Honda Mileage Measurement Device Firmware testing update

Today, the good news is that, after thousands of miles of simulated driving, the VID's fuel mileage measurement algorithms prove to be very stable. Indications on both the Blue Tooth and USB serial channels show complete complience with the established beta software testing standards.However, testing has uncovered one firmware bug. It is this type of bug that this test was designed to catch.

From the beginning we've decided not to utilize the floating point libraries available with the development compiler, we have instead gotten around the precision issues associated with using 32 bit unsigned long variables to represent floating point elements by using scaling up (by some factor) any variable that when divided by something else would result in round off errors. To use the floating point libraries too early would needlessly consume memory and processor bandwidth before we determined that we actually needed it. At some point, we may use the libraries but not before we run out of other options.

At any rate, given the wide latitude of using non signed 32 bit words we (thought) were careful to scale everything enough range to cover all possible uses of the variables.

For instance, the variable that stores the accumulated pulses for trip and tank is normally large enough to accommodate a trip of about 500,000 miles before that variable overflows. Similarly, the variable that holds the [accumulated gallons used] would handle 100,000 gallons before it overflowed. The accumatged gallons used variable is pre-scaled by a factor of 10000. i.e. 1 gallons is stored as 10000.

However, as we found out, while the variables are large enough to accumulate the specified range, certain functions used to convert accumulated pulses to accumulated miles, can overflow because of additional scaling used to avoid round off errors in these calculations.

This problem was noticed only once the trip and tank miles exceeded 1050 miles. A simple check of the process used to compute these numbers showed that pre-multiplying the accumulated pulses by 1000 to avoid round off errors, actually resulted in an overflow condition in a local unsigned long variable.

After following the general rule of THREES-- that is finding at least three ways to do something in embedded code, I have finally linked in the floating point libraries that came with this development system. As I eluded to a few paragraphes ago, falling back on the floating point libreies too early in the process would not have been the right thing to do. However, now that we are almost done-- with a lot of flash memory availabe-- it would be just as wrong not to include them now.

So.. without having to worry (so much) about the range of variables--- the device outputs the correct MPG to both the BCD display and the devices connected via the serial port(s).