Handling Hardware Interrupts

QNX SDP8.0Programmer's GuideDeveloper

This chapter explains the QNX OS mechanisms for quickly reacting to hardware events.

The key to handling hardware events quickly 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 traditionally 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 OS. As you'll see in this chapter, handling interrupts is almost trivial; given the fast context-switch time in QNX OS, the work is done by an Interrupt Service Thread (IST).

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

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.
  • Kernel calls and some library routines reenable interrupts. Masked interrupts aren't affected.
  • Setting up trace logging can be an excellent companion to writing an interrupt thread. If you've misconfigured hardware interrupts somehow, trace logging can reveal this before it becomes a problem (e.g., hardware interrupt flooding).
Page updated: