Back in the day, when the 2 kbyte 8048 microcontroller was the latest and greatest thing on the market,
Sorry, my mistake- the 8048 was 1Kx8. The 8049 was 2Kx8. National brought out a 4K version which they called the 8050. The EPROM version had a 28 pin piggy-back socket on the 40 pin DIP and you could install a regular EPROM in it, up to a 2732 (4Kx8)
not seen "Math Toolkit for Real-Time Programming" but the reviews on Amazon make it sound like it would be well-worth reading.
Jack Crenshaw, author of the above book is a long time contributor to the magazine Embedded Systems Programming in his column "Programmer's Toolbox". It is a pleasure to read although he often goes way over my head.
@Antedeluvian: ...the 8048 was 1Kx8. The 8049 was 2Kx8....
Did you ever read the biographies of Bill Gates and Paul Allen -- the original Microsoft BASIC fit in 4K and that was with a floating-point library. I hadn't realized quite what an achievement it was until I read the biographies -- now I have a much better appreciation for the mannitude of the task.
Bill and Paul actually paid another developer for the floating-point part -- I think they paid him a few hundred dollars -- if only he had known how far Microsoft BASIC woudl spread (it was even on Apple's machines) -- he should have asked for 1% of net...
When you are solving mathematical problems in digital computers, many times it helps to abondon the base10 arithmetic and do all your calculations in just the binary base2 numbers . Thereby most of the multiplications and divisions can be achieved by Left Shift or the right shift of the bits .
It is so fast compared to a floating point or the interger arithmetic , that I used it in one of motion control alogirithms . I was working on DEC LSI 11 processor based motion controller and the robotic 3 axis motion control required the interpolation of the robot arms path while it waas negotiating a complex chassi assembly.
The base2 arithemetic came very handy - time and memory effiecient and without much of the rounding errors.
This is written from the viewpoint that floating point is expensive and integer is cheap. In an embedded processor, this can be a reasonable assumption. But in a multi-issue, out-of-order execution pipe, using floating-point can be faster because you are using otherwise idle functional units, freeing up the integer units for other operations. So you have to think about your overall system bottlenecks.
... bother the poor piece of silicon with this calculation at all ?
Until it is sent to an output the "physical value" will only con- sume memory and CPU power (to calculate) but the result does not hold more information than the mere 1234d value from the ADC.
Nowadays the fresh-bred engineers from univerity are calling for floating point units - seemingly not aware that integer arithmetics exist at all. About 15 years ago I was tasked with improvements on an automotive ECU - based on an i80196. 90 % of the software was in assembler (primarily due to memory restrictions) and there was absolutely no FP arithmetics.
I was fiddling with data resolutions of 1/4 rpm and - IIRC - 1/16 degree of camshaft angle -- and that was just fine. The only instance where the "computing numbers" were converted to "real world values" was in the visualizing tools (PC based). And it was THEIR damned job to calculate these values :)
Nowadays there are still some fields of application where you sould resort to integer arithmetics, e.g. EC control units. OK - CPUs with FPUs are readily available. But when it comes to total cost, power consumption etc. integer math is superior. And - BTW - easily more precise than 32 bit floating point.