Interrupt Handling Overview (Windows CE 5.0)
Real-time applications use interrupts to respond to external events in a timely manner. The use of interrupts requires that an operating system (OS) balance performance against ease of use. Microsoft® Windows® CE balances these two factors by splitting interrupt processing into two steps: an interrupt service routine (ISR) and an interrupt service thread (IST).
Each interrupt request (IRQ) is associated with an ISR; an ISR can respond to multiple IRQ sources. When interrupts are enabled and an interrupt occurs, the kernel calls the registered ISR for that interrupt. 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.
The exception handler is the primary target of all interrupts. When an interrupt occurs, the microprocessor transfers control to an exception handler in the kernel. The exception handler then calls the ISR registered to handle the current interrupt. The ISR is responsible for translating the interrupt into a logical interrupt identifier, a SYSINTR, which it passes to the kernel as its return value. The kernel sets an event associated with the logical interrupt, which causes an interrupt service thread (IST) to be scheduled. Code in the IST is responsible for servicing the device interrupt. The IST runs in the context of a thread in Device Manager and is essentially a typical application thread running at a high priority.
You generally register your ISRs with the exception handler at system boot time. During boot, the kernel calls the OEMInit function in the OEM Adaptation Layer (OAL). Next, OEMInit calls the HookInterrupt function to inform the exception handler of which ISRs correspond to individual physical interrupt lines. A few subroutines in the OAL, such as the OEMInterruptEnable, OEMInterruptDisable, and OEMInterruptDone functions, are also used in interrupt processing. The interrupt handler manages the details of registering a driver for a particular interrupt and deregistering it later. It also maintains communication among the ISR, the IST, and subroutines within the OAL.
The following list shows an example of an interrupt-handling sequence:
If the kernel's exception-trapping code receives a hardware interrupt, and then the kernel detects an exception, the kernel handles the hardware interrupt.
Otherwise, go to the next step.
The kernel's interrupt support handler notifies the ISR to disable the specific interrupt until the required handling completes.
All other interrupts remain enabled.
The exception handler calls the ISR to determine how to handle the interrupt.
Note Details might vary depending on the CPU architecture.
The kernel receives the return value from the ISR, which lets the kernel know what to do about the interrupt.
The following table shows the possible responses from the kernel.
Response Description SYSINTR_NOP The kernel does nothing. SYSINTR_RESCHED The kernel reschedules the IST. The interrupt was for the OS timer tick thread. SYSINTR_XXX, logical interrupt value for that specific interrupt source. The kernel triggers the interrupt sources ISR so the IST wakes up and does its work. Then, the IST creates an event and waits on it. When the IST wakes up, the IST does whatever work it needs to do to handle the interrupt.
This could mean moving data into a buffer or interpreting the data in some meaningful way.
As needed, the IST calls various I/O routines to access the hardware to do its work.
When the IST finishes its work, it notifies the kernel by calling InterruptDone.
The kernel calls the OAL function OEMInterruptDone to complete all handling for the interrupt.
The OAL notifies the hardware to re-enable the interrupt.
The following illustration shows how kernel mode interrupt components and built-in device drivers interact with each other and the hardware.
.gif "Aa448274.intrrupt(en-us,MSDN.10).gif")
The following table shows some event-related functions.
| Function | Description |
|---|---|
| CeSetPowerOnEvent | Allows power callbacks in device drivers to set arbitrary events when the system resumes processing. |
| CreateEvent | Creates a named or an unnamed event object. |
| PulseEvent | Provides a single operation that sets the state of the specified event object to signaled, and then resets it to nonsignaled after releasing the appropriate number of waiting threads. |
| ResetEvent | Sets the state of the specified event object to nonsignaled. |
| SetEvent | Sets the state of the specified event object to signaled. |
| SetInterruptEvent | Allows a device driver to cause an artificial interrupt event. |
| WaitForSingleObject | Returns when the specified object is in the signaled state or when the time-out interval elapses. The kernel provides special treatment to interrupt events. ISTs cannot use WaitForMultipleObject with an interrupt event. |
For more information about events and event objects, see Event Object Notification and Synchronization.
The following table shows the functions that the OAL calls to associate an incoming hardware interrupt line with a software ISR.
| Function | Description |
|---|---|
| HookInterrupt | Called in the OEMInit function to associate an ISR with an IRQ. |
| UnhookInterrupt | Called to break the association between an ISR and an IRQ. |
The following table shows the functions that a custom driver DLL calls as part of the IST.
| Function | Description |
|---|---|
| InterruptDisable | Disables a hardware interrupt as specified by its interrupt identifier. |
| InterruptDone | Signals to the kernel that interrupt processing is complete. |
| InterruptInitialize | Initializes a hardware interrupt with the kernel. This initialization allows the device driver to register an event and enable the interrupt. |
Although layered drivers use the same functions to process interrupts, you do not have to use these functions to migrate layered drivers because the model device driver (MDD) layer, which typically does not require modification, already contains the proper calls to these functions.
See Also
Defining an Interrupt Identifier | Implementing an ISR | Loader | PCI Bus Driver | Real-Time Priority System
Send Feedback on this topic to the authors