The most important reason why you might consider using a traditional RTOS kernel for executing event-driven QP/C++ applications is compatibility with the existing software. For example, most 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 conventional RTOS allows you to run the existing software components as regular "blocking" tasks in parallel to the event-driven QP/C++ application.

Another reason you might be interested in running QP/C++ on top of a conventional RTOS is safety certification, which your RTOS kernel might have but the built-in QP kernels currently don't provide.

Note: You do not need to use a traditional RTOS just to achieve preemptive multitasking with QP. The preemptive QK kernel, available as part of the QP package, supports preemptive priority-based multitasking and is fully compatible with Rate Monotonic Scheduling to achieve guaranteed, hard real-time performance. The preemptive, run-to-completion QK kernel perfectly matches the run-to-completion execution semantics of active objects, yet it is simpler, faster, and more efficient than any traditional blocking kernel.

Attention: QP/C++ 6.x includes a small, preemptive, priority-based, dual-mode blocking QXK kernel that executes active objects like the QK kernel (basic threads), but can also execute traditional blocking threads (extended threads). In this respect, QXK behaves exactly like a conventional RTOS. The QXK kernel is recommended as the preferred RTOS kernel for applications that need to mix active objects with traditional blocking code. Due to the tight and optimal integration between QXK and the rest of QP, QXK offers better performance and smaller memory footprint than any QP port to a 3rd-party RTOS. Additionally, QXK is already included in QP, so you avoid additional licensing costs of 3rd-party kernels.

The QP/C++ framework can work with virtually any traditional real-time operating system (RTOS). The currently supported 3rd-party RTOS kernels are:

Combined with a conventional RTOS, QP/C++ takes full advantage of the multitasking capabilities of the RTOS by executing each active object in a separate RTOS task. The QP/C++ Platform Abstraction Layer (PAL) includes an abstract RTOS interface to enable integration between QP/C++ and the underlying RTOS. Specifically, the PAL allows adapting most message queue variants as event queues of active objects as well as most memory partitions as QP/C++ event pools.

embOS