Printable View
I was thinking...
You can go to the dollar store and buy a calculator that runs all from a single chip that can do floating point math, scan the keypad, and output data to the LCD. If they can make calculators for less then a dollar, what is preventing microcontroller manufactures from putting in floating point support on the microcontroller.
Hypothetical question,
Could you take that <$1 calculator chip and make it control an autonomous aircraft using GPS to navigate?
Probably not, but I wouldn't place any bets against somebody doing it.
The problem is that the modern day calculator is the result of 40 years of evolution in silicon. The chips that are now considered "Simple" calculators, contain millions of transitors, doing fairly complex functions that can't be simulated with a few lines of code.
Granted, floating point math CAN be done in software, but it comes at a heafty price. The "price" being, Program Space. If you don't mind sacrificing that space, you can always include the Free - Floating Point routines found here ... http://www.melabs.com/resources/fp.htm
Once you use those files, you'll see how much code it takes. And to just include all that stuff on a general basis, or because 1 formula in a program used a decimal point, would not only waste space needlessly, but would tend to Tick people off a bit... Make that, a Large Bit.
Quite often, the chip in use may only have 1 or 2K words of program space. I wouldn't want F.P. using 800 words, and leaving me the rest.
Plus, while Floating Point works great if you're calculating the distance to the Moon in meters (or inches), it doesn't do sqwat for the robot 5.2 feet from a wall. In fact, it will probably induce errors that need not happen. Not to mention waisting a whole bunch of time in the process.
I think the final blow for me was when I subtracted 7 from 8 and got 0.9999999
But, this is not the End of the World. Just a plee for a different line of thought.
Usually, a request for Floating Point Math stems from the thought that "I need to use Decimals, ie 24.21"...
Ennnhhhhhhh! ... Wrong Answer!
With only a few additional statements, you can work with Decimals just as easy as integers. BUT, you'll need to keep track of the decimal point youself. (worth it)
So what is 24.21? Well, one way to look at it is 2,421 hundredths of 1 unit. And since it's in Hundredths, it's easy to display. Divide by 100.
Value = 2421
LCDOUT DEC Value / 100,".", dec2 Value // 100
; output = 24.21
Wala. Decimals without F.P.
Well, OK, it's a bit trickier than that. But it's a start.
...
Alright, I went 2 paragraphs beyond this point when I realized how bad I was rambling, so I'll stop here. But hey, I got more. (ramblings)
I'd just rather Ramble in the direction that intrests you. So, why do you need F.P.?
<br>
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.
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.
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.
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.
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
sometimes i suspect he's the guy in the expression Taylor series ;)
Hey that's a good Book title 'PIC programming... the Taylor series'
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.
For me, one of the worst parts of designing things is, having to write an Operators Manual for it when it's done.
I can't even fathom writing a whole book that I didn't have to, or be fired.
Nope, I'll leave that stuff up to Bruce.
But thanks for the thought.
Charles,
Yeah, wouldn't that be nice. Maybe even 64-bit?
<br>