Writing an Interrupt Handler

The key to handling hardware events in a timely manner is for the hardware to generate an interrupt. An interrupt is simply a pause in, or interruption of, whatever the processor was doing, along with a request to do something else.

The hardware generates an interrupt whenever it has reached some state where software intervention is desired. Instead of having the software continually poll the hardware—which wastes CPU time—an interrupt is the preferred method of “finding out” that the hardware requires some kind of service. The software that handles the interrupt is therefore typically called an Interrupt Service Routine (ISR).

Although crucial in a realtime system, interrupt handling has unfortunately been a very difficult and awkward task in many traditional operating systems. Not so with the QNX Neutrino RTOS. As you'll see in this chapter, handling interrupts is almost trivial; given the fast context-switch times in QNX Neutrino, most if not all of the “work” (usually done by the ISR) is actually done by a thread.

Let's take a look at the QNX Neutrino interrupt functions and at some ways of dealing with interrupts. For a different look at interrupts, see the Interrupts chapter of Getting Started with QNX Neutrino.

Note: Any kernel call results in the re-enabling of interrupts, and many library routines are built on kernel calls. Masked interrupts aren't affected.