Why can't PIC's support fp math

[jheissjr]

Good point. I understand that you can achieve floating point in software but I didn't realize adding a floating point processor section to the microcontroller would take up too much silicon space. I guess you could argue DSP's which are like microcontrollers on steroids can do floating point but we are PIC gurus, not DSP guys.

[Bruce]

Some 10 years ago when I was teaching a basic electronics course with an
an intro to 8051 embedded programming, a student asked this exact same
question.

He had a hand-held calculator with a couple of non-functional keys. We tore
it open to investigate, and noticed it had an incredibly tiny little IC tucked
away in there that was handling everything.

We managed to re-solder a few bad connections to the IC, and had his
calculator back up & going in a few minutes, but it raised his curiosity. He
asked; why can't they just stuff something like this little IC into a controller
core?

Then we wouldn't all be banging our heads on our desks trying to convert
degrees C to degrees F in assembler for this stupid temperature sensor!

Rather than debate the issue in class, we fired that same question at a
couple of embedded engineers from Intel.

When they all finished laughing, spilling coffee all over themselves, and
managed to get up off the floor & back to the phone to answer his question,
one of them said, "what's the point".

If we added this to the core, it would just drive the price per unit up for a
hardware solution to something that nobody needs & certainly don't want to
pay extra for.

Anyone that really needs to compute an FP result already has the library
in their bag-of-tricks, and if they don't, we have already provided tons of
examples in assembler, and it's already supported by high-level languages if
someone prefers to use them.

It's a feature that 99.9% of the high-level compiler manufacturers will even
recommended you use "only" as a last resort!

At the time, it would have increased the size of the controller also. I think
now they could probably manage to squeeze this into a core without making
the controller any larger, but it for sure would drive up the cost per unit, and
make people that just don't need FP math more than a little upset.

Especially if they already owned a compiler that supported FP.

[jheissjr]

I guess it would always make a good project, interfacing a calculator to a PIC

Darrel Taylor,
I left a message in your interrupt thread under Code Examples about using your code for 18F's. Can you check it out and see what you think.

[G8RPI]

Hi,
Rememder as well that intel used to have to put FP for the 86xxx series in a separate "maths co-processor" chip that typically cost more than the main processor (I remember the £200 86287). And they still got bugs in them.
Don't forget that you can get an external math chip to go with your pic if you really need it.
As Bruce says, you don't really need FP for most microcontroller projects. When working with ADC's little thought on signal and Vref values in relation to the number of bit's and the real world value you are measuring can make the math much easier.
G8RPI.

[leisryan]

Hi Darrel,

I've been reading out most of your threads You're of no doudt endowed with programming talents I am curious, has it ever crossed your mind authoring a book?

Ryan

[mister_e]

sometimes i suspect he's the guy in the expression Taylor series

Hey that's a good Book title 'PIC programming... the Taylor series'

[Charles Linquis]

One thing that would make the lack of floating point less of an issue is if PBP fully supported 24 or 32 bit integer math.