Handling an Interrupt (Windows CE 5.0)
The main technique for handling an interrupt is to associate an event to a specified interrupt service routine (ISR). Windows CE then schedules your interrupt service thread (IST) when the event is triggered.
A typical interrupt handling sequence includes the following steps:
The hardware raises an interrupt.
The kernel looks up the interrupt request (IRQ) of the interrupt, calls the registered ISR, and disables all lower-priority interrupts.
The ISR performs any necessary handling, and then returns an interrupt identifier.
If the interrupt identifier value returned by the ISR is SYSINTR_NOP, the kernel completes processing without setting an event — all interrupts are enabled — and continues performing any tasks in process before the interrupt occurred.
Otherwise, the kernel sets the event you have associated with the interrupt identifier. When the ISR returns, the kernel enables all other interrupts except the one that is being processed.
The kernel schedules the IST indicated by the interrupt identifier to run.
The IST can use driver resources to get or send data and control codes to the hardware and to acknowledge the hardware interrupt.
After completely servicing the interrupt, the IST calls the InterruptDone function. In turn, InterruptDone calls the OEMInterruptDone OAL interface function to perform any hardware actions necessary to enable the next interrupt of the target device.
The following code example shows the functions that an IST typically calls.
// CreateThread can supply one 32-bit parameter, so pass the event handle.
// Associate this thread with the registered event.
MyISTRoutine(HANDLE hEvent) {
InterruptDone(InterruptId);
while (1) {
WaitForSingleObject(hEvent, INFINITE);
// Check for thread exit signal and exit if set
// Interrupt processing here.
// On completion, call InterruptDone.
InterruptDone(InterruptId);
// Loop and wait for the kernel to set the event.
}
}
If you initialize and enable the interrupt before fully creating the IST thread, be aware that if the device does interrupt after the point that you have enabled it (before the IST thread has been created), then the IST will miss the event that occurs when the interrupt fired.
Therefore, you will never see an interrupt again and it will appear that the device is gone. In the above code example, the InterruptDone function clears any interrupts that may have fired.
The disadvantage to including the InterruptDone function is that this does not actually record the interrupt data. So, even though including the InterruptDone function does not hang the device, it loses the data related to the interrupt. If this is a critical interrupt, the data is lost.
Be aware that there can be a disconnect between the initialization of the interrupt and the actual handling of the interrupt in the IST. If an interrupt fires between these two processes, you may lose the interrupt data. InterruptDone clears the interrupt state, but you may lose the data during boot time.
See Also
How to Develop an OEM Adaptation Layer | Implementing an ISR
Send Feedback on this topic to the authors