|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.|
Real-time applications use interrupts to respond to external events in a timely manner. Using interrupts requires that an OS balance performance against ease of use. Windows CE balances these two factors by splitting interrupt processing into two steps: an interrupt service routine (ISR) and an interrupt service thread (IST).
Windows CE associates each interrupt request (IRQ) with one ISR. In Windows CE 2.x when interrupts are enabled and an interrupt occurs, the kernel calls the registered ISR for that interrupt. While the ISR is running, the kernel disables all other IRQs. Therefore, no other interrupt, regardless of the priority, can interrupt another ISR. Once finished, the ISR returns an interrupt identifier. The kernel examines the returned interrupt identifier and sets the associated event. When the kernel sets the event, the IST starts processing.
To prevent the loss and delay of high priority interrupts, the Windows CE 3.0 introduces nested interrupts. The following list shows how Windows CE handles nested ISR calls:
If a higher-priority IRQ arrives before the current ISR completes processing, the kernel saves the current ISR state.
Windows CE can nest as many ISRs as supported by the hardware. An ISR is affected by the delay if they are performing some action that must be completed in a specific amount of time or there are other timing related issues. In these situations, the ISR would need to disable interrupts while performing the require actions.
Last updated on Tuesday, May 18, 2004