<100uS accurate sleeps on Windows CE

Question

Is it possible to sleep for an amount of time that will be accurate to less than 100 microseconds on Windows CE? The less jitter the better - ideally we'd like single digit microsecond response times.

What we really want is a 5ms timer with very low jitter - although the Windows CE WaitFor[Single|Multiple]Objects and Sleep APIs work in units of milliseconds, we can't then correct for the sub-ms time our code may take to run, so the cycle would gradually drift.

If this is not possible, that information would be very helpful too.

Answer 1

This MSDN article has some code to set up a 500us timer interrupt in WinCE, so it's absolutely possible.

If you aren't locked into your version of WinCE, you might want to look into Tenasys, who claims to offer an RTOS running side-by-side with Windows on standard hardware.

I've also heard good things about QNX, but I haven't used their products either. I do not believe it is Windows compatible in any way, however.

Answer 2

It's not possible. It's not even possible on desktops. Typical operating systems simply don't function in this manner.

If what you need is something to fire precisely every 4 milliseconds or whatever you're out of luck. If what you really need is something to fire precisely 250 times every second that may be more doable. If you're in need of the latter I can suggest an approach.

Answer 3

If your need to sleep is not a battery/thread-yield issue and just a matter of accurate timing, you can use the "performancecounter" in Windows CE devices. On XScale and Qualcomm CPUs, this is the internal chip timer and has sub 1-ms granularity. On older OMAP and Samsung processors, the performancecounter API is passing through the 1ms system tick and has lots of jitter.

L.B.

Answer 4

To correct the jitter you need access to a high resolution timer. The CPU you have may have one. If not, the interrupt controller may.

The Easiest way is to use a Linux with realtime and WINE your way into that library. you want a Periodic Thread.

Take a look at this report from NIST.