QP (framework)
Developer | Quantum Leaps |
---|---|
Written in | QP/C and QP-nano in C, QP/C++ in C++ |
OS family | Framework / RTOS |
Working state | Mature |
Source model | Open source |
Marketing target | Embedded systems |
Update method | Company website |
License | GPL and Commercial (Dual licensing) |
Official website | state-machine.com |
QP (Quantum Platform) is a family of lightweight, open source software frameworks for building responsive and modular real-time embedded applications as systems of cooperating, event-driven active objects (actors).
Overview
The QP family consists of QP/C, QP/C++, and QP-nano frameworks, which are all quality controlled, documented,[1] and commercially licensable.
All QP frameworks can run on "bare-metal" single-chip microcontrollers, completely replacing a traditional Real-Time Operating System (RTOS). Ports and ready-to-use examples are provided for all major CPU families. QP/C and QP/C++ can also work with a traditional OS/RTOS, such as: POSIX (Linux, QNX), Windows, VxWorks, ThreadX, MicroC/OS, FreeRTOS, etc.
The behavior of active objects (actors) is specified in QP by means of hierarchical state machines (UML statecharts). The frameworks support manual coding of UML state machines in C or C++ as well as fully automatic code generation by means of the free graphical QM modeling tool.[2]
The QP frameworks and the QM modeling tool are used in medical devices, defense & aerospace, robotics, consumer electronics, wired and wireless telecommunication, industrial automation, transportation, and many more.
Background
Active objects inherently support and automatically enforce the following best practices of concurrent programming:[3]
- Keep all of the task's data local, bound to the task itself and hidden from the rest of the system.
- Communicate among tasks asynchronously via intermediary event objects. Using asynchronous event posting keeps the tasks running truly independently without blocking on each other.
- Tasks should spend their lifetime responding to incoming events, so their mainline should consist of an event loop.
- Tasks should process events one at a time (to completion), thus avoiding any concurrency hazards within a task itself.
Active objects dramatically improve your ability to reason about the concurrent software. In contrast, using raw RTOS tasks directly is trouble for a number of reasons, particularly because raw tasks let you do anything and offer you no help or automation for the best practices.[4] As with all good patterns, active objects raise the level of abstraction above the naked threads and let you express your intent more directly thus improving your productivity.
Active objects cannot operate in a vacuum and require a software infrastructure (framework) that provides, at a minimum: an execution thread for each active object, queuing of events, and event-based timing services. In the resource-constrained embedded systems, the biggest concern has always been about scalability and efficiency of such frameworks, especially that the frameworks accompanying various modeling tools have traditionally been built on top of a conventional RTOS, which adds memory footprint and CPU overhead to the final solution.
The QP frameworks have been designed for efficiency and minimal footprint from the ground up and do not need an RTOS in the stand-alone configuration. In fact, when compared to conventional RTOSes, QP frameworks provide smaller footprint especially in RAM (data space), but also in ROM (code space). This is possible, because active objects don't need to block, so most blocking mechanisms (e.g., semaphores) of a conventional RTOS are not needed.
All these characteristics make event-driven active objects a perfect fit for single-chip microcontrollers (MCUs). Not only do you get the productivity boost by working at a higher level of abstraction than raw RTOS tasks, 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 chip in a low-power sleep mode.
QP Architecture and Components
QP consists of a universal UML-compliant event processor (QEP), a portable, event-driven, real-time framework (QF), a tiny run-to-completion kernel (QK), and software tracing system (QS).
QEP (Quantum Event Processor) is a universal UML-compliant event processor that enables direct coding of UML state machines (UML statecharts) in highly maintainable C or C++, in which every state machine element is mapped to code precisely, unambiguously, and exactly once (traceability). QEP fully supports hierarchical state nesting, which enables reusing behavior across many states instead of repeating the same actions and transitions over and over again.
QF (Quantum Framework) is a highly portable, event-driven, real-time application framework for concurrent execution of state machines specifically designed for real-time embedded systems.
QK (Quantum Kernel) is a tiny preemptive non-blocking run-to-completion kernel designed specifically for executing state machines in a run-to-completion (RTC) fashion.
QS (Quantum Spy) is a software tracing system that enables live monitoring of event-driven QP applications with minimal target system resources and without stopping or significantly slowing down the code.
Supported Processors
All types of QP frameworks (QP/C, QP/C++, and QP-nano) can be easily adapted to various microprocessor architectures and compilers. Adapting the QP software is called porting and all QP frameworks have been designed from ground up to make the porting easy.
Currently, bare-metal QP ports exist for the following processor architectures:
- ARM Cortex-M4F (TI Stellaris)
- ARM Cortex-M3 (TI Stellaris, ST STM32, NXP LPC)
- ARM Cortex-M0 (NXP LPC1114)
- ARM7/9 (Atmel AT91R4x, AT91SAM7, NXP LPC, ST STR912)
- Atmel AVR Mega
- Atmel AVR32 UC3-A3
- TI MSP430
- TI TMS320C28x
- TI TMS320C55x
- Renesas Rx600
- Renesas R8C
- Renesas H8
- Freescale Coldfire
- Freescale 68HC08
- Altera Nios II
- 8051 (Silicon Labs)
- 80251 (Atmel)
- Microchip PIC24/dsPIC
- Cypress PSoC1
- 80x86 real mode
Supported Operating Systems
The QP/C and QP/C++ frameworks can also work with the traditional operating systems and RTOSes.
Currently, QP ports exist for the following OSes/RTOSes:
- Linux (POSIX)
- Win32 (all desktop Windows and WindowsCE)
- VxWorks
- ThreadX
- FreeRTOS
- MicroC/OS-II
- QNX (POSIX)
- Integrity (POSIX)
Licensing
All QP framework types are dual-licensed under the open source GPLv2 and a traditional, closed-source license. Users who want to distribute QP (e.g. embedded inside user upgradable devices) can retain the proprietary status of their code for a fee. Several types of commercial, royalty-free, closed-source licenses are available.
See also
References
- ↑ Samek, Miro (2008). Practical UML Statecharts in C/C++, Second Edition: Event-Driven Programming for Embedded Systems. Newnes. p. 728. ISBN 978-0-7506-8706-5.
- ↑ "free graphical QM modeling tool".
- ↑ Herb Sutter (March 16, 2009). "Use Threads Correctly = Isolation + Asynchronous Messages".
- ↑ Herb Sutter (June 14, 2010). "Prefer Using Active Objects Instead of Naked Threads".
External links
- state-machine.com
- QP project on SourceForge.net
- qf4net: Quantum Framework for .Net
- qfj: Quantum Framework for Java on SourceForge.net
- Miros: a hierarchical state machine module in Python
- Miros: a hierarchical state machine module in Lua
- State-Oriented Programming (Groovy)
- ACCU Overload Journal #64 "Yet Another Hierarchical State Machine"
- C/C++ Users Journal "Who Moved My State?"
- C/C++ Users Journal "Deja Vu"
- Research on Open CNC System Based on Quantum Framework
- Active Objects by Schmidt