Quote Originally Posted by Joe S. View Post
Looks like you found some code that controls the display for the Odometer, I do not see anything here which does the math of turning 8000 counts into 1 mile. What I do see is this code writes to and reads from the eeprom and displays that on the 7 segment display, you would need to add some math routines to convert. In this case you know 8000 pulses = 1 mile so 8000/1.61 = 4968.944
not quite 5000, rounded up to 4969. Set up a 16 bit timer, preloaded with the difference between 65535 and 4969 and when it overflows you have traveled 1km, you will likely have to adjust that number some to account for "latency" in the pic while you are reloading the number in the timer. Oh, it is THREAD not Threat.
I don't think you'd really need any sort of timer unless you were trying to convert the odo input into a speed output. If it's just an odometer pulse input (which we're not even sure if the O/P is able to read that input in the first place), then it is just a simple matter of counting.
If you do know it is actually 8000 pulses per mile, then yes, you are right in that 8000 / 1.61 = 4968.944.
But since PBP can't do fractional numbers, and to add a bit more accuracy...
km_travelled = ( pulses_total * 412 ) / 2048
and to make it execute just a bit faster
km_travelled = ( pulses_total * 103 ) >> 9
Therefore, if you get 8000 pulses,
8000 * 103 / 512 = 1609 = 1.609 kilometers.

Hopefully this user's actual compiler (whether it be Proton or PBP) is capable of LONG (32 bit) variables, because using the above example, this will overflow after 13.18 kilometers. If a 32 bit variable is available, it'll be capable of counting up to 431,912 km's.