Microsoft Windows CE 3.0  

Real-Time Priority System

Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Windows CE 2.12 and earlier did not have robust support for real-time processing, largely due to the lack of nested interrupts and the small number of available thread priority levels. Hard real-time processing performance of Windows CE versions 2.12 and earlier varied widely according to processor and bus speed. On the Windows CE–based reference platform, interrupt-driven device drivers are typically started within 90 to 170 microseconds after the interrupt occurs, yielding theoretical sampling rates of about 5.8 to 11 kilohertz (kHz). The variability is due to many unpredictable factors, such as what data is currently in the processor cache and whether the device driver happens to be the currently executing process. On other hardware, factors such as CPU speed, bus speed, and the speed of the manufacturer's interrupt vectoring routines determine the lower limits of interrupt latency.

Because the ISTs of device drivers can be preempted by high-priority threads, there is no absolute upper limit. In general, however, the latency for servicing interrupts in Windows CE is less than the latency for Windows-based desktop platforms; device drivers are unlikely to lose data unless they are starved for processor time by other high-priority threads running on the OS. Device drivers for polled devices may be able to achieve higher sampling rates, because polled devices do not generate interrupts and are therefore not subject to the same latencies.

Windows CE 3.0 and later address some of these concerns by providing support for nested interrupts and by greatly increasing the number of available priority levels. ISRs and ISTs that must run at very high priority can now do so, and can preempt the processing of other, lower level ISRs and ISTs. However, because nested interrupts only occur for interrupts of a higher priority than the currently executing ISR, OEMs must be careful in how they assign the priority levels for their various device drivers.

The priority system, which used to have only 8 priority levels, now has 256 levels numbered 0 through 255. Priority level 0 is the highest priority level. The original 8 priority levels are mapped to levels 248 through 255. Applications and device drivers for Windows CE 3.0 and later should use the CeGetThreadPriorityand CeSetThreadPriorityAPIs, instead of the old APIs GetThreadPriorityand SetThreadPriority. The old APIs are still available, with the same interfaces as before, but those APIs have access only to the bottom 8 priority levels.

The new priority level system is broken into four ranges. Levels 0 through 96 are for high priority real-time tasks. Levels 97 through 152 are used by the default Windows CE device drivers. Levels 153 through 247 are for tasks that are higher priority than normal user-level tasks, but which should not interfere with device driver operations. Levels 248 through 255 are for non-real-time tasks such as user applications. The following table lists the default priority levels associated with Windows CE device drivers. OEMs can override these values either by changing the source code for the drivers, or by setting values in the registry.

Device Driver Priority Registry Key
USB Function Controller 100 none
USB OHC Driver 101 HKEY_LOCAL_MACHINE\Drivers\BuiltIn\OHCI\Priority256
USB UHC Driver 101 HKEY_LOCAL_MACHINE\Drivers\BuiltIn\UHCI\Priority256
Serial Port Driver 103 HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial\Priority256
PC Card Socket Driver 105 HKEY_LOCAL_MACHINE\Drivers\PCMCIA\Priority256
Touch Screen Driver 109 HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch\Priority256
IRSIR Driver 110 HKEY_LOCAL_MACHINE\Comm\Irsir1\Parms\Priority256
NDIS Driver 116 HKEY_LOCAL_MACHINE\Drivers\BuiltIn\NDIS\Priority256
EDBG Driver 130 none
CxPort Driver 132 HKEY_LOCAL_MACHINE\Comm\Cxport\Priority256
Keyboard Driver 145 HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Keybd\Priority256
IR Comm Driver 148 HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IrComm\Priority256
TAPI/Unimodem Driver 150 HKEY_LOCAL_MACHINE\Drivers\Unimodem\Priority256
WaveDev Driver 249 HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WaveDev\Priority256
WaveAPI Driver 250 HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WAPIMAN\Priority256

On the Windows CE–based reference the system can start an ISR in 2 to 5 microseconds. The system can start the corresponding IST in 90 to 170 microseconds. Many actual Windows CE–based platforms have better response times than these, depending on factors such as CPU type, clock speed, bus speed, and so on. Aside from hardware performance, the IST start times vary from one interrupt event to the next due to unpredictable factors, such as the state of the processor cache and whether the IST happens to be the currently running thread.

If your platform is not meeting your real-time performance requirements, you have the following options: