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.
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.
Short delays

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.
      - Short delays
      - Oversleeping: errors in delays
        The tick size becomes important just about every time you ask the kernel to do something related to pausing or delaying your process.
      - Another hiccup with hardware timers
      - What time is it?
        QNX Neutrino maintains two clocks in the system: one is a monotonic count of time since the kernel was initialized (CLOCK_MONOTONIC), and the other is a wall-clock time since January 1st, 1970 (CLOCK_REALTIME).
      - Reducing the power consumption of clocks and timers
        If your system needs to manage power consumption, you can set up your timers to help the system to sleep for longer intervals, saving power.
      - Tolerant and high-resolution timers
        You can use timer tolerance to specify how strictly the kernel should enforce a timer's expiry time.
      - Monitoring execution times
        QNX Neutrino includes some special CPU-time clocks that you can use to monitor the execution times for processes and threads.
    - 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
    - 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.

Short delays

If you need a pause, use delay() or the POSIX clock_nanosleep().

If you need a very short delay (e.g., for accessing hardware), you should look at the nanospin*() functions:

They basically do a while loop to a calibrated number of iterations to delay the proper amount of time. This wastes CPU, so you should use these functions only if necessary.

Page updated: March 12, 2026