Home
QNX Software Development Platform
Programming
Programmer's Guide
The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
Handling Hardware Interrupts
This chapter explains the QNX OS mechanisms for quickly reacting to hardware events.
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.

QNX Momentics IDE User's Guide
QNX Software Development Platform
- Quickstart Guide
- System Architecture
  The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
- OS Components
- Graphics
- Programming
  - Getting Started with the QNX OS
    Getting Started with the QNX OS: A Guide for Realtime Programmers is intended to introduce you to the QNX OS and help you develop applications and resource managers for it.
  - Programmer's Guide
    The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
    - Compiling and Debugging
      Let's start by looking at some things you should consider when you start to write a program for the QNX OS.
    - QNX OS Architecture and Concepts
      The QNX OS architecture consists of the microkernel and several cooperating processes. These processes communicate with each other via various forms of interprocess communication (IPC). Message passing is the primary form of IPC in QNX OS.
    - Processes
      Your applications should be written in a way that reflects the architecture of the QNX OS—as a set of cooperating processes. In this chapter, we see how to start processes (also known as creating processes) from code, how to terminate them, and how to detect their termination.
    - Multicore Processing
      Multiprocessing systems, whether discrete or multicore, can greatly improve your applications' performance.
    - 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.
    - Handling Hardware Interrupts
      This chapter explains the QNX OS mechanisms for quickly reacting to hardware events.
      - Attaching and detaching interrupts
        In order to handle interrupts, the software must tell the OS that it wants to associate a thread or an event with a particular source of interrrupts, a hardware interrupt request (IRQ).
      - Interrupt Service Thread (IST)
      - 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.
    - Working with Memory
      (or The Persistence of Memory, with a nod to Salvador Dali) In the Process Manager chapter of the System Architecture guide, we looked at how the OS manages memory. This chapter describes how you can work with memory.
    - Freedom from Hardware and Platform Dependencies
      The QNX OS can run on many different hardware platforms. The way in which applications can access peripheral devices and how data is stored varies between platforms. This chapter explains our solutions for minimizing the impact of such platform dependencies.
    - Conventions for Recursive Makefiles and Directories
      In this chapter, we'll look at the supplementary files used in the QNX OS development environment. Although we use the standard make command to create libraries and executables, we also use some of our own conventions in the Makefile syntax.
    - Glossary
  - Writing a Resource Manager
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX OS system and developers who want to create a QNX OS resource manager free from vulnerabilities.
- Utilities & Libraries
- Migrating to QNX OS 8.0
QNX Software in the Cloud
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX OS applications and systems.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

Problems with shared interrupts

QNX SDP8.0Programmer's GuideDeveloper

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.

Sharing interrupts can decrease your performance, because when the interrupt fires, all of the devices sharing the interrupt need to run and check to see if it's for them. Sharing interrupts can increase interrupt latency, depending upon exactly what each of the drivers does. After an interrupt fires, the kernel doesn't unmask the IRQ until all driver handlers tell the kernel that they've finished handling it. If one driver takes a long time servicing a shared interrupt that's masked, and another device on the same interrupt causes an interrupt during that time period, the processing of that interrupt can be delayed for an unknown length of time.

Page updated: May 17, 2024