Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
Programming
Programmer's Guide
The QNX Neutrino Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX Neutrino RTOS.
Writing an Interrupt Handler
Interrupt Service Routine (ISR)
In our example above, the function serint() is the ISR.
Servicing the hardware
The above discussion may lead you to the conclusion that level-sensitive is good; edge-triggered is bad. However, another issue comes into play.

QNX Momentics IDE User's Guide
This User's Guide describes version 7.1 of the Integrated Development Environment (IDE) that's part of the QNX Momentics tool suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
- Quickstart Guide
- OS Components & Operations
- Audio & Graphics API
- Multimedia
- Networking Middleware
- Programming
  - Getting Started with QNX Neutrino
    Getting Started with QNX Neutrino: A Guide for Realtime Programmers is intended to introduce you to the QNX Neutrino RTOS and help you develop applications and resource managers for it.
  - Programmer's Guide
    The QNX Neutrino Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX Neutrino RTOS.
    - Compiling and Debugging
    - Programming Overview
    - Processes
      As we stated in the Overview chapter, the architecture of the QNX Neutrino RTOS consists of a small microkernel and some number of cooperating processes. We also pointed out that your applications should be written the same way—as a set of cooperating processes.
    - Multicore Processing
    - Working with Access Control Lists (ACLs)
      Some filesystems, such as the Power-Safe (fs-qnx6.so) filesystem, extend file permissions with Access Control Lists, which are based on the withdrawn IEEE POSIX 1003.1e and 1003.2c draft standards.
    - Understanding the Microkernel's Concept of Time
      Whether you're working with timers or simply getting the time of day, it's important that you understand how the OS works with time.
    - Transparent Distributed Processing Using Qnet
      Transparent Distributed Processing (TDP) allows you to leverage the processing power of your entire network by sharing resources and services transparently over the network. TDP uses the QNX Neutrino native network protocol, Qnet, to link the devices in your network.
    - Writing an Interrupt Handler
      - Interrupts on multicore systems
        On a multicore system, each interrupt is directed to one (and only one) CPU, although it doesn't matter which. How this happens is under control of the programmable interrupt controller (PIC) chip(s) on the board. When you initialize the PICs in your system's startup, you can program them to deliver the interrupts to whichever CPU you want to; on some PICs you can even get the interrupt to rotate between the CPUs each time it goes off.
      - Attaching and detaching interrupts
        In order to install an ISR, the software must tell the OS that it wishes to associate the ISR with a particular source of interrupts, which can be a hardware Interrupt Request line (IRQ) or one of several software interrupts.
      - Interrupt Service Routine (ISR)
        In our example above, the function serint() is the ISR.
        Determining the source of the interrupt
        Depending on your hardware configuration, there may actually be multiple hardware sources associated with an interrupt. This issue is a function of your specific hardware and bus type. This characteristic (plus good programming style) mandates that your ISR ensure that the hardware associated with it actually caused the interrupt.
        Servicing the hardware
        The above discussion may lead you to the conclusion that level-sensitive is good; edge-triggered is bad. However, another issue comes into play.
        Safe functions
        When the ISR is servicing the interrupt, it can't make any kernel calls (except for the few that we'll talk about shortly). This means that you need to be careful about the library functions that you call in an ISR, because their underlying implementation may use kernel calls.
        Updating common data structures
        Another issue that arises when using interrupts is how to safely update data structures in use between the ISR and the threads in the application.
        Notifying the application code
        Since the environment the ISR operates in is very limited, generally you'll want to perform most (if not all) of your actual servicing operations at the thread level.
      - Running out of interrupt events
        If you're working with interrupts, you might see an Out of Interrupt Events error, which leads to a kernel shutdown.
      - Problems with shared interrupts
        It's possible for different devices to share an interrupt (for example if you've run out of hardware interrupt lines), but we don't recommend you do this with hardware that will be generating a lot of interrupts. We also recommend you not share interrupts with drivers that you don't have complete source control over, because you need to be sure that the drivers process interrupts properly.
      - Advanced topics
        Now that we've seen the basics of handling interrupts, let's take a look at some more details and some advanced topics.
    - 32- and 64-Bit Architectures
      QNX Neutrino 7.1 or later supports 32- and 64-bit versions of ARM (armle-v7 and aarch64le) and 64-bit versions of x86 (x86_64).
    - Working with Memory
      (or The Persistence of Memory, with a nod to Salvador Dali)
    - Power Management
      A major contributor to the power consumption of a CPU is the frequency at which it is clocked. The power-management API allows you to manage this.
    - Freedom from Hardware and Platform Dependencies
    - Conventions for Recursive Makefiles and Directories
      In this chapter, we'll take a look at the supplementary files used in the QNX Neutrino development environment. Although we use the standard make command to create libraries and executables, you'll notice we use some of our own conventions in the Makefile syntax.
    - Glossary
  - The QNX Neutrino Cookbook: Recipes for Programmers
  - Writing a Resource Manager
- Sensor Framework
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX Neutrino RTOS system and developers who want to create a QNX Neutrino resource manager free from vulnerabilities.
- Utilities & Libraries
QNX Hypervisor
The QNX Hypervisor allows you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
QNX Advanced Virtualization Frameworks User's Guide
This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

Servicing the hardware

The above discussion may lead you to the conclusion that level-sensitive is good; edge-triggered is bad. However, another issue comes into play.

In a level-sensitive environment, your ISR must clear the source of the interrupt (or at least mask it via InterruptMask()) before it completes. (If it didn't, then when the kernel issued the EOI to the PIC, the PIC would then immediately reissue a processor interrupt and the kernel would loop forever, continually calling your ISR code.)

In an edge-triggered environment, there's no such requirement, because the interrupt won't be noticed again until it transits from clear to asserted.

In general, to actually service the interrupt, your ISR has to do very little; the minimum it can get away with is to clear the source of the interrupt and then schedule a thread to actually do the work of handling the interrupt. This is the recommended approach, for a number of reasons:

Context-switch times between the ISR completing and a thread executing are very small—typically on the order of a few microseconds.
The type of functions that the ISR itself can execute is very limited (those that don't call any kernel functions, except the ones listed below).
The ISR runs at a priority higher than any software priority in the system—having the ISR consume a significant amount of processor has a negative impact on the realtime aspects of the QNX Neutrino RTOS.

Note:

Since the range of hardware attached to an interrupt source can be very diverse, the specific how-to's of servicing the interrupt are beyond the scope of this document—this really depends on what your hardware requires you to do.

Page updated: March 12, 2026