Quote:
Originally Posted by Sebastian
We are multiplying very huge numbers, and an unsigned long reaches from 0 to 4,294,967,295. If you multiply (for example) 70000*70000, the result already breaks this range. So it's not just for accuracy, it will throw completely wrong values because you create an overflow!
|
The calculations can be done in 32bits, but you need to structure the operations such that they never overflow.
Take instantgph(), e.g. Here your formula is
gph= (instInjTot * 3,600,000,000 * 1000 ) / (parm[uSperGallon] * (instInjEnd - instInjStart))
I.e., you have one huge-ass, overflowing value, divided by another huge-ass, non-overflowing value. But you can break it down into non-overflowing operations, thusly:
x = ( 3,600,000,000 / (parm[uSperGallon] * (instInjEnd - instInjStart)) ) /* does not overflow */
gph = x * 1000 * instInjTot /* still does not overflow */
The same principle can be applied to each of the mpguino's calculations, to allow the complete removal of the 64bit math library. What you need, instead of blindly plugging in numbers from left-to-right, is to work out each calc with expected max values for each variable in the formula -- such as: injectors should be "On" for XXX microseconds, vssPulses should not exceed YYY, during the 0.5 second data collection window -- and then re-arrange the multiplications, divisions, additions & subtractions appropriately.
I had to do this to my 'guino, in order to squeeze extra functionality into my 168; but with the 328, i guess the code savings shouldn't matter at this point. Not only do you save ~1200 bytes by tossing the 64bit library, but you also save 100-200 bytes on each function that no longer needs 64bit math. I think any speed savings are negligible, since these functions only get called a few times per second.
If my 168 chip was socketed and not SMT, i would have simply swapped it for a 328, kept the 64bit math & spent my time on something else. It was a fun exercise, anyway.