Interrupt Handling Overview (Windows Embedded CE 6.0)

1/6/2010

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. Windows Embedded 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:

1. 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.

2. The kernel's interrupt support handler notifies the ISR to disable the specific interrupt until the required handling completes.
   All other interrupts remain enabled.

3. The exception handler calls the ISR to determine how to handle the interrupt.

   Note

   Details might vary depending on the CPU architecture.

4. 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.

5. 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.

6. As needed, the IST calls various I/O routines to access the hardware to do its work.

7. When the IST finishes its work, it notifies the kernel by calling InterruptDone.

8. 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.

The following table shows some event-related functions.

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.

The following table shows the functions that a custom driver DLL calls as part of the IST.

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

Other Resources

Interrupt Handling
Defining an Interrupt Identifier
Implementing an ISR
Loader
PCI Bus Driver
Real-Time Priority System