QP real-time embedded framework (RTEF)

 QP™ Real-Time Embedded Frameworks (RTEFs)

QP™ (Quantum Platform) is a family of lightweight real-time embedded frameworks (RTEFs) for building event-driven, embedded software based on the Active Object design pattern. The QP family consists of the QP/C and QP/C++ frameworks, which are strictly quality controlled, thoroughly documented, and available under the flexible dual licensing model.

Home » Products » QP™ Frameworks

share on:
Share on reddit
Share on linkedin
Share on twitter
Share on email

Real-Time Embedded Frameworks for MCUs

The QP/C and QP/C++ real-time embedded frameworks (RTEFs) provide lightweight, reusable software architecture that combines the event-driven model of concurrency, known as active objects (actors), with hierarchical state machines. This architecture inherently supports and automatically enforces the best practices of concurrent programming. This results in applications that are safer, more responsive, and easier to manage than the naked threads and the myriad of blocking mechanisms of a traditional Real-Time Operating System (RTOS). The QP frameworks also provide a sufficiently high level of abstraction to effectively apply graphical modeling and code generation to deeply embedded systems, such as microcontrollers based on ARM Cortex-M.

The most important difference between a toolkit (e.g., RTOS) and a framework (e.g., QP RTEF) is the inversion of control. When you use a traditional RTOS, you write the main body of each thread and you call the code from the RTOS (such as a semaphore, time delay, etc.) In contrast, when you use a framework, you reuse the whole architecture and write the code that it calls. This inversion of control is the main mechanism for the architectural-reuse and enforcement of the policies of the framework.

QP framework block diagram
Block diagram showing the components of the QP™ framework and their relationship to the hardware and the application

QP™ Highlights


QP™ applications consisting of event-driven active objects consume less memory, especially RAM, than equivalent solutions based on traditional RTOS threads.

Hard Real-Time

QP™ RTEFs combined with a preemptive, priority-based kernel are suitable for hard real-time applications. In fact, the non-blocking active objects are better suited for the RMS/RMA methods than the traditional blocking RTOS threads.

Market Leadership

With 15+ years of continuous refinement, the QP™ frameworks are the most established and popular offering of this type on the embedded software market.

Support for Modern State Machines

The behavior of active objects is specified in QP/C and QP/C++ by means of hierarchical state machines (UML statecharts). The QP frameworks support manual coding of UML state machines in C (QP/C) or C++ (QP/C++) as well as Model-Based Design (MBD) and automatic code generation by means of the free QM™ Model-Based Design tool.

Standalone (Bare-Metal) Operation

The QP™ RTEFs can run standalone, completely replacing the traditional RTOS. The frameworks contain a selection of built-in real-time kernels, such as the cooperative QV kernel, the preemptive non-blocking QK kernel, and the unique preemptive, dual-mode (blocking/non-blocking) QXK kernel. Standalone QP ports and ready-to-use examples are provided for ARM Cortex-M (M0-M7) as well as other CPUs.

You do not need to use a traditional RTOS just to achieve preemptive multitasking with QP. The built-in, preemptive QK and QXK kernels, support preemptive priority-based multitasking that is fully compatible with Rate Monotonic Scheduling to achieve guaranteed, hard real-time performance. These preemptive kernels perfectly match the run-to-completion execution semantics of active objects, yet are simpler, faster, and more efficient than the traditional blocking RTOS kernels.

Example Evaluation Boards

Traditional RTOS Support

The QP™ RTEFs can also work with many traditional third-party RTOSes. QP ports and ready-to-use examples are provided for several RTOSes (such as FreeRTOS, embOS, ThreadX, MicroC/OS, etc.)

The most important reason why you might consider using a traditional RTOS kernel for executing event-driven QP™ applications is compatibility with the existing software. For example, many communication stacks (TCP/IP, USB, CAN, etc.) are designed for a traditional blocking kernel. In addition, a lot of legacy code requires blocking mechanisms, such as semaphores or time-delays. A traditional RTOS allows you to run the existing software components as regular “blocking” threads in parallel to the event-driven QP™ active objects.

General Purpose OS Support

The QP™ RTEFs can also work with general purpose OSes, such as Linux (POSIX), Windows, and macOS.

The QP™ ports to the general purpose operating systems are interesting in their own right. For example, the QP port to POSIX supports real-time extensions and works with embedded Linux, and POSIX subsystems of such RTOSes as QNX, INTEGRITY, VxWorks, etc. Similarly, QP port to Windows can work with Windows IoT or Windows Embedded Compact.

But the OS support can be also interesting for developing of deeply embedded code on the desktop workstations, which is called “dual-targeting”.

QP/C and QP/C++ Feature Comparison

Most Recent Version (Revision History)
Latest Release Date
Intended target systems
(Representative hardware)
32-bit/16-bit MCUs
(ARM Cortex-M)
32-bit/16-bit MCUs
(ARM Cortex-M)
Supported by the free QM™ Model-Based Design tool
Maximum number of active objects6464
Dynamic events with arbitrary parameters
Automatic event recycling
Direct event posting (FIFO)
Direct event posting (LIFO)
Publish-Subscribe event delivery
Event deferral
Number of system clock tick ratesconfigurable (0..15)configurable (0..15)
Number of time events per active objectUnlimitedUnlimited
----------------------------------------------- State Machines -----------------------------------------------
Hierarchical State Machines (QHsm-strategy)
Hierarchical State Machines (QMsm-strategy)
Sub-machines and sub-machine states
----------------------------------------------- Built-in Kernels -----------------------------------------------
Preemptive non-blocking kernel (QK)
Preemptive blocking dual-mode kernel (QXK)
----------------------------------------------- 3rd-Party RTOS/OS -----------------------------------------------
Portable to 3rd-party RTOS kernels
Available port to POSIX (Linux, QNX, INTEGRITY, etc.)
Available port to Windows
----------------------------------------------- Testing/Profiling -----------------------------------------------
QP/Spy™ software tracing
QUTest™ Unit Testing Harness
MISRA complianceMISRA-C:2004
AUTOSAR-C++ complianceAUTOSAR-C++ 14
PC-Lint-Plus support package
-----------------------------------------------Licensing -----------------------------------------------
Open Source Licensing (GPL)
Closed Source (Commercial) Licensing

Legacy QP™ Development Kits (QDKs)

QP Development Kits (QDKs) were separate QP ports and examples for various embedded processors, toolsets and boards.

Why "Legacy"?

Starting with QP release 5.4.0, all officially supported ports and examples are bundled into the QP downloads, as opposed to being distributed as separate QP Development Kits (QDKs). The QDKs released for earlier QP versions are called “legacy-QDKs” and are available for download from SourceForge.

The "legacy-QDKs" are not recommended for new projects. The "legacy-QDKs" do not come with commercial support from Quantum Leaps, although questions about "legacy-QDKs" are welcome on the Free QP Support Forum

How to Find QDK You Want?

All “legacy QDKs” are distributed in ZIP archives named according to the following general convention:

  • qdkxxx denotes the QP framework type, whereas qdkc stands for QDK for QP/C, qdkcpp for QP/C++, and qdkn for QP-nano
  • <cpu> denotes a QDK for standalone QP for the given embedded CPU type, such as AVR, M16C, R8C, etc.
  • <rtos> denotes a QDK for QP running on top of a given RTOS, such as eCos, VxWorks, etc.
  • <toolset> denotes a port to specific toolset, such a IAR, GNU, Renesas, etc.
  • <board> denotes that the examples are for the specified boards, such as SKP3607, YRDKRX62N, etc.
  • <version> denotes the compatible version of the QP framework.

All QDKs have been developed and tested with the specified <version> of the QP framework. A QDK might work with the newer QP version as well, but might require some modifications.

QDK Installation

The installation procedure for most “legacy QDKs” is as follows:

  1. Download the QDK that you like and check its <version> number.
  2. Download and install (unzip) the corresponding QP <version>. For example, if your QDK file starts with qdkcpp_ and ends with _4.5.02, you should download and install QP/C++ version 4.5.02.
  3. Unzip the QDK to a temporary directory.
  4. Copy the contents of the QDK directory to the QP installation directory. For example, if your QDK unzipped into directory qdkcpp_avr-iar_4.5.02, you should copy the content of this directory inside the QP/C++ installation folder (typically, inside C:/qp/qpcpp/). Note that you will need to give your consent to overwrite the already existing directories examples/ and ports/.

QDK Documentation

Every “legacy QDK” contains the “QDK Manual” in PDF in the main directory of the ZIP archive.