Odo-meter for Knight Rider.

[captain nguyen]

Oh...

Can admin move this threat for me?

[skimask]

Oh...

Can admin move this threat for me?

Can you find the Proton Basic forum section here?

[captain nguyen]

Do you mean "mel PIC BASIC Pro"?
If yes, but how can I move this threat?

[skimask]

Do you mean "mel PIC BASIC Pro"?
If yes, but how can I move this threat?

There is no THREAT here.

Apparently, you are NOT using MeLabs PicBasicPro. You are using PROTON Basic.
Try again.
Or maybe you expect somebody to covert a Proton Basic program to PicBasicPro for you?

[Darrel Taylor]

Or maybe he just doesn't realize the Proton forum is at ...

http://www.picbasic.org/forum
<br>

[Archangel]

Hello Captain,
I'm not fluent even in PBP much less Proton, but here is what I see . . . 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.

[skimask]

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.