Haven't I made myself clear, repeatedly? Let me shout it:

I DO NOT WANT TO WRITE C CODE FOR 8 BIT CPUS! I WANT TO WRITE ASM. BUT I CANNOT, BECAUSE MY CPU VENDOR WILL NO LONGER SUPPORT A DECENT ASSEMBLER FOR THEIR PARTS.

Comprende?

That's certainly clear, but doesn't answer my questions. But it matters not, I am now uninterested in communicating with you any further.

 

Haven't I made myself clear, repeatedly? Let me shout it:

I DO NOT WANT TO WRITE C CODE FOR 8 BIT CPUS! I WANT TO WRITE ASM. BUT I CANNOT, BECAUSE MY CPU VENDOR WILL NO LONGER SUPPORT A DECENT ASSEMBLER FOR THEIR PARTS.

Comprende?

Forgive me if my following suggestion might seem stupid or naïve ... but how hard would it be to gather a small band of programmers as frustrated as you are, and possibly crowdsource an open architecture assembler? ... or perhaps write add-ons to whatever mediocre software is available? I mean, all of the devices' datasheets include opcodes and all pertinent information needed for such a task, don't they?

 

Forgive me if my following suggestion might seem stupid or naïve ... but how hard would it be to gather a small band of programmers as frustrated as you are, and possibly crowdsource an open architecture assembler? ... or perhaps write add-ons to whatever mediocre software is available? I mean, all of the devices' datasheets include opcodes and all pertinent information needed for such a task, don't they?

Your suggestion is not stupid or naive. There are third party open source assemblers in the wild. The problem is the IDE, simulator, and debugger with respect to the newer, more capable parts.

If Microchip would open source mpasm and mplab, I'd be all over it -- and I believe it would be a popular project.

 

Your suggestion is not stupid or naive. There are third party open source assemblers in the wild. The problem is the IDE, simulator, and debugger with respect to the newer, more capable parts.

If Microchip would open source mpasm and mplab, I'd be all over it -- and I believe it would be a popular project.

Then contacting Microchip's customer support would be in order... hell, maybe I (and other members of this forum) would be willing to jump in the wagon too.

 

Wow. I just learned xc8 doesn't know how to multiply two 32 bit integers.

 

Wow. I just learned xc8 doesn't know how to multiply two 32 bit integers.

Are you promoting to long long integers before multiplying and noting the restrictions to C99 for PIC18? Unlike assembler where 32x32 can provide a 64 bit product, C is usually 32x32=32. I haven't run big integers in XC8 so just a guess.
Disregard if you've thought of all of that and XC8 is fouled...

__int24 24 Signed integer
__uint24 24 Unsigned integer
signed long 32 Signed integer
unsigned long 32 Unsigned integer
signed long long 32/64 Signed integer
unsigned long long 32/64 Unsigned integer

The __bit and __int24 types are non-standard types available in this implementation. The long long types are
64-bit C99 standard types when building for PIC18 or Enhanced Mid-range devices, but this implementation limits
their size to only 32 bits for projects conforming to the C90 Standard or any project targeting any other device.

 

Wow. I just learned xc8 doesn't know how to multiply two 32 bit integers.

To yield a 64-bit integer? When a 64-bit integer is not defined in XC8? You're funny. What kind of operations are you doing that requires 64-bit resolution with an 8-bit processor? Have you... well, never mind. I won't ask the question because the answer is obvious. I'm sure you'll claim you understand so much but the fact that you're surprised XC8 can't create 64-bit variables is funny. The datasheet for XC8 clearly says 64-bit numbers are not supported.

 

Disregard if you've thought of all of that and XC8 is fouled...

I'm not sure much thinking is happening - just complaining.

 

Then contacting Microchip's customer support would be in order... hell, maybe I (and other members of this forum) would be willing to jump in the wagon too.

It sounds like he jumped right on your generous suggestion.

 

Are you promoting to long long integers before multiplying and noting the restrictions to C99 for PIC18? Unlike assembler where 32x32 can provide a 64 bit product, C is usually 32x32=32. I haven't run big integers in XC8 so just a guess.
Disregard if you've thought of all of that and XC8 is fouled...

You are right.

A quick google search gave old results re C90. As I've grown to expect disappointment from this compiler, I just sighed and gave up.

This code compiles:

unsigned long ComputeBias_pA(void)
{
    return (unsigned long)(41042084*(unsigned long long) vbias / getGain().wordv);
}

but it is not tested yet.

 

A quick google search..

Don't forget the latest XC8 User's Guide - I copied the info from the 'data types' section.. pp. 93
https://ww1.microchip.com/downloads...8-C-Compiler-Users-Guide-for-PIC-50002737.pdf

 

Here's an insight into this project (which is now working quite well):



The "Bias" in the 3rd chart is a function of Temperature (and other things), which is controlled via a PID loop controlling the PWM. The Bias is being controlled within about +/- 300 pA of 100nA (full scale is about 50uA).

The data is transmitted from the PIC to the PC via USB SSP. The data rate to the app is only about 30 SPS (plenty for the analysis I need to do). Internally, the PID implementation is running about 16K samples/second.

The software is a real-time data capture / analysis tool I wrote for DOS back in 1994. It is written in Microsoft Visual C++ 1.52 and compiles for up to 80386 CPUs with VGA graphics (800x600x16 color). It does things no other package can, so I continue to maintain it. It runs great on DOSBox under Linux.

 

I should point out: even though the project is working, I've had to make a lot of compromises because it is written in C.

One of these compromises is that I need to run the clock at least 3x faster than necessary than I would have to were I writing in .asm.

 

BTW, I would love to modify my analysis software to run natively under Gnome.

I would like to use Vala with a charting library called LiveChart.

But I cannot get the LiveChart example to build on Ubuntu Budgie 20.04:

[2/139] Compiling Vala source ../src/a...vala ../src/static/static_points.vala.
FAILED: src/25a6634@@livechart_static@sta/area.c src/25a6634@@livechart_static@sta/axis.c src/25a6634@@livechart_static@sta/background.c src/25a6634@@livechart_static@sta/bar.c src/25a6634@@livechart_static@sta/bezier.c src/25a6634@@livechart_static@sta/bounds.c src/25a6634@@livechart_static@sta/chart.c src/25a6634@@livechart_static@sta/config.c src/25a6634@@livechart_static@sta/drawable.c src/25a6634@@livechart_static@sta/font.c src/25a6634@@livechart_static@sta/geometry.c src/25a6634@@livechart_static@sta/grid.c src/25a6634@@livechart_static@sta/intersections.c src/25a6634@@livechart_static@sta/intersectors.c src/25a6634@@livechart_static@sta/labels.c src/25a6634@@livechart_static@sta/legend.c src/25a6634@@livechart_static@sta/line_area.c src/25a6634@@livechart_static@sta/line.c src/25a6634@@livechart_static@sta/max_bound_line.c src/25a6634@@livechart_static@sta/min_bound_line.c src/25a6634@@livechart_static@sta/path.c src/25a6634@@livechart_static@sta/points.c src/25a6634@@livechart_static@sta/region.c src/25a6634@@livechart_static@sta/serie.c src/25a6634@@livechart_static@sta/serie_renderer.c src/25a6634@@livechart_static@sta/series.c src/25a6634@@livechart_static@sta/smooth_line_area.c src/25a6634@@livechart_static@sta/smooth_line.c src/25a6634@@livechart_static@sta/time_seek.c src/25a6634@@livechart_static@sta/threshold_line.c src/25a6634@@livechart_static@sta/utils.c src/25a6634@@livechart_static@sta/values.c src/25a6634@@livechart_static@sta/static/static_chart.c src/25a6634@@livechart_static@sta/static/static_series.c src/25a6634@@livechart_static@sta/static/static_serie.c src/25a6634@@livechart_static@sta/static/static_values.c src/25a6634@@livechart_static@sta/static/static_serie_renderer.c src/25a6634@@livechart_static@sta/static/static_line.c src/25a6634@@livechart_static@sta/static/static_grid.c src/25a6634@@livechart_static@sta/static/static_points.c src/livechart_static.h src/livechart_static.vapi
valac -C --debug --debug --pkg gee-0.8 --pkg gtk+-3.0 --color=always --directory src/25a6634@@livechart_static@sta --basedir ../src --library livechart_static --header src/livechart_static.h --vapi ../livechart_static.vapi --target-glib=2.50 --ccode --debug ../src/area.vala ../src/axis.vala ../src/background.vala ../src/bar.vala ../src/bezier.vala ../src/bounds.vala ../src/chart.vala ../src/config.vala ../src/drawable.vala ../src/font.vala ../src/geometry.vala ../src/grid.vala ../src/intersections.vala ../src/intersectors.vala ../src/labels.vala ../src/legend.vala ../src/line_area.vala ../src/line.vala ../src/max_bound_line.vala ../src/min_bound_line.vala ../src/path.vala ../src/points.vala ../src/region.vala ../src/serie.vala ../src/serie_renderer.vala ../src/series.vala ../src/smooth_line_area.vala ../src/smooth_line.vala ../src/time_seek.vala ../src/threshold_line.vala ../src/utils.vala ../src/values.vala ../src/static/static_chart.vala ../src/static/static_series.vala ../src/static/static_serie.vala ../src/static/static_values.vala ../src/static/static_serie_renderer.vala ../src/static/static_line.vala ../src/static/static_grid.vala ../src/static/static_points.vala
../src/series.vala:58.13-58.41: error: Argument 1: Cannot convert from `int' to `unowned LiveChart.Serie'
            foreach(var entry in signals){
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Compilation failed: 1 error(s), 0 warning(s)
ninja: build stopped: subcommand failed.

Google's no help. Any ideas?

 

One of these compromises is that I need to run the clock at least 3x faster than necessary than I would have to were I writing in .asm.

Is your hardware battery powered?

 

Is your hardware battery powered?

Yes. But CPU power consumption is not the limiting factor in this app.

The application is based on thermionic emission and requires a small platinum coil to be heated to 600 to 1000C. This alone consumes about 300mA from a single Li ion cell.

My biggest beef with C right now is how much time is require to babysit the compiler ensuring optimal code generation wrt execution speed.

 

I should point out: even though the project is working, I've had to make a lot of compromises because it is written in C.

One of these compromises is that I need to run the clock at least 3x faster than necessary than I would have to were I writing in .asm.

CPU speed is cheap, your brains and time are not. Chose wisely.

 

CPU speed is cheap, your brains and time are not. Chose wisely.

But I can work faster in .asm.

 

But I can work faster in .asm.

That and $6 bucks will get you a fancy cup of coffee. .asm -> C

 

This equation, in C, requires about 13,000 instruction cycles to execute:

new_gain_index = (uint_fast8_t) (-13.888481 * log(target_bias) + (32.980565 + .5));

The equivalent, using my .asm floating point library:

          pushfpc   f32_9
          pushfpc   fm9_6
          pushfl    target_bias
          call      log2f
          call      mulf
          call      addf
          popuint   newindex

requires about 1,600 instruction cycle.

No wonder you guys avoid floats like the plague. C sucks! I mean, like, really, really bad.