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:
Peripherals that connect to a Windows CE–based platform through a serial port can do so at the maximum speed of the serial port. Most serial ports are buffered internally by 16550-class universal asynchronous receiver-transmitters (UARTs) capable of relaying 115 kilobits per second; consult the manufacturer for specific information. PC Card socket speeds vary also; again, the authoritative source of information is the manufacturer.
Last updated on Tuesday, July 13, 2004