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:
  • You should disable interrupts for as little time as possible (i.e., the minimum time you need to access or deal with the hardware). Failure to do so may result in increased interrupt latency and the inability to meet realtime deadlines.
  • Some kernel calls and library routines reenable interrupts. Masked interrupts aren't affected.
  • Setting up trace logging can be an excellent companion to writing an interrupt handler. If you've misconfigured hardware interrupts somehow, trace logging can reveal this before it becomes a problem (e.g., hardware interrupt flooding).
Page updated: