mirror of
https://github.com/QuantumLeaps/qpcpp.git
synced 2025-01-28 06:02:56 +08:00
6.5.0
This commit is contained in:
QL
parent
9594239263
commit
f40f0bab45
@ -8,9 +8,9 @@ To check what's new in QP/C++, please see @ref history "QP/C++ Revision History"
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
@section ab_about What is it?
|
||||
<a class="extern" target="_blank" href="https://www.state-machine.com/products/"><strong>QP/C++™ (Quantum Platform in C++)</strong></a> is a lightweight <a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#RTEF"><strong>Real-Time Embedded Framework (RTEF)</strong></a> for building modern, responsive and modular real-time embedded applications as systems of asynchronous event-driven <a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#Active"><strong>active objects</strong></a> (<a href="http://en.wikipedia.org/wiki/Actor_model">actors</a>). The QP/C++™ framework is a member of a larger family consisting of QP/C++, <a href="https://www.state-machine.com/qpc" target="_blank" class="extern">QP/C</a>, and <a href="https://www.state-machine.com/qpn" target="_blank" class="extern">QP-nano</a> frameworks, which are all strictly quality controlled, thoroughly documented, and available under @ref licensing "dual licensing model".
|
||||
<a class="extern" target="_blank" href="https://www.state-machine.com/products/"><strong>QP/C++™ (Quantum Platform in C++)</strong></a> is a lightweight <a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#RTEF"><strong>Real-Time Embedded Framework (RTEF)</strong></a> for building modern, responsive and modular real-time embedded applications as systems of asynchronous event-driven <a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#Active"><strong>active objects</strong></a> (<a href="http://en.wikipedia.org/wiki/Actor_model">actors</a>). QP/C++™ is a member of a larger family of real-time embedded frameworks (RTEFs) consisting of QP/C++, <a href="https://www.state-machine.com/qpc" target="_blank" class="extern">QP/C</a>, and <a href="https://www.state-machine.com/qpn" target="_blank" class="extern">QP-nano</a> frameworks, which are all strictly quality controlled, thoroughly documented, and available under @ref licensing "dual licensing model".
|
||||
|
||||
The behavior of active objects is specified in QP/C++ by means of <a href="https://www.state-machine.com/doc/concepts#HSM" target="_blank" class="extern"><strong>hierarchical state machines</strong></a> (UML statecharts). The framework supports manual coding of UML state machines in C as well as automatic code generation by means of the free <a href="https://www.state-machine.com/qm"><strong>QM™ modeling tool</strong></a>.
|
||||
The behavior of active objects is specified in QP/C++ by means of <a href="https://www.state-machine.com/doc/concepts#HSM" target="_blank" class="extern"><strong>hierarchical state machines</strong></a> (UML statecharts). The framework supports @ref sm "manual coding of UML state machines in C++" as well as automatic code generation by means of the free <a href="https://www.state-machine.com/qm"><strong>QM™ model-based design tool</strong></a>.
|
||||
|
||||
@attention
|
||||
To use QP/C++™ effectively, you need to understand the <a href="https://www.state-machine.com/doc/concepts" target="_blank" class="extern"><strong>key concepts</strong></a> that underline the architecture of the framework and your applications based on the framework.
|
||||
@ -26,19 +26,19 @@ To use QP/C++™ effectively, you need to understand the <a href="https://ww
|
||||
@section ab_goals What does it do?
|
||||
The main goals of the QP/C++™ framework are:
|
||||
- to provide a reusable **architecture** based on <a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#Framework">active objects (actors)</a>, which is _safer_ and easier to understand than "free-threading" with a traditional RTOS.
|
||||
- to provide a simple-to-use coding techniques for <a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#HSM">hierarchical state machines</a>, with which to implement the behavior of active objects.
|
||||
- to provide a simple-to-use coding techniques for @ref sm "hierarchical state machines", with which to implement the behavior of active objects.
|
||||
- to provide efficient and thread-safe event-driven mechanisms for active objects to communicate, such as direct event passing and publish-subscribe.
|
||||
- to provide event-driven timing services (time events).
|
||||
- to provide a selection of built-in real-time kernels to run the QP applications, such as the cooperative @ref qv "QV kernel", the preemptive non-blocking @ref qk "QK kernel", and the preemptive blocking @ref qxk "QXK kernel".
|
||||
- to provide testing support for applications based on software tracing (@ref qs "Q-Spy").
|
||||
- to provide portability layer and ready-to-use ports to @ref ports_rtos "3rd-party RTOSes" and desktop operating systems such as @ref posix "Linux" and @ref win32 "Windows".
|
||||
- to provide a target for modeling and automatic code generation from the <a href="https://www.state-machine.com/qm" target="_blank" class="extern">QM modeling tool</a>.
|
||||
- to provide portability layer and ready-to-use ports to @ref ports_rtos "3rd-party RTOSes" and desktop operating systems such as @ref win32 "Windows", @ref posix "Linux" and @ref macos "macOS".
|
||||
- to provide a target for modeling and automatic code generation from the <a href="https://www.state-machine.com/qm" target="_blank" class="extern">QM™ model-based design (MBD) tool</a>.
|
||||
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
@section ab_special What's special about it?
|
||||
|
||||
The QP/C++™ Real-Time Embedded Framework (RTEF) is a unique offering on the embedded software market. It provides a modern, reusable **architecture** of embedded applications, which combines object-orientation with the particular model of concurrency, known as <a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#Active"><strong>active objects</strong></a> (actors). This architecture is generally **safer**, more responsive and easier to understand than "free threading" with a traditional Real-Time Operating System (RTOS). It also provides sufficiently high level of abstraction and the right abstractions to effectively apply modeling and code generation to deeply embedded systems.
|
||||
The QP/C++™ Real-Time Embedded Framework (RTEF) is a unique offering on the embedded software market. It provides a modern, reusable **architecture** of embedded applications, which combines object-orientation and @ref sm "hierarchical state machines" with the particular model of concurrency, known as <a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#Active"><strong>active objects</strong></a> (actors). This architecture is generally **safer**, more responsive and easier to understand than "free threading" with a traditional Real-Time Operating System (RTOS). It also provides sufficiently high level of abstraction and the right abstractions to effectively apply modeling and code generation to deeply embedded systems.
|
||||
|
||||
|
||||
<div class="separate"></div>
|
||||
@ -48,16 +48,16 @@ QP/C++™ is fundamentally an **object-oriented** framework, which means tha
|
||||
|
||||
<div class="separate"></div>
|
||||
@subsection lightweight Lightweight
|
||||
The most unique characteristic of the QP/C++™ framework is its very small footprint, especially in RAM. In this respect, QP/C++™ requires less resources than even the smallest conventional Real-Time Operating System (RTOS) kernel. At the same time, QP gives you a much higher level of abstraction than a conventional RTOS. With QP, you work at the level of active objects, state machines and events, as opposed to "naked" threads of an RTOS.
|
||||
The most unique characteristic of the QP/C++™ framework is its very small footprint, especially in RAM. In this respect, QP/C++™ requires less resources than even the smallest conventional Real-Time Operating System (RTOS) kernel. At the same time, QP/C++ gives you a much higher level of abstraction than a conventional RTOS. With QP, you work at the level of active objects, state machines and events, as opposed to "naked" threads of an RTOS.
|
||||
|
||||
|
||||
<div class="separate"></div>
|
||||
@subsection hsms Hierarchical State Machines
|
||||
The behavior of active objects is specified in QP by means of
|
||||
<a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#HSM">hierarchical state machines (UML statecharts)</a>. 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 <a class="extern" target="_blank" href="https://www.state-machine.com/qm">QM™ modeling tool</a>.
|
||||
The behavior of active objects is specified in QP/C++ by means of
|
||||
<a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#HSM">hierarchical state machines (UML statecharts)</a>. The framework supports @ref sm "manual coding of UML state machines in C++" as well as fully automatic code generation by means of the free graphical <a class="extern" target="_blank" href="https://www.state-machine.com/qm">QM™ model-based design (MBD) tool</a>.
|
||||
|
||||
@remarks
|
||||
State machines can be an incredibly powerful technique, but they require an event-driven **infrastructure** (framework) that provides, at a minimum: a run-to-completion (RTC) execution context for each state machine, queuing of events, and event-based timing services. This is really the pivotal point. Without an event-driven framewok (like QP/C++), state machines are like <a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#Infrastructure">cars without an infrastructure of roads</a>.
|
||||
State machines can be an incredibly powerful technique, but they require an event-driven **infrastructure** (framework) that provides, at a minimum: a run-to-completion (RTC) execution context for each state machine, queuing of events, and event-based timing services. This is really the pivotal point. Without an event-driven framework (like QP/C++), state machines are like <a class="extern" target="_blank" href="https://www.state-machine.com/doc/concepts#Infrastructure">cars without an infrastructure of roads</a>.
|
||||
|
||||
|
||||
<div class="separate"></div>
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
License Type: Windows Single User License
|
||||
Licensed To : Quantum Leaps, LLC
|
||||
License No. : WS2975 License Date: Dec 15, 2013
|
||||
Build Date : Sep 2 2009 Run Date: Apr 11, 2019
|
||||
Build Date : Sep 2 2009 Run Date: Apr 25, 2019
|
||||
(C)1996-2009 M Squared Technologies LLC
|
||||
________________________________________________________________________
|
||||
|
||||
|
||||
@ -530,10 +530,14 @@ QS_SIG_DICTIONARY(DESTROYED_MINE_SIG, this);
|
||||
<state_glyph node="4,10,26,8"/>
|
||||
</state>
|
||||
<state name="flying">
|
||||
<entry>m_score = 0U; /* reset the score */
|
||||
<entry>m_score = 0U; // reset the score
|
||||
ScoreEvt *sev = Q_NEW(ScoreEvt, SCORE_SIG);
|
||||
sev->score = m_score;
|
||||
AO_Tunnel->POST(sev, this);</entry>
|
||||
AO_Tunnel->POST(sev, this);
|
||||
|
||||
// lauch the ship from the initial position
|
||||
m_x = GAME_SHIP_X;
|
||||
m_y = (GAME_SHIP_Y << 2);</entry>
|
||||
<tran trig="TIME_TICK">
|
||||
<action>if (BSP_isThrottle()) {
|
||||
if (m_y > 0U) {
|
||||
|
||||
@ -148,10 +148,14 @@ Q_STATE_DEF(Ship, flying) {
|
||||
switch (e->sig) {
|
||||
//${AOs::Ship::SM::active::flying}
|
||||
case Q_ENTRY_SIG: {
|
||||
m_score = 0U; /* reset the score */
|
||||
m_score = 0U; // reset the score
|
||||
ScoreEvt *sev = Q_NEW(ScoreEvt, SCORE_SIG);
|
||||
sev->score = m_score;
|
||||
AO_Tunnel->POST(sev, this);
|
||||
|
||||
// lauch the ship from the initial position
|
||||
m_x = GAME_SHIP_X;
|
||||
m_y = (GAME_SHIP_Y << 2);
|
||||
status_ = Q_RET_HANDLED;
|
||||
break;
|
||||
}
|
||||
|
||||
@ -1,61 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<session version="4.5.0">
|
||||
<item name="license">GPL</item>
|
||||
<group name="locked"/>
|
||||
<group name="settings">
|
||||
<item name="tabs">1</item>
|
||||
<item name="windows">0</item>
|
||||
<item name="grid">3</item>
|
||||
<item name="backups">0</item>
|
||||
</group>
|
||||
<group name="windows">
|
||||
<item id=".::philo.cpp">0,0,557,470,*</item>
|
||||
</group>
|
||||
<group name="search">
|
||||
<item name="options">2033156</item>
|
||||
<item name="replace">1</item>
|
||||
</group>
|
||||
<group name="vars"/>
|
||||
<group name="tools">
|
||||
<group name="tool">
|
||||
<item name="icon">0</item>
|
||||
<item name="title"></item>
|
||||
<item name="command"></item>
|
||||
<item name="args"></item>
|
||||
<item name="dir"></item>
|
||||
<item name="options">0</item>
|
||||
</group>
|
||||
<group name="tool">
|
||||
<item name="icon">0</item>
|
||||
<item name="title"></item>
|
||||
<item name="command"></item>
|
||||
<item name="args"></item>
|
||||
<item name="dir"></item>
|
||||
<item name="options">0</item>
|
||||
</group>
|
||||
<group name="tool">
|
||||
<item name="icon">0</item>
|
||||
<item name="title"></item>
|
||||
<item name="command"></item>
|
||||
<item name="args"></item>
|
||||
<item name="dir"></item>
|
||||
<item name="options">0</item>
|
||||
</group>
|
||||
<group name="tool">
|
||||
<item name="icon">0</item>
|
||||
<item name="title"></item>
|
||||
<item name="command"></item>
|
||||
<item name="args"></item>
|
||||
<item name="dir"></item>
|
||||
<item name="options">0</item>
|
||||
</group>
|
||||
<group name="tool">
|
||||
<item name="icon">0</item>
|
||||
<item name="title"></item>
|
||||
<item name="command"></item>
|
||||
<item name="args"></item>
|
||||
<item name="dir"></item>
|
||||
<item name="options">0</item>
|
||||
</group>
|
||||
</group>
|
||||
</session>
|
||||
@ -10,35 +10,35 @@
|
||||
</operation>
|
||||
<statechart properties="0x02">
|
||||
<initial target="../1">
|
||||
<action>(void)e; // unused parameter
|
||||
m_timeEvt.armX(BSP_TICKS_PER_SEC/2, BSP_TICKS_PER_SEC/2);</action>
|
||||
<initial_glyph conn="2,3,5,1,20,4,-4">
|
||||
<action box="0,-2,6,2"/>
|
||||
<action>m_timeEvt.armX(BSP_TICKS_PER_SEC/2, BSP_TICKS_PER_SEC/2);
|
||||
(void)e; // unused parameter</action>
|
||||
<initial_glyph conn="2,2,5,1,20,8,-4">
|
||||
<action box="0,-2,32,6"/>
|
||||
</initial_glyph>
|
||||
</initial>
|
||||
<state name="off">
|
||||
<entry>BSP_ledOff();</entry>
|
||||
<tran trig="TIMEOUT" target="../../2">
|
||||
<tran_glyph conn="2,13,3,1,18,6,-2">
|
||||
<tran_glyph conn="2,16,3,1,18,8,-2">
|
||||
<action box="0,-2,8,2"/>
|
||||
</tran_glyph>
|
||||
</tran>
|
||||
<state_glyph node="2,5,16,10">
|
||||
<state_glyph node="2,8,16,10">
|
||||
<entry box="1,2,12,4"/>
|
||||
</state_glyph>
|
||||
</state>
|
||||
<state name="on">
|
||||
<entry>BSP_ledOn();</entry>
|
||||
<tran trig="TIMEOUT" target="../../1">
|
||||
<tran_glyph conn="2,25,3,1,20,-15,-4">
|
||||
<tran_glyph conn="2,30,3,1,20,-17,-4">
|
||||
<action box="0,-2,8,2"/>
|
||||
</tran_glyph>
|
||||
</tran>
|
||||
<state_glyph node="2,17,16,10">
|
||||
<state_glyph node="2,22,16,10">
|
||||
<entry box="1,2,12,4"/>
|
||||
</state_glyph>
|
||||
</state>
|
||||
<state_diagram size="30,29"/>
|
||||
<state_diagram size="34,34"/>
|
||||
</statechart>
|
||||
</class>
|
||||
</package>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user