Bosch 60-2 timing wheel resolution

johnc32779 · Post by **johnc32779** » Mon Jun 26, 2006 9:37 am

On the subject of timing wheel resolution the following site contains an interesting article explaining the evolution of the Bosch 60-2. Apparently Bosch is employing both the rising and falling VR edges for 3 degee resolution, and then through timers, the computer further divides each segment into quarters for 0.750 degree resolution.

http://frwilk.com/944dme/

The selection text may not be visible. If so click on the 4th selection down from the upper left top.

muythaibxr · Post by **muythaibxr** » Mon Jun 26, 2006 9:49 am

ahh, so I guess they're doing fixed timer intervals so they "know" they won't have a timer event running into a spark event...

My code at its worst should have around 10-20 usec accuracy... it's only limited to how long an OC timer has to wait when other interrupts run...

So far in my oscilloscope testing, I've seen no more than 10 usec jitter at 8333 rpms... I haven't tested any higher. This was testing on a really nice digital storage scope. The only time I get inaccurate is when a timer is supposed to go off within about 20 usec of a predicted tooth... I just err on the side of timing being a little more retarded, and allow the event to occur on a tooth.

But yeah, it'd be nice to not have to include the code that keeps 2 interrupts from happening that close together... I was under the impression that the processor could handle situations where the interrupts are occuring close together, but it seems not.

Ken

johnc32779 · Post by **johnc32779** » Mon Jun 26, 2006 10:59 am

It is inconceivable to me that the processor hardware design would allow missed interrupts.

I am sure you have triple check this. Never the less so thing must have gone astray. Could the compiler be the culprit? Perhaps the following Freescale forum can help.

[/url]http://forums.freescale.com/freescale/[url]

This replaces the "freegeeks.net" forum.

[/url]

baldur · Post by **baldur** » Wed Aug 15, 2007 3:28 pm

muythaibxr wrote:My code at its worst should have around 10-20 usec accuracy... it's only limited to how long an OC timer has to wait when other interrupts run...

So far in my oscilloscope testing, I've seen no more than 10 usec jitter at 8333 rpms... I haven't tested any higher. This was testing on a really nice digital storage scope. The only time I get inaccurate is when a timer is supposed to go off within about 20 usec of a predicted tooth... I just err on the side of timing being a little more retarded, and allow the event to occur on a tooth.

But yeah, it'd be nice to not have to include the code that keeps 2 interrupts from happening that close together... I was under the impression that the processor could handle situations where the interrupts are occuring close together, but it seems not.

Ken

20uS is a whole degree of timing at 8000rpm, not very precise...

As for interrupts, you really need to use a vectored interrupt controller that allows for interrupts to wait while other interrupts are being served. However you must take care that no interrupt routine takes up so much time that you can get two interrupts on a single source that is waiting meanwhile. Of course you will get jitter in interrupt response time like that but you shouldn't be bit banging time critical I/O anyway.