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
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.
Interrupts
In this chapter, we'll take a look at interrupts, how we deal with them under QNX Neutrino, their impact on scheduling and realtime, and some interrupt-management strategies.
Writing interrupt handlers
Let's see how to set up interrupt handlers—the calls, the characteristics, and some strategies.
The interrupt service routine
Let's look at the ISR itself. In the first example, we'll look at using the InterruptAttach() function. Then, we'll see the exact same thing, except with InterruptAttachEvent().
The tradeoffs
So, which function should you use? For low-frequency interrupts, you can almost always get away with InterruptAttachEvent(). Since the interrupts occur infrequently, there won't be a significant impact on overall system performance, even if you do schedule threads unnecessarily. The only time that this can come back to haunt you is if another device is chained off the same interrupt—in this case, because InterruptAttachEvent() masks the source of the interrupt, it'll effectively disable interrupts from the other device until the interrupt source is unmasked. This is a concern only if the first device takes a long time to be serviced. In the bigger picture, this is a hardware system design issue—you shouldn't chain slow-to-respond devices on the same line as high-speed devices.

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.
    - Processes and Threads
    - Message Passing
      In this chapter, we'll look at the most distinctive feature of QNX Neutrino, message passing. Message passing lies at the heart of the operating system's microkernel architecture, giving the OS its modularity.
    - Clocks, Timers, and Getting a Kick Every So Often
      It's time to take a look at everything related to time in the QNX Neutrino RTOS. We'll see how and why you'd use timers and the theory behind them. Then we'll take a look at getting and setting the realtime clock.
    - Interrupts
      In this chapter, we'll take a look at interrupts, how we deal with them under QNX Neutrino, their impact on scheduling and realtime, and some interrupt-management strategies.
      - QNX Neutrino and interrupts
        The first thing we need to ask is, What's an interrupt?
      - Writing interrupt handlers
        Let's see how to set up interrupt handlers—the calls, the characteristics, and some strategies.
        Attaching an interrupt handler
        To attach to an interrupt source, you'd use either InterruptAttach() or InterruptAttachEvent().
        Now that you've attached an interrupt
        At this point, you've called either InterruptAttachEvent() or InterruptAttach().
        Detaching an interrupt handler
        When done with the ISR, we may wish to break the association between the ISR and the interrupt vector:
        The flags parameter
        The last parameter, flags, controls all kinds of things:
        The interrupt service routine
        Let's look at the ISR itself. In the first example, we'll look at using the InterruptAttach() function. Then, we'll see the exact same thing, except with InterruptAttachEvent().
        Using InterruptAttach()
        Continuing our example, here's the ISR intHandler(). It looks at the 8250 serial port chip that we assume is attached to HW_SERIAL_IRQ:
        Using InterruptAttachEvent()
        If we were to recode the example above to use InterruptAttachEvent(), it would look like this:
        InterruptAttach() versus InterruptAttachEvent()
        This naturally brings us to the question, Why would I use one over the other?
        The tradeoffs
        So, which function should you use? For low-frequency interrupts, you can almost always get away with InterruptAttachEvent(). Since the interrupts occur infrequently, there won't be a significant impact on overall system performance, even if you do schedule threads unnecessarily. The only time that this can come back to haunt you is if another device is chained off the same interrupt—in this case, because InterruptAttachEvent() masks the source of the interrupt, it'll effectively disable interrupts from the other device until the interrupt source is unmasked. This is a concern only if the first device takes a long time to be serviced. In the bigger picture, this is a hardware system design issue—you shouldn't chain slow-to-respond devices on the same line as high-speed devices.
        ISR functions
        The next issue we should tackle is the list of functions an ISR is allowed to call.
      - Summary
        Keep the following things in mind when dealing with interrupts:
    - Resource Managers
      In this chapter, we'll take a look at what you need to understand in order to write a resource manager. Resource managers are another distintive feature of QNX Neutrino that allow you to access services through standard POSIX calls.
    - Sample Programs
      This appendix contains the complete versions of some of the sample programs discussed in this book.
    - Glossary
  - 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.
  - 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.

The tradeoffs

So, which function should you use? For low-frequency interrupts, you can almost always get away with InterruptAttachEvent(). Since the interrupts occur infrequently, there won't be a significant impact on overall system performance, even if you do schedule threads unnecessarily. The only time that this can come back to haunt you is if another device is chained off the same interrupt—in this case, because InterruptAttachEvent() masks the source of the interrupt, it'll effectively disable interrupts from the other device until the interrupt source is unmasked. This is a concern only if the first device takes a long time to be serviced. In the bigger picture, this is a hardware system design issue—you shouldn't chain slow-to-respond devices on the same line as high-speed devices.

For higher-frequency interrupts, it's a toss up, and there are many factors:

Unnecessary interrupts—if there will be a significant number of these, you're better off using InterruptAttach() and filtering them out in the ISR. For example, consider the case of a serial device. A thread may issue a command saying Get me 64 bytes. If the ISR is programmed with the knowledge that nothing useful will happen until 64 bytes are received from the hardware, the ISR has effectively filtered the interrupts. The ISR will then return an event only after 64 bytes have been accumulated.
Latency—if your hardware is sensitive to the amount of time that passes between asserting the interrupt request and the execution of the ISR, you should use InterruptAttach() to minimize this interrupt latency. This is because the kernel is very fast at dispatching the ISR.
Buffering—if your hardware has buffering in it, you may be able to get away with InterruptAttachEvent() and a single-entry queueing mechanism like SIGEV_INTR and InterruptWait(). This method lets the hardware interrupt as often as it wants, while letting your thread pick the values out of the hardware's buffer when it can. Since the hardware is buffering the data, there's no problem with interrupt latencies.

Page updated: March 12, 2026