You can even take the remainder (from the division) and, if it's 3 or 4, add 1 to the result to get correct rounding.
Or uh... add 2 before the division, I suppose.
Or to maintain accuracy, multiply by say 16 (or << 4), to get 12.4 fixed point -- this shift has to be un-done for printing, so it may be a bit inconvenient, or the 62mK resolution may simply be unnecessary.
That is:
accu = readCurrentTemperature() * 9;
accu <<= 4;
accu /= 5;
accu += 32 << 4;
printf("%d", accu >> 4);
printf(".%03d\n", ((accu & 0x0f) * 125) >> 1);
Or if you want to write out the print routine yourself, take the fractional part (accu & 0x0f), multiply by 10 to get a new digit above the decimal, print the digit, mask it off, and repeat:
for (...) {
frac = frac * 10;
printf("%d", (frac & 0xf0) >> 4);
}
Only a few digits are needed, since 4 bits of fraction = (0..15) / 16, which by itself doesn't fit into 1 digit (but the fifth in the present problem handily does), does easily fit into 2 digits (100ths), and terminates after 4 digits (
0.0625000, etc.).
This is, in part, how you work with fixed point numbers. Once you get a feel for them, it's not much harder to work with than floats in most problems, and goes
much faster on most embedded platforms.
I can report my own partial fail in this regard, as I had a recent problem with just too much dynamic range in play to handle easily even in 32 bit fixed point; as I couldn't justify spending time figuring it out, I fell back on floating point, which actually only added about 2kB to the binary, and my MCU had plenty of cycles to spare for the operation. (This was math in the complex domain, a bit weightier than whole numbers -- that's already 64 bits per complex number. Doing it with [32 bit] floats, takes up as much memory, but I don't have to pay any attention at all to dynamic range and shifting -- that's really what it's about, a "floating point" is literally just doing that every time.)
Tim
Home
Help
Search
Login
Register
