Hi Skimask,
If I understand your application right you are sending a 0 – 80 mS pulse from your main processor to your 683.
The 683 receives it 9with a 320uS resolution) and, after a little processing, creates a 4X output frequency for your tachometer set up as a MPG display.
So basically you start with a known value in digital format, process it to a 0 – 80 mS pulse, send it out, receive it with a 320 uS resolution, process it some more, output a 4x necessary frequency for the tachometer, divide it by 4 and finally display it.
If we do a little math we are basically dealing with a little over 240 steps of MPG information and a lot of processing taking its toll on accuracy and your main processor timing.
I was wandering if it is not easier to start from your known MPG value (0 – 80 MPG), multiply it by lets say 3 and you will have a value 0 – 240 (this is under 256 so you can treat it as a byte). You can even use a 0 – 80 value if you happy with 1 MPG resolution.
Just use your favorite serial communication module and send it out serially from your main processor to your secondary processor (this should take less than 80 mS even at low baud rates). In return your main processor timing will be more predictable and you preserve accuracy.
You can get really creative on the last 2 steps. I’m only suggesting one way.
On the 683 level process the received byte as your 3xMPG and do what you use to do:
Generate a frequency for the tachometer. You can get creative here also.
The idea is to keep it all in digital without going into the “artificial” digital to analog, analog to digital conversion done with PULSIN, PULSOUT.
BTW: I do not think you should be too concern with the close to zero values. Once you know your idle MPG, you can ignore and zero any readings way under this value (you should use a safety cushion).
Hope this will give new avenues to explore.
Regards,
Nick
Bookmarks