Active Objects for Real-Time
The main difference between an RTOS and RTEF is that when you use a “naked” RTOS, you write the main body of each and every thread in the application and from there, you call the various RTOS services (e.g., a time-delay or a semaphore).
When you use an RTEF, you reuse the overall architecture (such as the event loop for all private threads of Active Objects) and you only write the code that the RTEF calls. This leads to inversion of control, which allows the RTEF to automatically enforce the best practices of concurrent programming. In contrast, a “naked” RTOS lets you do anything and offers no help or automation for the best practices.
Smaller than Traditional RTOS
In the resource-constrained embedded systems, the biggest concern has always been about the size and efficiency of such RTEFs, especially that the frameworks accompanying various UML tools have traditionally been built on top of a conventional RTOS, which can only add memory footprint and CPU overhead to the final solution.
However, it turns out that an RTEF can be actually smaller than a traditional RTOS. This is possible, because Active Objects don’t need to block internally, so most blocking mechanisms (e.g., semaphores) of a conventional RTOS are not needed.
Preemptive, Non-Blocking Real-Time Kernels
While the Active Object model can work with traditional blocking RTOS kernels, it can also work with other types of real-time kernels. Specifically, the non-blocking, run-to-completion Active Objects can work with a much simpler, fully preemptive, but non-blocking, run-to-completion kernels (see also basic tasks in OSEK/VDX).
The QP RTEFs natively include a selection of such a super-simple and super-fast kernels (QK and QXK), which support fully preemptive multithreading using a single stack for all Active Object threads.
Higher Level of Abstraction at Lower Cost
Not only you get the productivity boost by working at a higher level than “naked” RTOS threads, but you get it at a lower resource utilization and better power efficiency, because event-driven systems use the CPU only when processing events and otherwise can put the MCU in a low-power sleep mode.