Книга: Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

Lesson Summary

Lesson Summary

Windows Embedded CE relies on ISRs and ISTs to respond to interrupt requests triggered by internal and external hardware components that require the attention of the CPU outside the normal code execution path. ISRs are typically compiled directly into the kernel or implemented in device drivers loaded at boot time and registered with corresponding IRQs through HookInterrupt calls. You can also implement installable ISRs in ISR DLLs, which device drivers can load on demand and associate with an IRQ by calling LoadIntChainHandler. Installable ISRs also enable you to support interrupt sharing. For example, on a system with only a single IRQ, such as an ARM-based device, you can modify the OEMInterruptHandler function, which is a static ISR that loads further installable ISRs depending on the hardware component that triggered the interrupt.

Apart from the fact that ISR DLLs must not have any dependencies on external code, ISRs and installable ISRs have many similarities. The primary task of an interrupt handler is to determine the interrupt source, mask off or clear the interrupt at the device, and then return a SYSINTR value for the IRQ to notify the kernel about an IST to run. Windows Embedded CE maintains interrupt mapping tables that associate IRQs with SYSINTR values. You can define static SYSINTR values in the source code or use dynamic SYSINTR values that you can request from the kernel at run time. By using dynamic SYSINTR values, you can increase the portability of your solutions.

According to the SYSINTR value, the kernel can signal an IST event which enables the corresponding interrupt service thread to resume from a WaitForSingleObject call. By performing most of the work to handle the IRQ in the IST instead of the ISR, you can achieve optimal system performance because the system blocks interrupt sources with lower or equal priority only during ISR execution. The kernel unmasks all interrupts when the ISR finishes, with the exception of the interrupt currently in processing. The current interrupt source remains blocked so that a new interrupt from the same device cannot interfere with the current interrupt handling procedure. When the IST has finished its work, the IST must call InterruptDone to inform the kernel that it is ready for a new interrupt so that the kernel's interrupt support handler can reenable the IRQ in the interrupt controller.

Оглавление книги