People do often say "Avoid using floating point on 8-bit processors". The reason why that's a common piece of advice is that it consumes big chunks of memory and takes a long time to execute. If you're trying it anyway, and finding that it doesn't work very well, maybe it's time to consider stepping up to a more powerful processor. These days, that's a very cheap change to make.

But I have to ask, do you really and truly need all the precision that appears in your code? Perhaps some of the work you're making the processor do isn't very useful anyway.

 

People do often say "Avoid using floating point on 8-bit processors". The reason why that's a common piece of advice is that it consumes big chunks of memory and takes a long time to execute. If you're trying it anyway, and finding that it doesn't work very well, maybe it's time to consider stepping up to a more powerful processor. These days, that's a very cheap change to make.

But I have to ask, do you really and truly need all the precision that appears in your code? Perhaps some of the work you're making the processor do isn't very useful anyway.

I'm sure he does need the precision. I've often had sensor dosage calculations that involved nA current integration with 100's of keV for dopant ion depth per cm². If your needed measurement cycle time is low an efficient 8-bit software solution works to a point with clever shift and slight of hand normalization's.

I do agree it's time to step up the embedded processor (that means a total break with 8-bit asm) for complex scientific calculations when you can get double precision FP in hardware that just as fast as integers and it's not just instruction speeds, it's data throughput bottlenecks for modules on the chip.
https://forum.allaboutcircuits.com/...-bug-in-windows-and-excel.187649/post-1743403

 

Well, I'm skeptical about this line:
new_gain_index = (uint_fast8_t) (-13.888481 * log(target_bias) + (32.980565 + .5));

6 decimal places of analog precision, and then the result gets cast into an 8-bit quantity? I don't see how that can make sense.

 

Well, I'm skeptical about this line:
new_gain_index = (uint_fast8_t) (-13.888481 * log(target_bias) + (32.980565 + .5));

6 decimal places of analog precision, and then the result gets cast into an 8-bit quantity? I don't see how that can make sense.

It could be just a scaling factor. The validity of his calculations are not the issue of this thread IMO.

 

The reason why that's a common piece of advice is that it consumes big chunks of memory and takes a long time to execute.

The problem is the language, not the hardware.

I just demonstrated almost an order of magnitude difference in execution speed, and my entire floating point library fits in less than 4K of code. And it supports 32 and 56 bit IEEE floats (and could easily be extended to n bits if necessary). And it properly utilizes NANs and INFs and subnormal numbers.

But I have to ask, do you really and truly need all the precision that appears in your code?

Yes, where appropriate. While it might not seem like it, I am an expert in the things I do. I know when precision is required -- and how much -- and when it's not.

6 decimal places of analog precision, and then the result gets cast into an 8-bit quantity? I don't see how that can make sense.

It would if you knew what I was doing, and why.

This is part of a larger calculation. I needed to benchmark the floating point performance of xc8 vs. my existing code in .asm, and this is a simple and exemplary piece of code to do it with.

It only gets more intricate from here.

Perhaps some of the work you're making the processor do isn't very useful anyway.

If that were the case, I wouldn't be spending all this time trying to make C do it.

If you're trying it anyway, and finding that it doesn't work very well, maybe it's time to consider stepping up to a more powerful processor.

Et tu, Brute?

My message to Microchip:

Microchip, are you listening? The common refrain here is that I, a loyal customer of 33 years, need to dump you. I need to design you out of 23 years of legacy product of which I sell 10s of thousands of pieces every year, and never again design you into new product.

Solely because you won't support a decent assembler (i.e mpasm) on MPLabX that you already possess and have supported in the past under MPLabX.

Your 8 bit hardware is exceptional in terms of power and speed -- in my expert opinion -- and they are still well priced. The available on-chip hardware peripherals are exquisitely tailored to exactly what I need for the kinds of products I design and manufacture.

But the language tools for your 8 bit processors are severely lacking.

Oh! But you have a line of processors that will work better with C. I should switch to those, right?

Nah. Over 30 years ago, you promised there would always be a migration path forward with the 8 bit PICs.

You lied about that. If I have to change processor technology, it will not be Microchip.

--------------------

Finally, I have a right to be angry. I've invested a career in Microchip. It will be a long, difficult, and expensive slog to change to something else.

 

Finally, I have a right to be angry. I've invested a career in Microchip. It will be a long, difficult, and expensive slog to change to something else.

damn right ... I haven't yet stumbled onto the obstacles you're facing, but I too have invested lots of time in Microchip and hearing your story has made me angry too ... I honestly hope the appropriate people in that company somehow get your message one way or the other.

 

Microchip is no longer so micro. The chip shortage has greatly shifted priorities, the migration path forward with the 8 bit PICs is focused at C. IMO, That's unlikely to change.
https://www.microchip.com/en-us/abo...s-to-invest-880-million-to-expand-its-silicon

This plant was set to be mainly R&D a few years ago.

 

Microchip is no longer so micro. The chip shortage has greatly shifted priorities, the migration path forward with the 8 bit PICs is focused at C. IMO, That's unlikely to change.
https://www.microchip.com/en-us/abo...s-to-invest-880-million-to-expand-its-silicon

This plant was set to be mainly R&D a few years ago.

What happened to "corporate subsidies are evil?"

Oh! That's right. The other party is in power.

 

Finally, I have a right to be angry. I've invested a career in Microchip. It will be a long, difficult, and expensive slog to change to something else.

Time passes... the world changes....

No surprises, really.

 

the world changes....

The hardware or architecture didn't change, just the language support -- and in a stupid way.

It's kind of silly: I cannot be the only customer with a large .asm investment in Microchip beginning long before C was even available for the platform. I mean, they were (still are?) the top supplier of small micros on earth.

 

Come on, guys. You've got to think it's a little bit absurd that a MCU vendor will only support a language that cripples its hardware!

 

Come on, guys. You've got to think it's a little bit absurd that a MCU vendor will only support a language that cripples its hardware!

I can almost hear the idiots upstairs arguing "it's for your own good" ...

 

Come on, guys. You've got to think it's a little bit absurd that a MCU vendor will only support a language that cripples its hardware!

Asm is supported with the new X releases.

It might not be the old 32-bit version you already know and love but a supported version is supplied.

 

Asm is supported with the new X releases.

...

It might not be the old 32-bit version you already know and love but a supported version is supplied.

I am quite aware of pic-as. It is a fine intermediary between C and object code, but it really wasn't designed to code and debug in .asm.

For a major project, with tens of thousands of lines of .asm spread across dozens of files -- along with the requirement to use the linker -- makes pic-as a bear to use.

Last time I tried it, I was unable to define or debug floating point "variables". That is a show stopper for me. But, hey, it seems it now understands how to define floating point constants -- but only in 24 bit "short" float format!?

Mpasm under MPLab (along with the MPLab debugger) was far more capable at least as far back as 20 years ago.

 

For a major project, with tens of thousands of lines of .asm spread across dozens of files -- along with the requirement to use the linker -- makes pic-as a bear to use.

NOW I understand where you are coming from. Previously I just thought you were a cantankerous old goat You may be a cantankerous old goat anyways

 

I just thought you were a cantankerous old goat...

You thought correctly. Just ask my wife. There's a reason for the avatar I use.

I am also pretty set in my ways. I don't like change for the sake of change. Especially when the change means I cannot do things my way -- which in this case is superior to the new, "improved" way.

 

Mpasm under MPLab (along with the MPLab debugger) was far more capable at least as far back as 20 years ago...

Oh! And a s***ton faster! MPLab was nearly instantaneous from build to program to debug. Each build/program/debug cycle takes at least a minute on MPLabX. I code in *very* short segments -- testing often to ensure bugless code. MPLabX makes this painfully annoying.

 

Just a thought -- you might consider (perhaps by joining forces with others) developing your own IDE for PIC parts using assembly. It sounds like you have the detailed knowledge of what features are really needed and/or useful and, like you say, there should be a lot of people out there in the same boat. It might be a money maker for you.

 

Just a thought -- you might consider (perhaps by joining forces with others) developing your own IDE for PIC parts using assembly. It sounds like you have the detailed knowledge of what features are really needed and/or useful and, like you say, there should be a lot of people out there in the same boat. It might be a money maker for you.

I already suggested the same thing a few posts ago. And I myself am willing to contribute however I can if such thing gets organized.

 

...you might consider (perhaps by joining forces with others) developing your own IDE for PIC parts using assembly.

That'd be fun...instead of tending the garden someday when/if I retire. And I'd do it for free (my code is that good).

Starting from scratch would be IMO an impossible task -- heck, there are other open-source PIC assemblers that support, what, maybe 5 parts? And an IDE -- including a useful debugger? Not a chance.

I would love for Microchip to open-source their old MPLab/mpasm and put it up on Github. There could be two forks: one to add support for the newer chips to the old 32 bit code base, and another to convert the code base from 32 to 64 bit for use not only on Windows, but Linux as well.

I would participate in such a project. But my contacts over at Microchip are stale. I wouldn't know to whom to make such a request, nor if corporate would allow it.