mirror of
https://github.com/QuantumLeaps/qpcpp.git
synced 2025-01-28 06:02:56 +08:00
7.3.0
Added QP Functional Safety (FuSa) Subsystem Memory Isolation with MPU Added QAsm abstract state machine base class Added memory marker to QEvt and rearranged memory layout Updated: QP-FreeRTOS, QP-ESP-IDF,QP-Zephyr Added drift-free ticking for QP-POSIX Reorganized documentation Updated 3rd_party
This commit is contained in:
MMS
parent
6b7d766521
commit
80d9bcd6fb
@ -1 +1 @@
|
||||
Subproject commit fa06969955bfa96cbdb5b9ff8b05b66f49fad890
|
||||
Subproject commit de077b869b8980d124d9df3e5f7327500e28f178
|
||||
@ -1,9 +1,13 @@
|
||||
Any user of the QP/C++ real-time embedded framework
|
||||
qpcpp
|
||||
2023-12-31
|
||||
2024-12-31
|
||||
|
||||
Copyright (C) 2005 Quantum Leaps, LLC <state-machine.com>.
|
||||
|
||||
Q u a n t u m L e a P s
|
||||
------------------------
|
||||
Modern Embedded Software
|
||||
|
||||
SPDX-License-Identifier: GPL-3.0-or-later OR LicenseRef-QL-commercial
|
||||
|
||||
This software is dual-licensed under the terms of the open source GNU
|
||||
@ -23,4 +27,4 @@ Plagiarizing this software to sidestep the license obligations is illegal.
|
||||
Contact information:
|
||||
<www.state-machine.com/licensing>
|
||||
<info@state-machine.com>
|
||||
#0EDBEBE8223119BF5BAB0ECFC1C52D7A75E3B97C
|
||||
#10EBA9166330240A6EE04F770591C48BE4545919
|
||||
@ -1,6 +1,10 @@
|
||||
|
||||
|
||||
|
||||
# What's New?
|
||||
|
||||
[](https://github.com/QuantumLeaps/qpcpp/releases/latest)
|
||||
|
||||
|
||||
View QP/C++ Revision History at: https://www.state-machine.com/qpcpp/history.html
|
||||
|
||||
> **NOTE:** If you're interested in the latest QP/C++ version from GitHub,
|
||||
@ -121,7 +125,7 @@ open the file [html/index.html](html/index.html) in your web browser.
|
||||
# How to Help this Project?
|
||||
If you like this project, please give it a star (in the upper-right corner of your browser window):
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[RTEF]: <https://www.state-machine.com/rtef>
|
||||
|
||||
1
doxygen/.gitignore
vendored
1
doxygen/.gitignore
vendored
@ -1 +0,0 @@
|
||||
metrics.dox
|
||||
309
doxygen/Doxyfile
309
doxygen/Doxyfile
@ -1,309 +0,0 @@
|
||||
# Doxyfile 1.9.5
|
||||
|
||||
@INCLUDE = ../../ql-doxygen/ql-doxyfile
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Project related configuration options
|
||||
#---------------------------------------------------------------------------
|
||||
DOXYFILE_ENCODING = UTF-8
|
||||
PROJECT_NAME = QP/C++
|
||||
PROJECT_NUMBER = 7.2.1
|
||||
PROJECT_BRIEF = "Real-Time Embedded Framework"
|
||||
PROJECT_LOGO = ../../ql-doxygen/images/logo_ql.png
|
||||
OUTPUT_DIRECTORY =
|
||||
CREATE_SUBDIRS = NO
|
||||
CREATE_SUBDIRS_LEVEL = 6
|
||||
ALLOW_UNICODE_NAMES = NO
|
||||
OUTPUT_LANGUAGE = English
|
||||
BRIEF_MEMBER_DESC = YES
|
||||
REPEAT_BRIEF = NO
|
||||
ABBREVIATE_BRIEF = "The $name class" \
|
||||
"The $name widget" \
|
||||
"The $name file" \
|
||||
is \
|
||||
provides \
|
||||
specifies \
|
||||
contains \
|
||||
represents \
|
||||
a \
|
||||
an \
|
||||
the
|
||||
ALWAYS_DETAILED_SEC = NO
|
||||
INLINE_INHERITED_MEMB = NO
|
||||
FULL_PATH_NAMES = NO
|
||||
STRIP_FROM_PATH =
|
||||
STRIP_FROM_INC_PATH =
|
||||
SHORT_NAMES = NO
|
||||
JAVADOC_AUTOBRIEF = YES
|
||||
JAVADOC_BANNER = NO
|
||||
QT_AUTOBRIEF = NO
|
||||
MULTILINE_CPP_IS_BRIEF = NO
|
||||
PYTHON_DOCSTRING = YES
|
||||
INHERIT_DOCS = YES
|
||||
SEPARATE_MEMBER_PAGES = NO
|
||||
TAB_SIZE = 4
|
||||
OPTIMIZE_OUTPUT_FOR_C = NO
|
||||
OPTIMIZE_OUTPUT_JAVA = NO
|
||||
OPTIMIZE_FOR_FORTRAN = NO
|
||||
OPTIMIZE_OUTPUT_VHDL = NO
|
||||
OPTIMIZE_OUTPUT_SLICE = NO
|
||||
EXTENSION_MAPPING = lnt=Objective-C
|
||||
MARKDOWN_SUPPORT = YES
|
||||
TOC_INCLUDE_HEADINGS = 4
|
||||
AUTOLINK_SUPPORT = YES
|
||||
BUILTIN_STL_SUPPORT = NO
|
||||
CPP_CLI_SUPPORT = NO
|
||||
SIP_SUPPORT = NO
|
||||
IDL_PROPERTY_SUPPORT = YES
|
||||
DISTRIBUTE_GROUP_DOC = NO
|
||||
GROUP_NESTED_COMPOUNDS = NO
|
||||
SUBGROUPING = YES
|
||||
INLINE_GROUPED_CLASSES = YES
|
||||
INLINE_SIMPLE_STRUCTS = YES
|
||||
TYPEDEF_HIDES_STRUCT = YES
|
||||
LOOKUP_CACHE_SIZE = 0
|
||||
NUM_PROC_THREADS = 1
|
||||
#---------------------------------------------------------------------------
|
||||
# Build related configuration options
|
||||
#---------------------------------------------------------------------------
|
||||
EXTRACT_ALL = YES
|
||||
EXTRACT_PRIVATE = YES
|
||||
EXTRACT_PRIV_VIRTUAL = NO
|
||||
EXTRACT_PACKAGE = YES
|
||||
EXTRACT_STATIC = YES
|
||||
EXTRACT_LOCAL_CLASSES = YES
|
||||
EXTRACT_LOCAL_METHODS = NO
|
||||
EXTRACT_ANON_NSPACES = NO
|
||||
RESOLVE_UNNAMED_PARAMS = YES
|
||||
HIDE_UNDOC_MEMBERS = NO
|
||||
HIDE_UNDOC_CLASSES = NO
|
||||
HIDE_FRIEND_COMPOUNDS = NO
|
||||
HIDE_IN_BODY_DOCS = NO
|
||||
INTERNAL_DOCS = NO
|
||||
CASE_SENSE_NAMES = NO
|
||||
HIDE_SCOPE_NAMES = YES
|
||||
HIDE_COMPOUND_REFERENCE= NO
|
||||
SHOW_HEADERFILE = YES
|
||||
SHOW_INCLUDE_FILES = YES
|
||||
SHOW_GROUPED_MEMB_INC = NO
|
||||
FORCE_LOCAL_INCLUDES = NO
|
||||
INLINE_INFO = YES
|
||||
SORT_MEMBER_DOCS = NO
|
||||
SORT_BRIEF_DOCS = NO
|
||||
SORT_MEMBERS_CTORS_1ST = NO
|
||||
SORT_GROUP_NAMES = NO
|
||||
SORT_BY_SCOPE_NAME = NO
|
||||
STRICT_PROTO_MATCHING = NO
|
||||
GENERATE_TODOLIST = YES
|
||||
GENERATE_TESTLIST = YES
|
||||
GENERATE_BUGLIST = YES
|
||||
GENERATE_DEPRECATEDLIST= YES
|
||||
ENABLED_SECTIONS = QPCPP
|
||||
MAX_INITIALIZER_LINES = 30
|
||||
SHOW_USED_FILES = YES
|
||||
SHOW_FILES = YES
|
||||
SHOW_NAMESPACES = YES
|
||||
FILE_VERSION_FILTER =
|
||||
LAYOUT_FILE =
|
||||
CITE_BIB_FILES =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to warning and progress messages
|
||||
#---------------------------------------------------------------------------
|
||||
QUIET = NO
|
||||
WARNINGS = YES
|
||||
WARN_IF_UNDOCUMENTED = YES
|
||||
WARN_IF_DOC_ERROR = YES
|
||||
WARN_IF_INCOMPLETE_DOC = YES
|
||||
WARN_NO_PARAMDOC = NO
|
||||
WARN_AS_ERROR = NO
|
||||
WARN_FORMAT = "$file:$line: $text"
|
||||
WARN_LINE_FORMAT = "at line $line of file $file"
|
||||
WARN_LOGFILE =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the input files
|
||||
#---------------------------------------------------------------------------
|
||||
INPUT = main.dox \
|
||||
gs.dox \
|
||||
../../cert-pack/cert-pack.dox \
|
||||
../../cert-pack/srs.dox \
|
||||
../../cert-pack/sas.dox \
|
||||
../../cert-pack/sds.dox \
|
||||
../../cert-pack/sds_sm-cpp.dox \
|
||||
../../cert-pack/autosar.dox \
|
||||
../../cert-pack/metrics.dox \
|
||||
history.dox \
|
||||
exa.dox \
|
||||
exa_native.dox \
|
||||
exa_rtos.dox \
|
||||
exa_os.dox \
|
||||
exa_qutest.dox \
|
||||
exa_mware.dox \
|
||||
ports.dox \
|
||||
ports_native.dox \
|
||||
ports_arm-cm.dox \
|
||||
ports_rtos.dox \
|
||||
ports_os.dox \
|
||||
api.dox \
|
||||
../../ql-doxygen/help.dox \
|
||||
dir.dox \
|
||||
config.hpp \
|
||||
../include \
|
||||
../src \
|
||||
../ports/sample \
|
||||
../ports/lint-plus/std.lnt \
|
||||
../ports/lint-plus/qpcpp.lnt \
|
||||
../ports/lint-plus/options.lnt
|
||||
INPUT_ENCODING = UTF-8
|
||||
INPUT_FILE_ENCODING =
|
||||
FILE_PATTERNS = *.dox \
|
||||
*.h \
|
||||
*.hpp \
|
||||
*.c \
|
||||
*.cpp \
|
||||
*.s \
|
||||
*.asm \
|
||||
*.lnt
|
||||
RECURSIVE = YES
|
||||
EXCLUDE = ../include/qs_dummy.hpp
|
||||
EXCLUDE_SYMLINKS = NO
|
||||
EXCLUDE_PATTERNS =
|
||||
EXCLUDE_SYMBOLS = QP_IMPL
|
||||
EXAMPLE_PATH = gen \
|
||||
snippets \
|
||||
../include \
|
||||
../src \
|
||||
../ports \
|
||||
../ports/lint-plus \
|
||||
../examples
|
||||
EXAMPLE_PATTERNS = *
|
||||
EXAMPLE_RECURSIVE = NO
|
||||
IMAGE_PATH = images \
|
||||
../../ql-doxygen/images \
|
||||
../../cert-pack/images
|
||||
INPUT_FILTER =
|
||||
FILTER_PATTERNS =
|
||||
FILTER_SOURCE_FILES = NO
|
||||
FILTER_SOURCE_PATTERNS =
|
||||
USE_MDFILE_AS_MAINPAGE =
|
||||
FORTRAN_COMMENT_AFTER = 72
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to source browsing
|
||||
#---------------------------------------------------------------------------
|
||||
SOURCE_BROWSER = YES
|
||||
INLINE_SOURCES = NO
|
||||
STRIP_CODE_COMMENTS = NO
|
||||
REFERENCED_BY_RELATION = NO
|
||||
REFERENCES_RELATION = NO
|
||||
REFERENCES_LINK_SOURCE = YES
|
||||
SOURCE_TOOLTIPS = YES
|
||||
USE_HTAGS = NO
|
||||
VERBATIM_HEADERS = YES
|
||||
CLANG_ASSISTED_PARSING = NO
|
||||
CLANG_ADD_INC_PATHS = YES
|
||||
CLANG_OPTIONS =
|
||||
CLANG_DATABASE_PATH =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the alphabetical class index
|
||||
#---------------------------------------------------------------------------
|
||||
ALPHABETICAL_INDEX = YES
|
||||
IGNORE_PREFIX =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the HTML output
|
||||
#---------------------------------------------------------------------------
|
||||
GENERATE_HTML = YES
|
||||
HTML_OUTPUT = ../html
|
||||
HTML_FILE_EXTENSION = .html
|
||||
HTML_HEADER = ../../ql-doxygen/ql-header-awesome.html
|
||||
HTML_FOOTER = ../../ql-doxygen/ql-footer-awesome.html
|
||||
HTML_STYLESHEET =
|
||||
HTML_EXTRA_STYLESHEET = ../../ql-doxygen/doxygen-awesome.css \
|
||||
../../ql-doxygen/doxygen-awesome-sidebar-only.css \
|
||||
../../ql-doxygen/doxygen-awesome-sidebar-only-darkmode-toggle.css \
|
||||
../../ql-doxygen/ql-awesome.css
|
||||
HTML_EXTRA_FILES = ../../ql-doxygen/doxygen-awesome-darkmode-toggle.js \
|
||||
../../ql-doxygen/doxygen-awesome-fragment-copy-button.js \
|
||||
../../ql-doxygen/doxygen-awesome-paragraph-link.js \
|
||||
../../ql-doxygen/ql-preview.js
|
||||
HTML_COLORSTYLE = AUTO_LIGHT
|
||||
HTML_COLORSTYLE_HUE = 209
|
||||
HTML_COLORSTYLE_SAT = 255
|
||||
HTML_COLORSTYLE_GAMMA = 113
|
||||
HTML_TIMESTAMP = NO
|
||||
HTML_DYNAMIC_MENUS = YES
|
||||
HTML_DYNAMIC_SECTIONS = NO
|
||||
HTML_INDEX_NUM_ENTRIES = 100
|
||||
GENERATE_DOCSET = NO
|
||||
DOCSET_FEEDNAME = "Doxygen generated docs"
|
||||
DOCSET_FEEDURL =
|
||||
DOCSET_BUNDLE_ID = com.state-machine.doc
|
||||
DOCSET_PUBLISHER_ID = com.state-machine.doc
|
||||
DOCSET_PUBLISHER_NAME = QuantumLeaps
|
||||
GENERATE_HTMLHELP = NO
|
||||
CHM_FILE = ../qpcpp.chm
|
||||
HHC_LOCATION =
|
||||
GENERATE_CHI = NO
|
||||
CHM_INDEX_ENCODING =
|
||||
BINARY_TOC = YES
|
||||
TOC_EXPAND = NO
|
||||
GENERATE_QHP = NO
|
||||
QCH_FILE =
|
||||
QHP_NAMESPACE = com.state-machine.qp
|
||||
QHP_VIRTUAL_FOLDER = doc
|
||||
QHP_CUST_FILTER_NAME =
|
||||
QHP_CUST_FILTER_ATTRS =
|
||||
QHP_SECT_FILTER_ATTRS =
|
||||
QHG_LOCATION =
|
||||
GENERATE_ECLIPSEHELP = NO
|
||||
ECLIPSE_DOC_ID = com.state-machine.qp
|
||||
DISABLE_INDEX = NO
|
||||
GENERATE_TREEVIEW = YES
|
||||
FULL_SIDEBAR = NO
|
||||
ENUM_VALUES_PER_LINE = 4
|
||||
TREEVIEW_WIDTH = 335
|
||||
EXT_LINKS_IN_WINDOW = NO
|
||||
OBFUSCATE_EMAILS = NO
|
||||
HTML_FORMULA_FORMAT = png
|
||||
FORMULA_FONTSIZE = 10
|
||||
FORMULA_MACROFILE =
|
||||
USE_MATHJAX = NO
|
||||
MATHJAX_VERSION = MathJax_2
|
||||
MATHJAX_FORMAT = HTML-CSS
|
||||
MATHJAX_RELPATH = https://cdn.jsdelivr.net/npm/mathjax@2
|
||||
MATHJAX_EXTENSIONS =
|
||||
MATHJAX_CODEFILE =
|
||||
SEARCHENGINE = YES
|
||||
SERVER_BASED_SEARCH = NO
|
||||
EXTERNAL_SEARCH = NO
|
||||
SEARCHENGINE_URL =
|
||||
SEARCHDATA_FILE = searchdata.xml
|
||||
EXTERNAL_SEARCH_ID = QPCPP
|
||||
EXTRA_SEARCH_MAPPINGS =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the preprocessor
|
||||
#---------------------------------------------------------------------------
|
||||
ENABLE_PREPROCESSING = YES
|
||||
MACRO_EXPANSION = NO
|
||||
EXPAND_ONLY_PREDEF = NO
|
||||
SEARCH_INCLUDES = YES
|
||||
INCLUDE_PATH =
|
||||
INCLUDE_FILE_PATTERNS =
|
||||
PREDEFINED = Q_SPY \
|
||||
Q_UTEST \
|
||||
QP_IMPL \
|
||||
Q_EVT_CTOR \
|
||||
QF_MAX_ACTIVE=32 \
|
||||
QF_MAX_TICK_RATE=2 \
|
||||
QF_MAX_EPOOL=3 \
|
||||
QF_EVENT_SIZ_SIZE=2 \
|
||||
QF_EQUEUE_CTR_SIZE=2 \
|
||||
QF_MPOOL_SIZ_SIZE=2 \
|
||||
QF_MPOOL_CTR_SIZE=2 \
|
||||
QF_TIMEEVT_CTR_SIZE=4 \
|
||||
QF_ACTIVE_STOP=0 \
|
||||
QF_ON_CONTEXT_SW \
|
||||
QS_TIME_SIZE=4 \
|
||||
QF_EQUEUE_TYPE=QEQueue \
|
||||
QF_OS_OBJECT_TYPE=void* \
|
||||
QF_THREAD_TYPE=void*
|
||||
EXPAND_AS_DEFINED =
|
||||
SKIP_FUNCTION_MACROS = NO
|
||||
@ -1,15 +0,0 @@
|
||||
# Doxyfile 1.9.4
|
||||
|
||||
@INCLUDE = Doxyfile
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the HTML output
|
||||
#---------------------------------------------------------------------------
|
||||
PROJECT_LOGO = images/logo_ql-comp.png
|
||||
|
||||
HTML_OUTPUT = tmp
|
||||
HTML_HEADER = ../../ql-doxygen/ql-header.html
|
||||
HTML_FOOTER = ../../ql-doxygen/ql-footer.html
|
||||
HTML_EXTRA_STYLESHEET = ../../ql-doxygen/ql.css
|
||||
HTML_EXTRA_FILES = ../../ql-doxygen/ql-preview.js
|
||||
GENERATE_HTMLHELP = YES
|
||||
@ -1,11 +0,0 @@
|
||||
# Doxyfile 1.9.5
|
||||
|
||||
@INCLUDE = Doxyfile
|
||||
|
||||
GENERATE_HTML = NO
|
||||
GENERATE_LATEX = YES
|
||||
ENABLED_SECTIONS += LATEX
|
||||
|
||||
# no source code in latex...
|
||||
SOURCE_BROWSER = NO
|
||||
VERBATIM_HEADERS = NO
|
||||
313
doxygen/api.dox
313
doxygen/api.dox
@ -1,313 +0,0 @@
|
||||
/*! @page api API Reference
|
||||
@nav_next{deprecated}
|
||||
|
||||
@section api_qep QEP (Hierarchical State Machines)
|
||||
QEP is a universal, UML-compliant event processor that enables developers to code UML state machines in highly readable ANSI-C, in which every state machine element is mapped to code precisely, unambiguously, and exactly once (traceability). QEP fully supports hierarchical state nesting, which is the fundamental mechanism for reusing behavior across many states instead of repeating the same actions and transitions over and over again.
|
||||
|
||||
|
||||
@subsection api_qep_hsm Hierarchical State Machines
|
||||
- QHsm class
|
||||
- QHsm::QHsm()
|
||||
- QHsm::init()
|
||||
- QHsm::dispatch()
|
||||
- QHsm::isIn()
|
||||
- QHsm::state()
|
||||
- QHsm::top()
|
||||
- QMsm class
|
||||
- QMsm::QMsm()
|
||||
- QMsm::isInState()
|
||||
- QMsm::stateObj()
|
||||
- Q_STATE_CAST()
|
||||
|
||||
|
||||
@section api_qf QF (Active Object Framework)
|
||||
QF is a portable, event-driven, real-time framework for execution of active objects (concurrent state machines) specifically designed for real-time embedded (RTE) systems.
|
||||
|
||||
|
||||
@subsection api_qf_act Active Objects
|
||||
- QActive class
|
||||
- QActive::QActive()
|
||||
- QActive::start()
|
||||
- %QActive:: POST()
|
||||
- %QActive:: POST_X()
|
||||
- QActive::postLIFO()
|
||||
- QActive::defer()
|
||||
- QActive::recall()
|
||||
- QActive::flushDeferred()
|
||||
- QActive::stop()
|
||||
- QMActive class
|
||||
- QMActive::QMActive()
|
||||
|
||||
|
||||
@subsection api_qf_ps Publish-Subscribe
|
||||
- ::QSubscrList (Subscriber List struct)
|
||||
- QActive::psInit()
|
||||
- %QF:: PUBLISH()
|
||||
- QActive::subscribe()
|
||||
- QActive::unsubscribe()
|
||||
- QActive::unsubscribeAll()
|
||||
|
||||
|
||||
@subsection api_qf_evt Event Management
|
||||
- QEvt class
|
||||
- Q_NEW()
|
||||
- Q_NEW_X()
|
||||
- Q_NEW_REF()
|
||||
- Q_DELETE_REF()
|
||||
- QF::gc()
|
||||
- Q_EVT_CAST()
|
||||
|
||||
|
||||
@subsection api_qf_time Time Events
|
||||
- QTimeEvt class
|
||||
- QTimeEvt::QTimeEvt()
|
||||
- QTimeEvt::armX()
|
||||
- QTimeEvt::disarm()
|
||||
- QTimeEvt::rearm()
|
||||
- QTimeEvt::currCtr()
|
||||
- QTicker active object
|
||||
- %QF:: TICK()
|
||||
- %QF:: TICK_X()
|
||||
|
||||
|
||||
@subsection api_qf_queue Event Queues (raw thread-safe)
|
||||
- QEQueue class
|
||||
- QEQueue::init()
|
||||
- QEQueue::post()
|
||||
- QEQueue::postLIFO()
|
||||
- QEQueue::get()
|
||||
- QEQueue::getNFree()
|
||||
- QEQueue::getNMin()
|
||||
- QEQueue::isEmpty()
|
||||
- QEQueueCtr()
|
||||
|
||||
|
||||
@subsection api_qf_mem Memory Pools
|
||||
- QMPool class
|
||||
- QMPool::init()
|
||||
- QMPool::get()
|
||||
- QMPool::put()
|
||||
|
||||
|
||||
@section api_qs QS ("Quantum Spy" Software Tracing)
|
||||
QS is a software tracing system that enables developers to monitor live event-driven QP applications with minimal target system resources and without stopping or significantly slowing down the code. QS is an ideal tool for testing, troubleshooting, and optimizing QP applications. QS can even be used to support acceptance testing in product manufacturing.
|
||||
|
||||
|
||||
@subsection api_qs_ini QS Initialization and Control
|
||||
- QS_INIT()
|
||||
- QS::initBuf()
|
||||
- QS::getByte()
|
||||
- QS::getBlock()
|
||||
- QS::onStartup()
|
||||
- QS::onCleanup()
|
||||
- QS::onFlush()
|
||||
- QS::onGetTime()
|
||||
|
||||
|
||||
@subsection api_qs_rx QS Receive-Channel (QS-RX)
|
||||
- QS::rxInitBuf()
|
||||
- QS::rxPut()
|
||||
- QS::rxParse()
|
||||
- QS::onCommand()
|
||||
|
||||
|
||||
@subsection api_qs_filter QS Filters
|
||||
- QS_GLB_FILTER()
|
||||
- QS_LOC_FILTER()
|
||||
- QS_FILTER_AP_OBJ()
|
||||
|
||||
|
||||
@subsection api_qs_dict QS Dictionaries
|
||||
- QS_SIG_DICTIONARY()
|
||||
- QS_OBJ_DICTIONARY()
|
||||
- QS_OBJ_ARR_DICTIONARY()
|
||||
- QS_FUN_DICTIONARY()
|
||||
- QS_USR_DICTIONARY()
|
||||
|
||||
|
||||
@subsection api_qs_user QS Application-Specific Records
|
||||
- ::QS_USER enumeration
|
||||
- QS_BEGIN_ID()
|
||||
- QS_END()
|
||||
- QS_U8() / QS_I8()
|
||||
- QS_U16() / QS_I16()
|
||||
- QS_U32() / QS_I32()
|
||||
- QS_U32_HEX()
|
||||
- QS_STR()
|
||||
- QS_MEM()
|
||||
|
||||
|
||||
@section api_qv QV (Cooperative Kernel)
|
||||
QV is a simple **cooperative** kernel (previously called "Vanilla" kernel). This kernel executes active objects one at a time, with priority-based scheduling performed before processing of each event. Due to naturally short duration of event processing in state machines, the simple QV kernel is often adequate for many real-time systems.
|
||||
|
||||
The QV scheduler is engaged after every RTC step of any active object to choose the next active object to execute. The QV scheduler always chooses the highest-priority active object that has any events in its event queue. The QV scheduler then extracts the next event from this queue and dispatches it to the state machine associated with the active object. The state machine runs to completion, after which the QV scheduler runs and the cycle repeats.
|
||||
|
||||
Please note that because the state machines always return to the QV scheduler after each RTC step, a single stack can be used to process all state machines (memory-friendly architecture).
|
||||
|
||||
The QV scheduler can also very easily detect when all event queues are empty, at which point it can call the idle callback to let the application put the CPU and peripherals to a low-power sleep mode (power-friendly architecture).
|
||||
|
||||
Given the simplicity, portability, and low-resource consumption, the QV scheduler is very attractive. It allows you to partition the problem into active objects and execute these active objects orderly. The task-level response of this scheduler is the longest RTC step in the whole system, but because event-driven active objects don’t block, the RTC steps tend to be very short (typically just a few microseconds). Also, often you can break up longer RTC steps into shorter pieces, by posting an event to self and returning (“Reminder” state pattern). The self-posted event then triggers the continuation of longer processing.
|
||||
|
||||
|
||||
@subsection api_qv_init Kernel Initialization and Control
|
||||
- QV_INIT()
|
||||
- <a href="qv_8c.html#a779a1bc9482e2d489dc87751cd100fdb"><b>QF_run()</b></a>
|
||||
- QV::onIdle()
|
||||
- QV_CPU_SLEEP()
|
||||
|
||||
|
||||
@section api_qk QK (Preemptive Run-to-Completion Kernel)
|
||||
QK is a tiny **preemptive**, priority-based, non-blocking kernel designed specifically for executing active objects. QK runs active objects in the same way as prioritized interrupt controller (such as NVIC in ARM Cortex-M) runs interrupts using the single stack. Active objects process their events in run-to-completion (RTC) fashion and remove themselves from the call stack, the same way as nested interrupts remove themselves from the stack upon completion. At the same time high-priority active objects can preempt lower-priority active objects, just like interrupts can preempt each other under a prioritized interrupt controller. QK meets all the requirement of the Rate Monotonic Scheduling (a.k.a. Rate Monotonic Analysis RMA) and can be used in hard real-time systems.
|
||||
|
||||
|
||||
@subsection api_qk_ctrl Kernel Initialization and Control
|
||||
- QK_INIT()
|
||||
- <a href="qk_8c.html#a779a1bc9482e2d489dc87751cd100fdb"><b>QF_run()</b></a>
|
||||
- QK::onIdle()
|
||||
- QK::schedLock()
|
||||
- QK::schedUnlock()
|
||||
|
||||
|
||||
@subsection api_qk_isr Interrupt Management
|
||||
- QK_ISR_ENTRY()
|
||||
- QK_ISR_EXIT()
|
||||
|
||||
|
||||
@section api_qxk QXK (Preemptive Dual-Mode Run-to-Completion/Blocking RTOS Kernel)
|
||||
QXK is a small, preemptive, priority-based, dual-mode **blocking** kernel that executes active objects like the @ref qk "QK kernel", but can also execute traditional __blocking__ threads (extended threads). In this respect, QXK behaves exactly as a conventional __RTOS__ (Real-Time Operating System). QXK has been designed specifically for mixing event-driven active objects with traditional blocking code, such as commercial middleware (TCP/IP stacks, UDP stacks, embedded file systems, etc.) or legacy software.
|
||||
|
||||
|
||||
@subsection api_qxk_ctrl Kernel Initialization and Control
|
||||
- QXK_INIT()
|
||||
- <a href="qxk_8c.html#a779a1bc9482e2d489dc87751cd100fdb"><b>QF_run()</b></a>
|
||||
- QXK::onIdle()
|
||||
- QXK::schedLock()
|
||||
- QXK::schedUnlock()
|
||||
|
||||
|
||||
@subsection api_qxk_isr Interrupt Management
|
||||
- QXK_ISR_ENTRY()
|
||||
- QXK_ISR_EXIT()
|
||||
|
||||
|
||||
@subsection api_qxk_xthr Extended Thread Management
|
||||
- QXThread class
|
||||
- QXThread::QXThread()
|
||||
- QXThread::start()
|
||||
- QXThread::delay()
|
||||
- QXThread::delayCancel()
|
||||
- QXThread::queueGet()
|
||||
- Q_XTHREAD_CAST()
|
||||
- QXK_current()
|
||||
- QXK_TLS()
|
||||
|
||||
|
||||
@subsection api_qxk_sema Semaphores
|
||||
- QXSemaphore class (Semaphore Control Block)
|
||||
- QXSemaphore::init()
|
||||
- QXSemaphore::wait()
|
||||
- QXSemaphore::tryWait()
|
||||
- QXSemaphore::signal()
|
||||
|
||||
|
||||
@subsection api_qxk_mutex Mutexes
|
||||
- QXMutex class (Mutex Control Block)
|
||||
- QXMutex::init()
|
||||
- QXMutex::lock()
|
||||
- QXMutex::tryLock()
|
||||
- QXMutex::unlock()
|
||||
|
||||
|
||||
@subsection api_qxk_queue Message Queues
|
||||
- %QXThread:: POST()
|
||||
- %QXThread:: POST_X()
|
||||
- QXThread::queueGet() - waiting (blocking) on message queue
|
||||
|
||||
|
||||
@subsection api_qxk_mem Memory Pools
|
||||
- QMPool class
|
||||
- QMPool::init()
|
||||
- QMPool::get()
|
||||
- QMPool::put()
|
||||
|
||||
<br>
|
||||
@nav_next{deprecated}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page deprecated Deprecated APIs
|
||||
|
||||
__The following QP/C++ APIs are now deprecated:__
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @namespace QP
|
||||
@brief QP/C++ framework
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @namespace QP::QF
|
||||
@brief hierarchical event processor and active object framework
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @namespace QP::QS
|
||||
@brief "QP/Spy" software tracing (target-resident components)
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @namespace QP::QV
|
||||
@brief cooperative, non-preemptive kernel
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @namespace QP::QK
|
||||
@brief preemptive, non-blocking kernel
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @namespace QP::QXK
|
||||
@brief preemptive, dual-mode (non-blocking / blocking) kernel
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir include
|
||||
@brief Platform-independent QP™/C++ API
|
||||
|
||||
@attention
|
||||
The QP™/C++ <span class="img folder">include</span> directory needs to be added to the compiler's include path in the applications using QP™/C++.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src
|
||||
@brief Platform-independent QP™/C++ source code
|
||||
|
||||
Files from this directory need to be added to the project, to build the QP™/C++ framework from source code.
|
||||
|
||||
@attention
|
||||
The QP™/C++ <span class="img folder">src</span> directory needs to be added to the compiler's include path in the applications that build QP™/C++ framework from sources (as opposed to using QP as a pre-built library).
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src/qf
|
||||
@brief Platform-independent implementation of the QEP and QF components.
|
||||
|
||||
@note
|
||||
Typically, files in this directory need to be added to the application build, but some QP ports might not need all the files in this directory. For example, a QP port to a 3rd-party RTOS kernel might be using a message queue of the RTOS instead of the native QP event queue, in which case the file qf_actq.cpp would not be needed and should be excluded from the build.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src/qv
|
||||
@brief Platform-independent implementation of the @ref srs_qv built-in kernel.
|
||||
|
||||
@attention
|
||||
Files in this directory need to be included in the QP application build only if the application uses the @ref srs_qv kernel.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src/qk
|
||||
@brief Platform-independent implementation of the @ref srs_qk built-in kernel.
|
||||
|
||||
@attention
|
||||
Files in this directory need to be included in the QP application build only if the application uses the @ref srs_qk kernel.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src/qxk
|
||||
@brief Platform-independent implementation of the @ref srs_qxk built-in kernel.
|
||||
|
||||
@attention
|
||||
Files in this directory need to be included in the QP application build only if the application uses the @ref srs_qxk kernel.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src/qs
|
||||
@brief Platform-independent implementation of the @ref qs component (software tracing).
|
||||
*/
|
||||
@ -1,66 +0,0 @@
|
||||
//! @file
|
||||
//! @brief Various macros for configuring and porting QP/C++
|
||||
|
||||
//! The preprocessor switch to disable checking assertions
|
||||
//!
|
||||
//! @description
|
||||
//! When defined, Q_NASSERT disables the following macros #Q_ASSERT,
|
||||
//! #Q_REQUIRE, #Q_ENSURE, #Q_INVARIANT, #Q_ERROR as well as
|
||||
//! #Q_ASSERT_ID, #Q_REQUIRE_ID, #Q_ENSURE_ID, #Q_INVARIANT_ID, and
|
||||
//! #Q_ERROR_ID do NOT evaluate the test condition passed as the
|
||||
//! argument to these macros.
|
||||
//!
|
||||
//! @note One notable exception is the macro #Q_ALLEGE, that still
|
||||
//! evaluates the test condition, but does not report assertion
|
||||
//! failures when the switch Q_NASSERT is defined.
|
||||
#define Q_NASSERT
|
||||
|
||||
//! Enable the QActive::stop() API in the QF port.
|
||||
//!
|
||||
//! @description
|
||||
//! Defining this macro enables the QActive::stop() API in a given port.
|
||||
//! This feature should be used with caution, as stopping and re-starting
|
||||
//! active objects **cleanly** can be tricky.
|
||||
//!
|
||||
#define QF_ACTIVE_STOP
|
||||
|
||||
//! The preprocessor switch to activate the constructor in QP::QEvt.
|
||||
//!
|
||||
//! @description
|
||||
//! When #Q_EVT_CTOR is defined (typically in the qep_port.hpp header file),
|
||||
//! QP::QEvt becomes a class with constructor. More importantly, the
|
||||
//! subclasses of QP::QEvt (custom events) can have non-default constructors.
|
||||
//! These constructors are then called when events are created (e.g.,
|
||||
//! with Q_NEW())
|
||||
//!
|
||||
//! @sa #Q_EVT_VIRTUAL
|
||||
#define Q_EVT_CTOR
|
||||
|
||||
//! The preprocessor switch to activate the virtual destructor in QP::QEvt.
|
||||
//!
|
||||
//! @description
|
||||
//! This macro only works when #Q_EVT_CTOR is also defined. When also
|
||||
//! #Q_EVT_VIRTUAL is defined (typically in the qep_port.hpp header
|
||||
//! file), QP::QEvt becomes a class with a constructor and a virtual
|
||||
//! destructor. More importantly, the subclasses of QP::QEvt (custom events)
|
||||
//! can have (virtual) destructors. These destructors are then invoked
|
||||
//! before recycling the event with QP::QF::gc().
|
||||
#define Q_EVT_VIRTUAL
|
||||
|
||||
//! The preprocessor switch to activate the QS software tracing
|
||||
//! instrumentation in the code
|
||||
//!
|
||||
//! @description
|
||||
//! When defined, Q_SPY activates the QS software tracing instrumentation.
|
||||
//! When Q_SPY is not defined, the QS instrumentation in the code does
|
||||
//! not generate any code.
|
||||
#define Q_SPY
|
||||
|
||||
//! This macro enables calling the QK context-switch callback
|
||||
//! QF_onContextSw()
|
||||
#define QF_ON_CONTEXT_SW
|
||||
|
||||
//! Macro that should be defined (typically on the compiler's command line)
|
||||
//! in the Win32-GUI applications that use the @ref win32 or @ref win32-qv
|
||||
//! ports.
|
||||
#define WIN32_GUI
|
||||
@ -1,48 +0,0 @@
|
||||
/*##########################################################################*/
|
||||
/*! @dir include
|
||||
@brief Platform-independent QP™/C++ API
|
||||
|
||||
@attention
|
||||
The QP™/C <span class="img folder">include</span> directory needs to be added to the compiler's include path in the applications using QP™/C++.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src
|
||||
@brief Platform-independent QP™/C++ source code
|
||||
|
||||
Files from this directory need to be added to the project, to build the QP™/C++ framework from source code.
|
||||
|
||||
@attention
|
||||
The QP™/C++ <span class="img folder">src</span> directory needs to be added to the compiler's include path in the applications that build QP™/C++ framework from sources (as opposed to using QP as a pre-built library).
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src/qf
|
||||
@brief Platform-independent implementation of the QEP and QF components.
|
||||
|
||||
@note
|
||||
Typically, files in this directory need to be added to the application build, but some QP ports might not need all the files in this directory. For example, a QP port to a 3rd-party RTOS kernel might be using a message queue of the RTOS instead of the native QP event queue, in which case the file qf_actq.c would not be needed and should be excluded from the build.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src/qv
|
||||
@brief Platform-independent implementation of the @ref srs_qv built-in kernel.
|
||||
|
||||
@attention
|
||||
Files in this directory need to be included in the QP application build only if the application uses the @ref srs_qv kernel.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src/qk
|
||||
@brief Platform-independent implementation of the @ref srs_qk built-in kernel.
|
||||
|
||||
@attention
|
||||
Files in this directory need to be included in the QP application build only if the application uses the @ref srs_qk kernel.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src/qxk
|
||||
@brief Platform-independent implementation of the @ref srs_qxk built-in kernel.
|
||||
|
||||
@attention
|
||||
Files in this directory need to be included in the QP application build only if the application uses the @ref srs_qxk kernel.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @dir src/qs
|
||||
@brief Platform-independent implementation of the QS component (software tracing).
|
||||
*/
|
||||
522
doxygen/exa.dox
522
doxygen/exa.dox
@ -1,522 +0,0 @@
|
||||
/*! @page exa Examples
|
||||
|
||||
@section exa_gen General Comments
|
||||
The QP/C++ distribution contains many @subpage exa_ref "example projects" to demonstrate various QP/C++ features. Each example project is described on its own dedicated page that you can find using several criteria (see @ref exa_ref). The example projects have the following main goals:
|
||||
|
||||
- <strong>to help you learn how to use QP/C</strong> — the examples show the intended way of using QP/C++ features and structuring QP/C++ applications.
|
||||
|
||||
- <strong>to provide you with a starting point for your own projects</strong> — the examples are complete working projects, with correctly pre-configured tools, such as compiler options, linker script, debugger setup, etc.
|
||||
|
||||
- <strong>to provide you with unit testing support</strong> — the [QUTest](/qtools/qutest.html) examples illustrate unit testing techniques both for the development worksations and for embedded targets.
|
||||
|
||||
@note
|
||||
It is highly recommended that you create your own projects by **copying and modifying** existing example projects rather than starting your QP/C++ projects from scratch.
|
||||
|
||||
|
||||
|
||||
@subsection exa_code Example Code Structure
|
||||
QP/C++ examples are located in sub-directories of the <span class="img folder">examples</span> <a href="files.html">top-level folder</a>, with the hierarchical organization outlined below:
|
||||
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">examples/</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">arm-cm/</span> — Native examples for ARM-Cortex-M (bare-metal) <span class="tag">A</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">blinky_ek-tm4c123gxl/</span> — Blinky example for EK-TM4C123GXL board
|
||||
</li>
|
||||
<li><span class="img folder">dpp_ek-tm4c123gxl/</span> — DPP example for EK-TM4C123GXL board
|
||||
</li>
|
||||
<li><span class="img folder">qk/</span> — Version for the @ref comp_qk "preemptive QK kernel"
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">arm/</span> — build with ARM-KEIL (Compiler Version 5) toolchain
|
||||
</li>
|
||||
<li><span class="img folder">armclang/</span> — build with ARM-Clang (Compiler Version 6) toolchain
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">dbg/</span> — Debug @ref exa_sec_conf "build configuration"
|
||||
</li>
|
||||
<li><span class="img folder">rel/</span> — Release build configuration
|
||||
</li>
|
||||
<li><span class="img folder">spy/</span> — Spy build configuration
|
||||
</li>
|
||||
</ul>
|
||||
<li><span class="img folder">gnu/</span> — build with GNU toolchain
|
||||
</li>
|
||||
<li><span class="img folder">iar/</span> — build with IAR toolchain
|
||||
</li>
|
||||
<li><span class="img file_c">...</span> — source code independent on the toolchain
|
||||
</li>
|
||||
</ul>
|
||||
<li><span class="img folder">qv/</span> — Version for the @ref comp_qv "cooperative QV kernel"
|
||||
</li>
|
||||
<li><span class="img folder">qxk/</span> — Version for the @ref comp_qxk "blocking QXK kernel"
|
||||
</li>
|
||||
</ul>
|
||||
<li><span class="img folder">.../</span> — Native examples for other CPU architectures...
|
||||
</li>
|
||||
|
||||
<li><span class="img folder">threadx/</span> — Examples for ThreadX (3rd-party RTOS) <span class="tag">B</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">arm-cm/</span> — Examples for ARM-Cortex-M
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">dpp_ek-tm4c123gxl/</span> — DPP example for EK-TM4C123GXL board
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">iar/</span> — build with IAR toolchain
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">dbg/</span> — Debug build configuration
|
||||
</li>
|
||||
<li><span class="img folder">rel/</span> — Release build configuration
|
||||
</li>
|
||||
<li><span class="img folder">spy/</span> — Spy build configuration
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
</ul>
|
||||
</ul>
|
||||
<li><span class="img folder">.../</span> — Native examples for other 3rd-party RTOSes...
|
||||
</li>
|
||||
|
||||
<li><span class="img folder">lwip/</span> — Examples for lwIP (3rd-party TCP/IP) <span class="tag">C</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">arm-cm/</span> — Examples for ARM-Cortex-M
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">lwip_ek-lm3s6965/</span> — lwIP example for EK-LM3S6965 board
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">qk/</span> — Version for the @ref comp_qk "preemptive QK kernel"
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">gnu/</span> — build with GNU toolchain
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">dbg/</span> — Debug build configuration
|
||||
</li>
|
||||
<li><span class="img folder">rel/</span> — Release build configuration
|
||||
</li>
|
||||
<li><span class="img folder">spy/</span> — Spy build configuration
|
||||
</li>
|
||||
</ul>
|
||||
<li><span class="img folder">iar/</span> — build with IAR toolchain
|
||||
</li>
|
||||
</ul>
|
||||
<li><span class="img folder">qv/</span> — Version for the @ref comp_qv "cooperative QV kernel"
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">gnu/</span> — build with GNU toolchain
|
||||
</li>
|
||||
<li><span class="img folder">iar/</span> — build with IAR toolchain
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
</ul>
|
||||
</ul>
|
||||
<li><span class="img folder">.../</span> — Examples for other 3rd-party middleware...
|
||||
</li>
|
||||
|
||||
<li><span class="img folder">qutest/</span> — Examples for QUTest unit testing harness <span class="tag">D</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">blinky/</span> — The simple Blinky example
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">src/</span> — source code under test
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img file_c">blinky.cpp</span> — Blinky implementation
|
||||
</li>
|
||||
<li><span class="img file_h">blinky.hpp</span> — Blinky header
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">test/</span> — code for unit testing
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img file_mak">Makefile</span> — cross-platform makefile
|
||||
</li>
|
||||
<li><span class="img file_c">test_blinky.cpp</span> — test fixture for Blinky
|
||||
</li>
|
||||
<li><span class="img file_py">test_blinky.py</span> — test script for Blinky (Python)
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<li><span class="img folder">.../</span> — Other QUTest examples...
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<li><span class="img folder">workstation/</span> — Examples for workstations (Windows, Linux, MacOS) <span class="tag">E</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">blinky/</span> — The simple Blinky example
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">build/</span> — Debug build configuration
|
||||
</li>
|
||||
<li><span class="img folder">build_rel/</span> — Release build configuration
|
||||
</li>
|
||||
<li><span class="img folder">build_spy/</span> — Spy build configuration
|
||||
</li>
|
||||
<li><span class="img file_c"> blinky.cpp</span> — blinky source code
|
||||
</li>
|
||||
<li><span class="img file_qm"> blinky.qm</span> — QM model file for Blinky
|
||||
</li>
|
||||
<li><span class="img file_mak"> Makefile</span> — cross-platform Makefile (Windows, Linux, MacOS)
|
||||
</li>
|
||||
</ul>
|
||||
<li><span class="img folder">calc/</span> — The Calculator example
|
||||
</li>
|
||||
<li><span class="img folder">comp/</span> — The Orthogonal-Component example
|
||||
</li>
|
||||
<li><span class="img folder">defer/</span> — The Deferred-Event example
|
||||
</li>
|
||||
<li><span class="img folder">dpp/</span> — The Dining-Philosophers Problem example
|
||||
</li>
|
||||
<li><span class="img folder">.../</span> — other examples for workstations...
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
<ul class="tag">
|
||||
<li><span class="tag">A</span> @subpage exa_native "Native examples" are located in sub-directories named after the CPU architecture, such as <span class="img folder">arm-cm</span> for ARM Cortex-M. Under that directory, the sub-directories <span class="img folder">blinky_ek-tm4c123gxl</span> contain the specific example on the specified board, such as "Blinky" on the EK-TM4C123GXL board here. In the specific example folder, you find sub-folders for the @ref comp_qv "QV", @ref comp_qk "QK" and @ref comp_qxk "QXK" kernels, respectively.
|
||||
</li>
|
||||
|
||||
<li><span class="tag">B</span> @subpage exa_rtos "Examples for 3rd-party RTOS"/@ref exa_os "OS" are located in sub-directories named after the RTOS/OS, such as <span class="img folder">uc-os2</span> for uc-os2 RTOS. Under that directory, the sub-directories, such as <span class="img folder">arm-cm</span>, contain examples for the specified CPU architecture, such as ARM Cortex-M here.
|
||||
</li>
|
||||
|
||||
<li><span class="tag">C</span> @subpage exa_mware "Examples for 3rd-party Middleware" are located in sub-directories named after the middleware, such as <span class="img folder">lwIP</span> for the lwIP TCP/IP stack. Under that directory, the sub-directories, such as <span class="img folder">arm-cm</span>, contain examples for the specified CPU architecture, such as ARM Cortex-M here.
|
||||
</li>
|
||||
|
||||
<li><span class="tag">D</span> @subpage exa_qutest "Examples for QUTest" illustrate unit testing of embedded event-driven code. <span class="highlight"><b>NOTE:</b> Examples in this directory can run on all types of workstations (Windows, Linux, MacOS), as well as embedded targets.</span>
|
||||
</li>
|
||||
|
||||
<li><span class="tag">E</span> @subpage exa_os "Examples for Workstations" provide console-based examples described in the [PSiCC2](/psicc2) book, which you can try directly on your workstation without any embedded hardware. <span class="highlight"><b>NOTE:</b> Examples in this directory can also be used on the <b>embedded</b> versions of the desktop operating systems, such as embedded-Linux and Windows-embedded.</span>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
@note
|
||||
Because the QP distribution contains *all* examples, the number of sub-directories and files in the <span class="img folder">examples</span> folder may seem daunting. However, knowing the structure of the <span class="img folder">examples</span> folder, you can simply ignore or even delete the sub-directories that are not interesting to you.
|
||||
|
||||
|
||||
@subsection exa_sec_apps Example Applications
|
||||
To demonstrate QP/C++ features on an embedded board, you need to create an application that does "something interesting". Instead of inventing this "something interesting" for each and every example, the example projects implement one of the three @subpage exa_apps "example applications", which are described on the separate pages:
|
||||
|
||||
- @ref tut_blinky
|
||||
- @ref tut_dpp
|
||||
- @ref tut_game
|
||||
|
||||
With the exception of the game application, all other example applications can be implemented on a board with just a couple of LEDs. The @ref game application is a bit more involved and requires a small graphic display on the board.
|
||||
|
||||
Beyond these basic applications for demonstrating and testing the various @ref ports "QP/C++ ports", the QP/C++ distribution contains all examples described in the book <a class="extern" target="_blank" href="https://www.state-machine.com/psicc2" >Practical UML Statecharts in C/C++, 2nd Edition</a>.
|
||||
@sa @ref exa_os
|
||||
|
||||
|
||||
@subsection exa_sec_boards Development Boards
|
||||
While some provided examples can run on your @ref exa_os "desktop computer", most embedded example projects require special hardware in form of @ref exa_sec_boards, which you need to acquire to be able to run the examples. The boards chosen for the examples are generally inexpensive and self-contained with no need for external hardware (such as external JTAG debuggers or power supplies).
|
||||
|
||||
|
||||
@subsection exa_sec_tools Development Tools
|
||||
Most provided examples require special embedded cross-development tools, such as embedded compilers, linkers, debuggers and IDEs, which you need to acquire independently from the QP/C++ distribution. Generally, the examples work with the free (size limited) evaluation versions of the commercial tools. The examples list the versions of tools they were developed and tested with. Please refer to the @ref exa_ref "cross-reference section" @ref exa_sec_tools to see which embedded toolchains are used.
|
||||
|
||||
|
||||
@subsection exa_sec_conf Build Configurations
|
||||
QP examples @ref ports "QP ports" are provided in the following three **build configurations**:
|
||||
|
||||
- **Debug** — this configuration is built with full debugging information and minimal optimization. When the QP framework finds no events to process, the framework busy-idles until there are new events to process. The @ref comp_qs "QS trace instrumentation" is **disabled**.
|
||||
|
||||
- **Release** — this configuration is built with no debugging information and high optimization. Single-stepping and debugging at the source-code level is effectively impossible due to the lack of debugging information and optimized code, but the debugger can be used to download and start the executable. When the QP framework finds no events to process, the framework puts the CPU to sleep until there are new events to process. The @ref comp_qs "QS trace instrumentation" is **disabled**.
|
||||
|
||||
- **Spy** — like the debug variant, this variant is built with full debugging information and minimal optimization. Additionally, it is build with the @ref comp_qs "QS trace instrumentation" enabled. The on-board serial port and the Q-Spy host application are used for sending and viewing trace data. Like the Debug configuration, the QP framework busy-idles until there are new events to process.
|
||||
|
||||
|
||||
@remark
|
||||
<strong>Why do you need multiple build configurations?</strong>@n
|
||||
The different phases of embedded software life cycle pose different challenges. During the development and maintenance phase, for example, the emphasis is on the ease of debugging and verifying the correctness of the code, which require lower levels of optimization and special scaffolding code. In contrast, for releasing the code in the final product, the emphasis is on small memory footprint and CPU time efficiency, which require high-level of optimization and removal of any scaffolding code. To address these conflicting needs, the same source code is compiled into multiple **build configurations** that differ in the use of compiler options and activation of the scaffolding code.
|
||||
|
||||
|
||||
@subsection exa_sec_qm QM Models
|
||||
Many example projects contain code auto-generated by the <a class="extern" target="_blank" href="https://www.state-machine.com/products/qm/"><strong>QM modeling tool</strong></a>. Such projects always contain the corresponding **QM model** file, which you can open in QM, modify, and re-generate the code.
|
||||
|
||||
@note
|
||||
The auto-generated files are saved as **read-only**. This protects them from inadvertent modifications, which will get lost when the files are re-generated by QM (or QMC). All modifications to the auto-generated code should be done in the QM model, not in the code.
|
||||
|
||||
|
||||
@subsection exa_sec_3rd Third-Party Code
|
||||
The QP/C++ example projects often need to use various additional code, such as MCU register definition files, startup code, device drivers, etc., which are provided by Third-Party vendors. All such code is located in the <span class="img folder">3rd_party</span> <a href="files.html">top-level folder</a>.
|
||||
|
||||
@note
|
||||
As far as possible, the code in the <span class="img folder">3rd_party</span> folder has been left unchanged from the original source. (Any modified code is clearly identified by top-level comments that detail the applied changes.) For that reason, the Third-Party code might produce **compilation warnings** in your builds.
|
||||
|
||||
The code in the <span class="img folder">3rd_party</span> folder comes from various sources, and Quantum
|
||||
Leaps, LLC expressly makes **no claims of ownership** to any of this code, even though some of the code might be customized or modified by Quantum Leaps.
|
||||
|
||||
@attention
|
||||
The Third-Party software components included in the <span class="img folder">3rd_party</span> folder are licensed under a variety of different licensing terms that are defined by the respective owners of this software and are spelled out in the `README.txt` or `LICENSE.txt` files included in the respective
|
||||
sub-folders.
|
||||
|
||||
|
||||
@subsection exa_own Creating your Own QP/C++ Projects
|
||||
Perhaps the most important fact of life to remember is that in embedded systems nothing works until everything works. This means that you should always start with a <strong>working system</strong> and gradually evolve it, changing one thing at a time and making sure that it keeps working every step of the way.
|
||||
|
||||
Keeping this in mind, the provided QP/C++ application examples, such as the super-simple Blinky, or a bit more advanced @ref dpp or @ref game, allow you to get started with a working project rather than starting from scratch. You should also always try one of the provided example projects on the same evaluation board that it was designed for, before making any changes.
|
||||
|
||||
@note
|
||||
The evaluation boards used in the examples are all very **inexpensive** and available from major electronic distributors (e.g., [Arrow](https://www.arrow.com/), [DigiKey](https://www.digikey.com/), [Mouser](https://www.mouser.com/), [Avnet](https://www.avnet.com)), as well as directly from the silicon vendors (e.g., a TI board is also available from TI.com).
|
||||
|
||||
@remark
|
||||
Even before you acquire a specific evaluation board, you can always at least **build** a project that interests you on your workstation.
|
||||
|
||||
|
||||
Only after convincing yourself that the example project works "as is", you can think about creating your own projects. At this point, the easiest and recommended way is to copy the existing working example project folder (such as the Blinky example) and rename it.
|
||||
|
||||
After copying the project folder, you still need to change the name of the project/workspace. The easiest and safest way to do this is to open the project/workspace in the corresponding IDE and use the Save As... option to save the project under a different name. You can do this also with the QM model file, which you can open in QM and "Save As" a different model.
|
||||
|
||||
@note
|
||||
By copying and re-naming an existing, working project, as opposed to creating a new one from scratch, you inherit the correct compiler and linker options an other project settings, which will help you get started much faster.
|
||||
|
||||
|
||||
@subsection exa_doc Next Steps and Further Reading About QP and QM
|
||||
|
||||
To work with QP/C++ effectively, you need to learn a bit more about active objects and state machines. Below is a list of links to enable you to further your knowledge:
|
||||
|
||||
1. The book “Practical UML Statecharts in C/C++, 2nd Edition” [PSiCC2] and the companion web-page to the book (https://www.state-machine.com/psicc2/
|
||||
2. Free Support Forum for QP/QM (https://sourceforge.net/p/qpc/discussion/668726 )
|
||||
3. QP Code Downloads summary (https://www.state-machine.com/#Downloads )
|
||||
4. QP Application Notes (https://www.state-machine.com/an/ )
|
||||
5. "State Space" Blog (https://www.state-machine.com/category/blog/ )
|
||||
|
||||
@next{exa_ref}
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_ref Cross-Reference
|
||||
|
||||
@section exa_ref_kernel Native Examples (by Built-in Kernel)
|
||||
- @ref exa_qv
|
||||
- @ref exa_qk
|
||||
- @ref exa_qxk
|
||||
|
||||
|
||||
@section exa_ref_tool Native Examples (by Development Toolchain)
|
||||
|
||||
@subsection exa_ref_arm-clang ARM-Clang Toolchain (ARM Compiler 6)
|
||||
- @ref arm-cm_blinky_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="NUCLEO-L053R8"></a> (Cortex-M0+)
|
||||
- @ref arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="NUCLEO-L152RE"></a> (Cortex-M3)
|
||||
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_stm32f4-discovery <a class="preview board" href="bd_STM32F4-Discovery.jpg" title="STM32F4-Discovery"></a>
|
||||
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="NUCLEO-L053R8"></a> (Cortex-M0+)
|
||||
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_nucleo-h743zi <a class="preview board" href="bd_NUCLEO-H743ZI.jpg" title="NUCLEO-H743ZI"></a> (Cortex-M7)
|
||||
|
||||
|
||||
@subsection exa_ref_gnu-arm GNU-ARM (command-line with Makefile, importable to Eclipse)
|
||||
- @ref arm-cm_blinky_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a> (Cortex-M4)
|
||||
- @ref arm-cm_blinky_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="NUCLEO-L053R8"></a> (Cortex-M0+)
|
||||
- @ref arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="NUCLEO-L152RE"></a> (Cortex-M3)
|
||||
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_stm32f4-discovery <a class="preview board" href="bd_STM32F4-Disco.jpg" title="STM32F4-Discovery"></a>
|
||||
- @ref lwip_ek-lm3s6965 <a class="preview board" href="bd_EK-LM3S6965.jpg" title="EK-LM3S6965"></a> (Cortex-M3)
|
||||
|
||||
|
||||
@subsection exa_ref_gnu-ccs GNU-ARM with TI CCS IDE
|
||||
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a> (Cortex-M4)
|
||||
|
||||
|
||||
@subsection exa_ref_iar-arm IAR EWARM
|
||||
- @ref arm-cm_blinky_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a> (Cortex-M4)
|
||||
- @ref arm-cm_blinky_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a> (Cortex-M4)
|
||||
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="NUCLEO-L053R8"></a> (Cortex-M0+)
|
||||
- @ref arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="NUCLEO-L152RE"></a> (Cortex-M3)
|
||||
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> (Cortex-M4)
|
||||
- @ref arm-cr_blinky_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a> (Cortex-R4)
|
||||
- @ref arm-cr_dpp_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a> (Cortex-R4)
|
||||
- @ref lwip_ek-lm3s6965 <a class="preview board" href="bd_EK-LM3S6965.jpg" title="EK-LM3S6965"></a> (Cortex-M3)
|
||||
|
||||
|
||||
@subsection exa_ref_ccs-430 CCS for MSP430
|
||||
- @ref msp430_blinky_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
- @ref msp430_dpp_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
|
||||
|
||||
@subsection exa_ref_iar-430 IAR EW430
|
||||
- @ref msp430_blinky_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
- @ref msp430_dpp_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
|
||||
|
||||
@section exa_ref_native Native Examples (by Processor)
|
||||
- @ref exa_arm-cm
|
||||
- @ref exa_arm-cr
|
||||
- @ref exa_msp430 ("classic" MSP430 and "extended" MSP430x)
|
||||
|
||||
|
||||
@section exa_ref_rtos Examples for Third-Party RTOS
|
||||
- @ref exa_embos (SEGGER)
|
||||
- @ref exa_freertos (Amazon Web Services)
|
||||
- @ref exa_threadx (Express Logic)
|
||||
- @ref exa_uc-os2 (Micrium/SiLabs)
|
||||
|
||||
|
||||
@section exa_ref_os Examples for Workstations (Windows, Linux, MacOS)
|
||||
The examples in the "workstation" directory are designed for workstations (running Windows, Linux, or MacOS), but they can also be used for projects intended for the **embedded** versions of the "big" operating systems (e.g., embedded-Linux or Windows-embedded). These examples are based on the following QP ports:
|
||||
|
||||
- @ref exa_os "POSIX-QV" — single-threaded examples for POSIX-QV (Linux, MacOS)
|
||||
- @ref exa_os "POSIX" — multi-threaded examples for POSIX (Linux, MacOS, QNX, etc.)
|
||||
- @ref exa_os "Windows-QV" — single-threaded examples for Windows
|
||||
- @ref exa_os "Windows" — multi-threaded examples for Windows
|
||||
|
||||
|
||||
@section exa_ref_mware Examples for Third-Party Middleware
|
||||
- @ref exa_lwip (open source, see http://lwip.wikia.com/wiki/LwIP_Wiki )
|
||||
- @ref exa_emwin (SEGGER, a.k.a. uC/GUI by Micrium)
|
||||
|
||||
|
||||
@section exa_ref_boards Examples by Development Board
|
||||
The boards chosen for the examples are generally inexpensive and self-contained with minimal need for external hardware (such as external JTAG debuggers or power supplies). Also, all the selected boards provide a virtual COM port (ideally) or can be easily connected to a TTL-to-USB serial converter cable for @ref comp_qs "QS software tracing" output.
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
|
||||
@subsection exa_ref_arm-cm ARM Cortex-M Boards
|
||||
|
||||
@anchor EK-TM4C123GXL
|
||||
|
||||
|
||||
- @ref arm-cm_blinky_ek-tm4c123gxl (QV, QK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
- @ref arm-cm_dpp_ek-tm4c123gxl (QV, QK, QXK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
- @ref freertos_dpp_ek-tm4c123gxl (FreeRTOS kernel; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
- @ref freertos_dpp_nucleo-h743zi (FreeRTOS kernel; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
- @ref threadx_dpp_ek-tm4c123gxl (ThreadX kernel; IAR-EWARM toolchain)
|
||||
- @ref uc-os2_dpp_ek-tm4c123gxl (uC/OS-II kernel; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
|
||||
|
||||
@anchor EFM32-SLSTK3401A
|
||||
|
||||
- @ref arm-cm_blinky_efm32-slstk3401a (QV, QK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
- @ref arm-cm_dpp_efm32-slstk3401a (QV, QK, QXK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
- @ref arm-cm_game_efm32-slstk3401a (QV, QK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains; <a href="https://www.state-machine.com/qtools/qwin.html"><b>QWin-GUI emulation</b></a>)
|
||||
|
||||
|
||||
@anchor mbed-LPC1768
|
||||
|
||||
- @ref arm-cm_dpp_mbed-lpc1768 (QV, QK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
|
||||
|
||||
@anchor NUCLEO-L053R8
|
||||
|
||||
- @ref arm-cm_dpp_nucleo-l053r8 (QV, QK, QXK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
|
||||
|
||||
@anchor NUCLEO-L152RE
|
||||
|
||||
- @ref arm-cm_dpp_nucleo-l152re (QV, QK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
- @ref uc-os2_dpp_nucleo-l053r8 (uC/OS-II kernel; ARM-KEIL, IAR-EWARM toolchains)
|
||||
|
||||
|
||||
@anchor exa_EK-LM3S6965
|
||||
|
||||
- @ref lwip_ek-lm3s6965 (**LwIP TCP/IP**; QV, QK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
|
||||
|
||||
@anchor NUCLEO-H743ZI
|
||||
|
||||
- @ref arm-cm_dpp_nucleo-h743zi (QV, QK, QXK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
- @ref freertos_dpp_nucleo-h743zi (FreeRTOS kernel; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
|
||||
|
||||
@anchor STM32F4-Discovery
|
||||
|
||||
- @ref arm-cm_dpp_stm32f4-discovery (QV, QK, QXK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
- @ref embos_dpp_stm32f429-discovery (embOS kernel; IAR-EWARM toolchain)
|
||||
- @ref threadx_dpp_stm32f429-discovery (ThreadX kernel; IAR-EWARM toolchain)
|
||||
|
||||
|
||||
@anchor STM32F746G-Discovery
|
||||
|
||||
- @ref arm-cm_dpp_stm32f746g-disco (QV, QK, QXK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
- @ref freertos_dpp_stm32f746g-disco (FreeRTOS kernel; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
|
||||
|
||||
|
||||
@subsection exa_ref_arm-cr ARM Cortex-R Boards:
|
||||
@anchor LAUNCHXL2-TMS57012
|
||||
|
||||
- @ref arm-cr_blinky_launchxl2-tms57012 (QV, QK kernels; CCS-TI-ARM, IAR-EWARM toolchains)
|
||||
- @ref arm-cr_dpp_launchxl2-tms57012 (QV, QK kernels; CCS-TI-ARM, IAR-EWARM toolchains)
|
||||
|
||||
|
||||
@subsection exa_ref_msp430 MSP430 Boards:
|
||||
@anchor MSP-EXP430F5529LP
|
||||
|
||||
- @ref msp430_blinky_msp-exp430f5529lp (QV, QK kernels; CCS=430, IAR-EW430 toolchains)
|
||||
- @ref msp430_dpp_msp-exp430f5529lp (QV, QK kernels; CCS=430, IAR-EW430 toolchains)
|
||||
|
||||
|
||||
@section exa_ref_mcu Examples by MCU Architecture
|
||||
- ARM Cortex-M0/M0+
|
||||
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="NUCLEO-L053R8"></a>
|
||||
- ARM Cortex-M3
|
||||
- @ref arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="NUCLEO-L152RE"></a>
|
||||
- @ref arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a>
|
||||
- @ref lwip_ek-lm3s6965 <a class="preview board" href="bd_EK-LM3S6965.jpg" title="EK-LM3S6965"></a>
|
||||
- ARM Cortex-M4 (with hardware FPU)
|
||||
- @ref arm-cm_blinky_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cm_blinky_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_dpp_stm32f4-discovery <a class="preview board" href="bd_STM32F4-Disco.jpg" title="STM32F4-Discovery"></a>
|
||||
- ARM Cortex-M7 (with hardware single-precision FPU)
|
||||
- @ref arm-cm_dpp_stm32f746g-disco <a class="preview board" href="bd_STM32F746G-Disco.jpg" title="STM32F746G-Discovery"></a>
|
||||
- ARM Cortex-M7 (with hardware double-precision FPU)
|
||||
- @ref arm-cm_dpp_nucleo-h743zi <a class="preview board" href="bd_NUCLEO-H743ZI.jpg" title="NUCLEO-H743ZI"></a>
|
||||
- ARM Cortex-R
|
||||
- @ref arm-cr_blinky_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a>
|
||||
- @ref arm-cr_dpp_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a>
|
||||
|
||||
- MSP430
|
||||
- @ref msp430_blinky_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
- @ref msp430_dpp_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
|
||||
@section exa_ref_vendor Examples by MCU Vendor
|
||||
- NXP
|
||||
- @ref arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a>
|
||||
- Silicon Labs
|
||||
- @ref arm-cm_blinky_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- ST Microelectronics
|
||||
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="NUCLEO-L053R8"></a>
|
||||
- @ref arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="NUCLEO-L152RE"></a>
|
||||
- @ref arm-cm_dpp_stm32f4-discovery <a class="preview board" href="bd_STM32F4-Disco.jpg" title="STM32F4-Discovery"></a>
|
||||
- @ref arm-cm_dpp_stm32f746g-disco <a class="preview board" href="bd_STM32F746G-Disco.jpg" title="STM32F746G-Discovery"></a>
|
||||
- Texas Instruments
|
||||
- @ref arm-cm_blinky_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cr_blinky_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a>
|
||||
- @ref arm-cr_dpp_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a>
|
||||
- @ref lwip_ek-lm3s6965 <a class="preview board" href="bd_EK-LM3S6965.jpg" title="EK-LM3S6965"></a>
|
||||
|
||||
@next{exa_native}
|
||||
*/
|
||||
@ -1,142 +0,0 @@
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_apps Example Applications
|
||||
|
||||
<p>To demonstrate QP/C++ features, you need to create an application that does "something interesting". Instead of inventing this "something interesting" for each and every example, most of the example projects implement one of the three example applications, which are described on the separate pages:
|
||||
</p>
|
||||
|
||||
- @subpage blinky
|
||||
- @subpage dpp
|
||||
- @subpage game
|
||||
- @subpage pelican
|
||||
|
||||
Additionally, the QP/C++ distribution contains several application examples described in the <a class="extern" target="_blank" href="https://www.state-machine.com/psicc2">PSiCC2</a> book.
|
||||
|
||||
- Calculator example from Chapter 2 of PSiCC2
|
||||
- Orthogonal Component design pattern
|
||||
- Orthogonal Component with QM model design pattern
|
||||
- Deferred Event design pattern
|
||||
- Transition-to-History (with QP::QHsm class)
|
||||
- Transition-to-History (with QP::QMsm class)
|
||||
- QMsmTst Test State Machine based on QP::QMsm with QM model
|
||||
- QHsmTst Test State Machine based on QP::QHsm with QM model
|
||||
- Reminder design pattern from Chapter 5 of PSiCC2
|
||||
- Reminder design pattern different version
|
||||
|
||||
@next{blinky}
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page blinky Simple Blinky Application
|
||||
|
||||
<p>The ultra-simple Blinky example is the embedded systems' equivalent of the venerable <i>"Hello World!"</i> program, that is, the simplest possible working QP application that does "something". In the case of Blinky, this "something" is blinking an LED at the rate of 1Hz, where an LED turns on and remains on for 0.5 seconds on then turns off and remains off for 0.5 seconds.
|
||||
</p>
|
||||
|
||||
@image html blinky_ek-tm4c123gxl.gif Blinky on EK-TM4C123GLX (TivaC LaunchPad)
|
||||
|
||||
The ultra-simple Blinky application, which consists of just one active object named `Blinky`, is intentionally kept small and illustrates only the most basic QP features, such as:
|
||||
|
||||
- defining a simple Blinky active object (AO) @ref oop "class";
|
||||
- hand-coding the simple state machine of the Blinky AO;
|
||||
- using a periodic time event;
|
||||
- initializing the QP framework; and
|
||||
- starting an AO.
|
||||
|
||||
|
||||
|
||||
@section blinky_sm State Machine
|
||||
The very simple state machine of the Blinky AO is shown in the figure below:
|
||||
|
||||
@image html SM_blinky.png "State Machine of the Blinky AO"
|
||||
|
||||
<ul class="tag">
|
||||
<li><span class="tag">1</span> The top-most initial transition in this state machine arms a QP time event (QTimeEvt_armX()) to deliver the `TIMEOUT` signal every half second, so that the LED can stay on for one half second and off for the other half.
|
||||
</li>
|
||||
|
||||
<li><span class="tag">2</span> The initial transition leads to state "off", which turns the LED off in the entry action (`BSP_ledOff()`).
|
||||
</li>
|
||||
|
||||
<li><span class="tag">3</span> When the `TIMEOUT` event arrives in the "off" state, the "off" state transitions to the "on" state
|
||||
</li>
|
||||
<li><span class="tag">4</span> The "on" state turns the LED on in the entry action (`BSP_ledOn()`).
|
||||
</li>
|
||||
<li><span class="tag">5</span> When the `TIMEOUT` event arrives in the "on" state, the "on" state transitions back to "off", which cases execution of the entry action, in which the LED is turned off. From that point on the cycle repeats forever because the `TIMEOUT` events keep getting generated at the pre-determined rate.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
@section blinky_code State Machine Code
|
||||
The Blinky state machine shown above is implemented in the blinky.c source file, as shown in the
|
||||
listing below. The code has been specifically organized not to access target resources directly, but instead encapsulate all such access in the calls to the BSP (Board Support Package). So for example, instead of turning the LED on and off by writing to a specific GPIO register on an embedded board, the code calls the BSP functions `BSP_ledOn()` and `BSP_ledOff()`. These functions can then be defined differently for each Target board (or even a desktop workstation), without the need to change the state machine code.
|
||||
|
||||
@note
|
||||
The Blinky source code (blinky.c) is actually the same on all platforms, including Windows
|
||||
and the embedded boards. The only difference is in the Board Support Package (bsp.c), which is
|
||||
specific for the target.
|
||||
|
||||
@includelineno examples/arm-cm/blinky_ek-tm4c123gxl/blinky.cpp
|
||||
|
||||
As you can see, the structure of the state machine is very clearly recognizable in this code. Please refer to the Application Note <a class="extern" target="_blank" href="http://state-machine.com/doc/AN_Crash_Course_in_UML_State_Machines.pdf">A Crash Course in UML State Machines</a> for exact explanation of the state machine coding techniques.
|
||||
|
||||
|
||||
@subsection blinky_ao Defining Active Object (AO) Class
|
||||
|
||||
|
||||
- hand-coding the simple state machine of the Blinky AO;
|
||||
- using a periodic time event;
|
||||
- initializing the QP framework; and
|
||||
- starting an AO.
|
||||
|
||||
@next{dpp}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page dpp Dining Philosophers Problem (DPP)
|
||||
|
||||
The Dining Philosophers Problem (DPP) example is described in the <a class="extern" target="_blank" href="https://www.state-machine.com/doc/AN_DPP.pdf">Application Note: Dining Philosophers Problem (DPP) Example</a>.
|
||||
|
||||
@htmlonly
|
||||
<div class="image">
|
||||
<a target="_blank" href="https://www.state-machine.com/doc/AN_DPP.pdf"><img border="0" src="img/AN.jpg" title="Download PDF"></a>
|
||||
<div class="caption">
|
||||
Application Note: Dining Philosophers Problem (DPP) Example
|
||||
</div>
|
||||
</div>
|
||||
@endhtmlonly
|
||||
|
||||
@next{game}
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page game "Fly 'n' Shoot" Game
|
||||
|
||||
The "Fly 'n' Shoot" game example is described in the <a class="extern" target="_blank" href="https://www.state-machine.com/doc/AN_Fly-n-Shoot.pdf">Application Note: Fly 'n' Shoot Game Example</a>.
|
||||
|
||||
@htmlonly
|
||||
<div class="image">
|
||||
<a target="_blank" href="https://www.state-machine.com/doc/AN_Fly-n-Shoot.pdf"><img border="0" src="img/AN.jpg" title="Download PDF"></a>
|
||||
<div class="caption">
|
||||
Application Note: Fly 'n' Shoot Game Example
|
||||
</div>
|
||||
</div>
|
||||
@endhtmlonly
|
||||
|
||||
@next{pelican}
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page pelican PEdestrian LIgtht CONtrolled (PELICAN) Crossing
|
||||
|
||||
The "Fly 'n' Shoot" game example is described in the <a class="extern" target="_blank" href="https://www.state-machine.com/doc/AN_PELICAN.pdf">Application Note: PEdestrian LIght CONtrolled (PELICAN) Crossing Example</a>.
|
||||
|
||||
@htmlonly
|
||||
<div class="image">
|
||||
<a target="_blank" href="https://www.state-machine.com/doc/AN_PELICAN.pdf"><img border="0" src="img/AN.jpg" title="Download PDF"></a>
|
||||
<div class="caption">
|
||||
Application Note: PEdestrian LIght CONtrolled (PELICAN) Crossing Example
|
||||
</div>
|
||||
</div>
|
||||
@endhtmlonly
|
||||
|
||||
@next{ports}
|
||||
*/
|
||||
|
||||
|
||||
@ -1,101 +0,0 @@
|
||||
namespace QP {
|
||||
|
||||
/*! @page exa_mware Examples for Third-Party Middleware
|
||||
|
||||
- @subpage exa_qt
|
||||
- @subpage exa_lwip
|
||||
- @subpage exa_emwin
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_qt Qt (GUI Framework)
|
||||
|
||||
- \subpage qt_dpp
|
||||
- \subpage qt_dpp-gui
|
||||
- \subpage qt_game-gui
|
||||
- \subpage qt_pelican-gui
|
||||
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page qt_dpp DPP (Console) for Qt
|
||||
|
||||
@image html under_construction.jpg
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page qt_dpp-gui DPP-GUI for Qt
|
||||
|
||||
@image html under_construction.jpg
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page qt_game-gui Game-GUI for Qt
|
||||
|
||||
@image html qt_game-gui.png
|
||||
@n@n
|
||||
@image html qtcreator_game-gui.png
|
||||
@n@n
|
||||
@image html qtdesign_game-gui.png
|
||||
@n@n
|
||||
@image html under_construction.jpg
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page qt_pelican-gui PELICAN-GUI for Qt
|
||||
|
||||
PEdestrian LIght CONtrolled (PELICAN) crossing example for Qt
|
||||
|
||||
@image html qt_pelican-gui.png
|
||||
@n@n
|
||||
@image html qtdesign_pelican-gui.png
|
||||
@n@n
|
||||
@image html under_construction.jpg
|
||||
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_lwip lwIP TCP/IP
|
||||
|
||||
- @subpage lwip_ek-lm3s6965
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page lwip_ek-lm3s6965 lwIP on EK-LM3S6965
|
||||
|
||||
@image html bd_EK-LM3S6965.jpg EK-LM3S6965 board
|
||||
|
||||
lwIP example for Texas Instruments EK-LM3S6965 (Cortex-M3) with GNU-ARM and IAR-ARM toolsets.
|
||||
|
||||
@image html bd_EK-LM3S6965_lwip.jpg QP-lwIP on EK-LM3S6965
|
||||
@n@n
|
||||
|
||||
@section lwip_AN Application Note: QP and lwIP TCP/IP Stack
|
||||
The [Application Note](https://www.state-machine.com/doc/AN_QP_and_lwIP.pdf) describes how to use the lightweight TCP/IP stack called lwIP with the QP real-time embedded frameworks.
|
||||
|
||||
[](https://www.state-machine.com/doc/AN_QP_and_lwIP.pdf)
|
||||
@htmlonly
|
||||
<div class="caption">
|
||||
Application Note: QP and lwIP TCP/IP Stack
|
||||
</div>
|
||||
@endhtmlonly
|
||||
|
||||
@next{ exa_emwin}
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_emwin emWin Embedded GUI
|
||||
|
||||
<p>The <a href="https://www.state-machine.com/doc/AN_QP_emWin.pdf" target="_blank" class="extern"><strong>Application Note "QP and emWin Embedded GUI"</strong></a> describes how to use QP™ with the <a href="https://www.segger.com/emwin.html" target="_blank" class="extern">emWin™ Embedded GUI from SEGGER</a> and also <a href="https://www.micrium.com/rtos/gui/" target="_blank" class="extern">µC/GUI from Micrium</a>, which technically are the same products.
|
||||
</p>
|
||||
|
||||
@image html emWin_demo.jpg QP-emWin demo (DPP) running on Windows
|
||||
|
||||
|
||||
To demonstrate the working examples, this Application Note uses the emWin Simulation on Windows, which is available for a <a href="https://www.segger.com/downloads/emwin" target="_blank" class="extern">free download from the SEGGER</a> (requires registration). You need only a Windows-based PC to execute the examples provided in this Application Note. Additionally, you'd need Microsoft Visual Studio 2013 (could be the free Express Edition) or higher to re-build and debug the provided examples.
|
||||
|
||||
@note
|
||||
Although the QP-emWin (µC/GUI) integration runs on Windows, the application-level code uses exclusively the embedded emWin™ API and is designed to run without any modifications on embedded targets.
|
||||
*/
|
||||
|
||||
} // namespace QP
|
||||
@ -1,615 +0,0 @@
|
||||
namespace QP {
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_native Native Examples (Built-in Kernels)
|
||||
|
||||
<p>The QP/C++ framework contains real-time kernels (@ref comp_qv and @ref comp_qk), so it can run natively ("bare-metal") on single-chip microcontrollers, completely replacing a traditional RTOS. Click on the following links to see examples for the specified built-in kernels:
|
||||
</p>
|
||||
- @subpage exa_qv
|
||||
- @subpage exa_qk
|
||||
- @subpage exa_qxk
|
||||
|
||||
Click on the following links to see examples for the specified CPU architectures:
|
||||
- @subpage exa_arm-cm
|
||||
- @subpage exa_arm-cr
|
||||
- @subpage exa_msp430
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_qv QV Kernel (Non-Preemptive, Priority-Based, Non-Blocking)
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
- @ref arm-cm_blinky_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cm_blinky_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a>
|
||||
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="STM32 NUCLEO-L053R8"></a>
|
||||
- @ref arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="STM32 NUCLEO-L152RE"></a>
|
||||
- @ref arm-cm_dpp_stm32f4-discovery <a class="preview board" href="bd_STM32F4-Disco.jpg" title="STM32F4-Discovery"></a>
|
||||
- @ref arm-cm_dpp_nucleo-h743zi <a class="preview board" href="bd_NUCLEO-H743ZI.jpg" title="STM32 NUCLEO-H743ZI"></a>
|
||||
- @ref arm-cm_dpp_nucleo-l552ze <a class="preview board" href="bd_NUCLEO-L552ZE.jpg" title="STM32 NUCLEO-L552ZE Q"></a>
|
||||
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref tut_low <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cr_blinky_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a>
|
||||
- @ref arm-cr_dpp_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a>
|
||||
- @ref msp430_blinky_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
- @ref msp430_dpp_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_qk QK Kernel (Preemptive, Run-To-Completion/Non-Blocking)
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
- @ref arm-cm_blinky_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cm_blinky_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a>
|
||||
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="STM32 NUCLEO-L053R8"></a>
|
||||
- @ref arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="STM32 NUCLEO-L152RE"></a>
|
||||
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_dpp_stm32f4-discovery <a class="preview board" href="bd_STM32F4-Disco.jpg" title="STM32F4-Discovery"></a>
|
||||
- @ref arm-cm_dpp_nucleo-h743zi <a class="preview board" href="bd_NUCLEO-H743ZI.jpg" title="STM32 NUCLEO-H743ZI"></a>
|
||||
- @ref arm-cm_dpp_nucleo-l552ze <a class="preview board" href="bd_NUCLEO-L552ZE.jpg" title="STM32 STM32 NUCLEO-L552ZE Q"></a>
|
||||
- @ref tut_low <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cr_blinky_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a>
|
||||
- @ref arm-cr_dpp_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a>
|
||||
- @ref msp430_blinky_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
- @ref msp430_dpp_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_qxk QXK Kernel (Preemptive, Run-To-Completion/Blocking)
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref arm-cm_dpp_stm32f4-discovery <a class="preview board" href="bd_STM32F4-Disco.jpg" title="STM32F4-Discovery"></a>
|
||||
- @ref arm-cm_dpp_nucleo-l552ze <a class="preview board" href="bd_NUCLEO-L552ZE.jpg" title="STM32 NUCLEO-L552ZE Q"></a>
|
||||
- @ref arm-cm_dpp_nucleo-h743zi <a class="preview board" href="bd_NUCLEO-H743ZI.jpg" title="STM32 NUCLEO-H743ZI"></a>
|
||||
- @ref tut_low <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_arm-cm ARM Cortex-M (Cortex-M0/M0+/M3/M4/M7/M33)
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
- @subpage arm-cm_blinky_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @subpage arm-cm_blinky_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @subpage arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
- @subpage arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @subpage arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a>
|
||||
- @subpage arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="STM32 NUCLEO-L053R8"></a>
|
||||
- @subpage arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="STM32 NUCLEO-L152RE"></a>
|
||||
- @subpage arm-cm_dpp_stm32f4-discovery <a class="preview board" href="bd_STM32F4-Disco.jpg" title="STM32F4-Discovery"></a>
|
||||
- @subpage arm-cm_dpp_nucleo-h743zi <a class="preview board" href="bd_NUCLEO-H743ZI.jpg" title="STM32 NUCLEO-H743ZI"></a>
|
||||
- @subpage arm-cm_dpp_nucleo-l552ze <a class="preview board" href="bd_NUCLEO-L552ZE.jpg" title="STM32 NUCLEO-L552ZE"></a>
|
||||
- @subpage arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a>
|
||||
- @ref tut_lowr <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_arm-cr ARM Cortex-R
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
- @subpage arm-cr_blinky_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a>
|
||||
- @subpage arm-cr_dpp_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a>
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_msp430 MSP430 ("classic" MSP430 and "extended" MSP430x)
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
|
||||
- @subpage msp430_blinky_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
- @subpage msp430_dpp_msp-exp430f5529lp <a class="preview board" href="bd_MSP-EXP430F5529LP.jpg" title="MSP-EXP430F5529LP"></a>
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_blinky_ek-tm4c123gxl Blinky on EK-TM4C123GXL
|
||||
|
||||
<p>This example implements the @ref blinky "Blinky sample application" on the EK-TM4C123GLX board (ARM Cortex-M4F).
|
||||
</p>
|
||||
|
||||
@image html bd_EK-TM4C123GXL.jpg EK-TM4C123GXL board
|
||||
|
||||
|
||||
The Blinky example is located in the directory <span class="img folder">qpcpp/examples/arm-cm/blinky_ek-tm4c123gxl</span>, which is organized as follows:
|
||||
|
||||
@code{c}
|
||||
qpcpp/ // QP/C++ installation directory
|
||||
+-examples/ // QP/C++ examples directory (application)
|
||||
| +-arm-cm/ // QP/C++ examples for ARM Cortex-M
|
||||
| | +-blinky_ek-tm4c123gxl/ // Blinky example on the EK-TM4C123GLX board
|
||||
| | | +-qk/ // QK version
|
||||
| | | | +-armclang/ // ARM-KEIL with arm-clang (compiler 6)
|
||||
| | | | | +-blinky-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-blinky-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.cpp // BSP for the QK kernel
|
||||
| | | +-qv/ // QV version
|
||||
| | | | +-armclang/ // ARM-KEIL with arm-clang (compiler 6)
|
||||
| | | | | +-blinky-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project with GNU-ARM
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-blinky-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.cpp // BSP for the QV kernel
|
||||
| | | +-win32/ // Windows emulation (multithreaded)
|
||||
| | | | +-Makefile // Makefile for building the project with MinGW
|
||||
| | | | +-bsp.cpp // BSP for the Win32
|
||||
| | | +-win32-qv/ // Windows emulation (single thread)
|
||||
| | | | +-Makefile // Makefile for building the project with MinGW
|
||||
| | | | +-bsp.cpp // BSP for the Win32-QV
|
||||
@endcode
|
||||
|
||||
|
||||
@section arm-cm_blinky_ek-tm4c123gxl_feat Features Demonstrated
|
||||
- cooperative QV kernel
|
||||
+ with ARM-KEIL toolchain
|
||||
+ with GNU-ARM toolchain
|
||||
+ with IAR-ARM toolchain
|
||||
- preemptive run-to-completion QK kernel
|
||||
+ with ARM-KEIL toolchain
|
||||
+ with GNU-ARM toolchain
|
||||
+ with IAR-ARM toolchain
|
||||
- Windows emulation (console multithreaded)
|
||||
- Windows emulation (console, single threaded: win32-qv)
|
||||
|
||||
|
||||
@section arm-cm_blinky_ek-tm4c123gxl_run Running the Example
|
||||
Once programmed into the board, the example blinks the on-board LED about once a second.
|
||||
|
||||
@image html blinky_ek-tm4c123gxl.gif Blinky on EK-TM4C123GLX (TivaC LaunchPad)
|
||||
|
||||
|
||||
@section arm-cm_blinky_ek-tm4c123gxl_win Windows Emulation
|
||||
The Windows emulation is a simple console application that produces the following output:
|
||||
|
||||
@image html blinky_win32.png Blinky emulation running in a Windows console
|
||||
|
||||
@next{arm-cm_blinky_efm32-slstk3401a}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_blinky_efm32-slstk3401a Blinky on EFM32-SLSTK3401A
|
||||
|
||||
<p>This example implements the @ref blinky "Blinky sample application" on the EFM32-SLSTK3401A board (ARM Cortex-M4F).
|
||||
</p>
|
||||
|
||||
@image html bd_EFM32-SLSTK3401A.jpg EFM32-SLSTK3401A board
|
||||
|
||||
The Blinky example is located in the directory <span class="img folder">qpcpp/examples/arm-cm/blinky_efm32-slstk3401a</span>, which is organized as follows:
|
||||
|
||||
@code{c}
|
||||
qpcpp/ // QP/C++ installation directory
|
||||
+-examples/ // QP/C++ examples directory (application)
|
||||
| +-arm-cm/ // QP/C++ examples for ARM Cortex-M
|
||||
| | +-blinky_efm32-slstk3401a/ // Blinky example on the EFM32-SLSTK3401A board
|
||||
| | | +-qk/ // QK version
|
||||
| | | | +-armclang/ // ARM-KEIL with arm-clang (compiler 6)
|
||||
| | | | | +-blinky-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-blinky-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.cpp // BSP for the QK kernel
|
||||
| | | +-qv/ // QV version
|
||||
| | | | +-armclang/ // ARM-KEIL with arm-clang (compiler 6)
|
||||
| | | | | +-blinky-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project with GNU-ARM
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-blinky-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.cpp // BSP for the QV kernel
|
||||
| | | +-win32/ // Windows emulation (multithreaded)
|
||||
| | | | +-Makefile // Makefile for building the project with MinGW
|
||||
| | | | +-bsp.cpp // BSP for the Win32
|
||||
| | | +-win32-qv/ // Windows emulation (single thread)
|
||||
| | | | +-Makefile // Makefile for building the project with MinGW
|
||||
| | | | +-bsp.cpp // BSP for the Win32-QV
|
||||
@endcode
|
||||
|
||||
|
||||
|
||||
@section arm-cm_blinky_efm32-slstk3401a_feat Features Demonstrated
|
||||
- cooperative QV kernel
|
||||
+ with ARM-KEIL toolchain
|
||||
+ with GNU-ARM toolchain
|
||||
+ with IAR-ARM toolchain
|
||||
- preemptive run-to-completion QK kernel
|
||||
+ with ARM-KEIL toolchain
|
||||
+ with GNU-ARM toolchain
|
||||
+ with IAR-ARM toolchain
|
||||
- Windows emulation (console multithreaded)
|
||||
- Windows emulation (console, single threaded: win32-qv)
|
||||
|
||||
|
||||
@section arm-cm_blinky_efm32-slstk3401a_run Running the Example
|
||||
Once programmed into the board, the example blinks the on-board LED about once a second.
|
||||
|
||||
|
||||
@section arm-cm_blinky_efm32-slstk3401a_win Windows Emulation
|
||||
The Windows emulation is a simple console application that produces the following output:
|
||||
|
||||
@image html blinky_win32.png Blinky emulation running in a Windows console
|
||||
|
||||
@next{arm-cm_dpp_ek-tm4c123gxl}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_dpp_ek-tm4c123gxl DPP on EK-TM4C123GXL
|
||||
|
||||
<p>This example implements the @ref dpp "Dining Philosophers Problem" sample application on the EK-TM4C123GLX board (ARM Cortex-M4F).
|
||||
</p>
|
||||
|
||||
@image html bd_EK-TM4C123GXL.jpg EK-TM4C123GXL board
|
||||
|
||||
The DPP example is located in the directory <span class="img folder">qpcpp/examples/arm-cm/dpp_ek-tm4c123gxl</span>, which is organized as follows:
|
||||
|
||||
@code{c}
|
||||
qpcpp/ // QP/C++ installation directory
|
||||
+-examples/ // QP/C++ examples directory (applications)
|
||||
| +-arm-cm/ // QP/C++ examples for ARM Cortex-M
|
||||
| | +-dpp_ek-tm4c123gxl/ // DPP example on the EK-TM4C123GLX board
|
||||
| | | +-lint-plus/ // PC-Lint-Plus version (static analysis of the application code)
|
||||
| | | | +-lin.bat // batch file for running the PC-Lint
|
||||
| | | | +-options.lnt // PC-Lint options file for the application code
|
||||
| | | +-qk/ // QK version
|
||||
| | | | +-armclang/ // ARM-KEIL with arm-clang (compiler 6)
|
||||
| | | | | +-dpp-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-dpp-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-ti/ // TI-ARM toolchain (CCS)
|
||||
| | | | | +-.ccsproject // CCS project
|
||||
| | | | | +-.cproject // C Eclipse project
|
||||
| | | | | +-.project // Eclipse project
|
||||
| | | | +-bsp.cpp // BSP for the QK kernel
|
||||
| | | | +-main.cpp // main() for the QK kernel
|
||||
| | | +-qv/ // QV version
|
||||
| | | | +-armclang/ // ARM-KEIL with arm-clang (compiler 6)
|
||||
| | | | | +-dpp-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project with GNU-ARM
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-blinky-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.cpp // BSP for the QV kernel
|
||||
| | | | +-main.cpp // main() for the QV kernel
|
||||
| | | +-qxk/ // QXK version
|
||||
| | | | +-armclang/ // ARM-KEIL with arm-clang (compiler 6)
|
||||
| | | | | +-dpp-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-dpp-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-ti/ // TI-ARM toolchain (CCS)
|
||||
| | | | | +-.ccsproject // CCS project
|
||||
| | | | | +-.cproject // C Eclipse project
|
||||
| | | | | +-.project // Eclipse project
|
||||
| | | | +-bsp.cpp // BSP for the QXK kernel
|
||||
| | | | +-main.cpp // main() for the QXK kernel
|
||||
| | | | +-test.cpp // extended (blocking) test threads
|
||||
| | | +-qspyview/ // visualization and monitoring for the DPP example
|
||||
| | | | +-dpp.py // QSpyView specialization for the DPP
|
||||
| | | | +-qspyview.bat // batch file for launching QSpyView for DPP
|
||||
@endcode
|
||||
|
||||
|
||||
@section arm-cm_dpp_ek-tm4c123gxl_feat Features Demonstrated
|
||||
- cooperative QV kernel
|
||||
+ with ARM-KEIL toolchain (arm-clang/compiler 6)
|
||||
+ with GNU-ARM toolchain
|
||||
+ with IAR-ARM toolchain
|
||||
+ with TI-ARM toolchain (CCS)
|
||||
- preemptive run-to-completion QK kernel
|
||||
+ with ARM-KEIL toolchain (arm-clang/compiler 6)
|
||||
+ with GNU-ARM toolchain
|
||||
+ with IAR-ARM toolchain
|
||||
+ with TI-ARM toolchain (CCS)
|
||||
- preemptive dual-mode QXK kernel
|
||||
+ with ARM-KEIL toolchain (arm-clang/compiler 6)
|
||||
+ with GNU-ARM toolchain
|
||||
+ with IAR-ARM toolchain
|
||||
+ with TI-ARM toolchain (CCS)
|
||||
- QP/Spy software tracing (output)
|
||||
- QP/Spy software tracing (input QS-RX)
|
||||
- Unit Testing with QUTest
|
||||
- Windows emulation with GUI (multithreaded)
|
||||
- Windows emulation with GUI (single threaded, win32-qv)
|
||||
|
||||
|
||||
@section arm-cm_dpp_ek-tm4c123gxl_run Running the Example
|
||||
Once programmed into the board, the example rapidly toggles the Blue LED from the idle loop (blue LED glows) and toggles the Red and Green LEDs as the Philosophers change their state. Additionally, you can depress and hold the SW1 button (left) to PAUSE the application (Table transitions into the "paused" state). Releasing the SW1 button causes transition back to the "serving" state.
|
||||
|
||||
|
||||
@section arm-cm_dpp_ek-tm4c123gxl_qutest Unit Testing
|
||||
The examples demonstrates the QUTest unit tests for the application.
|
||||
|
||||
|
||||
@section arm-cm_dpp_ek-tm4c123gxl_spy QP/Spy Software Tracing
|
||||
The application also demonstrates <a href="https://www.state-machine.com/qtools/qpspy.html" target="_blank" class="extern">QP/Spy</a> software tracing output and input. To exercise this feature, you need to build and upload the Spy build configuration into the board.
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_dpp_efm32-slstk3401a DPP on EFM32-SLSTK3401A
|
||||
|
||||
<p>This example implements the @ref dpp "Dining Philosophers Problem" sample application on the EFM32-SLSTK3401A board (ARM Cortex-M4F).
|
||||
</p>
|
||||
|
||||
@image html bd_EFM32-SLSTK3401A.jpg EFM32-SLSTK3401A board
|
||||
|
||||
The DPP example is located in the directory <span class="img folder">qpcpp/examples/arm-cm/dpp_efm32-slstk3401a</span> and includes versions for @ref qv "cooperative QV kernel", the @ref qk "preemptive QK kernel", and the @ref qxk "preemptive dual mode QXK RTOS kernel" each provided for the ARM-KEIL, GNU-ARM, and IAR-ARM. The following annotated directory listing describes the contents of the example folder:
|
||||
|
||||
@code{c}
|
||||
qpcpp/ // QP/C++ installation directory
|
||||
+-examples/ // QP/C++ examples directory (application)
|
||||
| +-arm-cm/ // QP/C++ examples for ARM Cortex-M
|
||||
| | +-dpp_efm32-slstk3401a/ // DPP example on the EK-TM4C123GLX board
|
||||
| | | +-lint-plus/ // PC-Lint-Plus version (static analysis of the application code)
|
||||
| | | | +-lin.bat // batch file for running the PC-Lint
|
||||
| | | | +-options.lnt // PC-Lint options file for the DPP application code
|
||||
| | | +-qk/ // QK version
|
||||
| | | | +-armclang/ // ARM-KEIL with arm-clang (compiler 6)
|
||||
| | | | | +-dpp-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-dpp-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.cpp // BSP for the QK kernel
|
||||
| | | | +-main.cpp // main() for the QK kernel
|
||||
| | | +-qv/ // QV version
|
||||
| | | | +-armclang/ // ARM-KEIL with arm-clang (compiler 6)
|
||||
| | | | | +-dpp-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project with GNU-ARM
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-blinky-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.cpp // BSP for the QV kernel
|
||||
| | | | +-main.cpp // main() for the QV kernel
|
||||
| | | +-qxk/ // QXK version
|
||||
| | | | +-arm/ // ARM-KEIL toolchain
|
||||
| | | | | +-dpp-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-dpp-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.cpp // BSP for the QXK kernel
|
||||
| | | | +-main.cpp // main() for the QXK kernel
|
||||
| | | | +-test.cpp // extended (blocking) test threads
|
||||
| | | +-qspyview/ // visualization and monitoring for the DPP example
|
||||
| | | | +-dpp.py // QSpyView specialization for the DPP
|
||||
| | | | +-qspyview.bat // batch file for launching QSpyView for DPP
|
||||
@endcode
|
||||
|
||||
|
||||
@section arm-cm_dpp_efm32-slstk3401a_feat Features Demonstrated
|
||||
- cooperative QV kernel
|
||||
+ with ARM-KEIL toolchain
|
||||
+ with GNU-ARM toolchain
|
||||
+ with IAR-ARM toolchain
|
||||
- preemptive run-to-completion QK kernel
|
||||
+ with ARM-KEIL toolchain
|
||||
+ with GNU-ARM toolchain
|
||||
+ with IAR-ARM toolchain
|
||||
- preemptive dual-mode QXK kernel
|
||||
+ with ARM-KEIL toolchain
|
||||
+ with GNU-ARM toolchain
|
||||
+ with IAR-ARM toolchain
|
||||
- QP/Spy software tracing (output)
|
||||
- QP/Spy software tracing (input QS-RX)
|
||||
- Unit Testing with QUTest
|
||||
- Windows emulation with GUI (multithreaded)
|
||||
- Windows emulation with GUI (single threaded, win32-qv)
|
||||
|
||||
|
||||
@section arm-cm_dpp_efm32-slstk3401a_run Running the Example
|
||||
Once programmed into the board, the example rapidly toggles the LED1 from the idle loop (LED1 glows) and toggles LED0 as the Philosophers change their state. Additionally, you can depress and hold the BTN0 button (left) to PAUSE the application (Table transitions into the "paused" state). Releasing the BTN0 button causes transition back to the "serving" state.
|
||||
|
||||
|
||||
@section arm-cm_dpp_efm32-slstk3401a_spy QP/Spy Software Tracing
|
||||
The application also demonstrates <a href="https://www.state-machine.com/qtools/qpspy.html" target="_blank" class="extern">QP/Spy</a> software tracing output and input. To exercise this feature, you need to build and upload the Spy build configuration into the board.
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_dpp_mbed-lpc1768 DPP on mbed-LPC1768
|
||||
|
||||
@image html bd_mbed-LPC1768.jpg mbed-LPC1768 board
|
||||
|
||||
Dining Philosophers Problem (DPP) example for NXP LPC1768 MCU (Cortex-M3) with GNU-ARM toolchain.
|
||||
|
||||
@image html mbed-LPC1768_button.jpg Adding External Button to mbed-LPC1768
|
||||
|
||||
<br>
|
||||
@image html under_construction.jpg
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_dpp_nucleo-l053r8 DPP on STM32 NUCLEO-L053R8
|
||||
|
||||
@image html bd_NUCLEO-L053R8.jpg NUCLEO-L053R8 board
|
||||
|
||||
@ref dpp "Dining Philosophers Problem (DPP)" example for STM32 NUCLEO-L053R8 MCU (Cortex-M0+).
|
||||
|
||||
Demonstrated built-in kernels:
|
||||
- cooperative @ref qv with ARM-Clang, ARM-Keil, GNU-ARM (Makefile and Atollic TRUEstudio), and IAR-ARM toolchains
|
||||
- preemptive, run-to-completion @ref qk with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
- dual-mode (run-to-completion/blocking) @ref qxk with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
|
||||
Features:
|
||||
- multiple active objects, including 5 instances of the same AO class (Philo)
|
||||
- extended threads (the QXK version)
|
||||
- [QP/Spy software tracing](https://www.state-machine.com/qtools/qpspy.html) using the virtual COM-port
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_dpp_nucleo-l152re DPP on STM32 NUCLEO-L152RE
|
||||
|
||||
@image html bd_NUCLEO-L152RE.jpg NUCLEO-L152RE board
|
||||
|
||||
@ref dpp "Dining Philosophers Problem (DPP)" example for STM32 NUCLEO-L152RE MCU (Cortex-M3).
|
||||
|
||||
Demonstrated built-in kernels:
|
||||
- cooperative @ref qv with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
- preemptive, run-to-completion @ref qk with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
|
||||
Features:
|
||||
- multiple active objects, including 5 instances of the same AO class (Philo)
|
||||
- [QP/Spy software tracing](https://www.state-machine.com/qtools/qpspy.html) using the virtual COM-port
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_dpp_stm32f4-discovery DPP on STM32F4-Discovery
|
||||
|
||||
The @ref dpp "DPP example" for STM32F4-Discovery board is located directory <span class="img folder">examples/arm-cm/dpp_stm32f4-discovery</span>.
|
||||
|
||||
|
||||
|
||||
Demonstrated built-in kernels:
|
||||
- cooperative @ref qv with ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
- preemptive, run-to-completion @ref qk with ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
- dual-mode (run-to-completion/blocking) @ref qxk with ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
|
||||
|
||||
Features:
|
||||
- multiple active objects, including 5 instances of the same AO class (Philo)
|
||||
- extended threads (the QXK version)
|
||||
- [QP/Spy software tracing](https://www.state-machine.com/qtools/qpspy.html) using the virtual COM-port
|
||||
- bi-directional [QP/Spy](https://www.state-machine.com/qtools/qs.html#qs_rx) (sending commands to the target)
|
||||
|
||||
After you load the DPP example into the STM32F4-Discovery board, the application should start blinking the 4 on-board LEDs. You can press the User button (blue) to PAUSE the philosophers for as long as the button is depressed. The philosophers resume dining when you release the User button. (In the PAUSED state the Table active object stops granting permissions to eat, so eventually all philosophers end in the "hungry" state.)
|
||||
|
||||
|
||||
@section arm-cm_dpp_stm32f4-discovery_qs QS Software Tracing
|
||||
The DPP example for embOS on STM32F4-Discovery board provides the "Spy" build configuration, which outputs the QS (Quantum Spy) software tracing data through USART2. To get the data out of the board, you need to connect the TTL/RS232 converter as follows:
|
||||
|
||||
<center>
|
||||
STM32F4-Discovery | TTL/RS232 Converter
|
||||
-------------------|:------------------------
|
||||
PA2 | TX
|
||||
PA3 | RX (currently not used)
|
||||
VDD | VCC
|
||||
GND | GND
|
||||
</center>
|
||||
|
||||
|
||||
|
||||
The output is generated at 115200 baud rate.
|
||||
|
||||
Here is an example invocation of the QSPY host application to receive the QS data from STM32F4-Discovery:
|
||||
|
||||
@verbatim
|
||||
qspy -cCOM1
|
||||
@endverbatim
|
||||
|
||||
The actual COM port number might be different on your Windows machine. Please check the Device Manager to find the COM port number.
|
||||
|
||||
@next{arm-cm_dpp_nucleo-l552ze}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_dpp_nucleo-h743zi DPP on STM32 NUCLEO-H743ZI
|
||||
|
||||
|
||||
|
||||
@ref dpp "Dining Philosophers Problem (DPP)" example for STM32 NUCLEO-H743ZI MCU (Cortex-M7).
|
||||
|
||||
Demonstrated built-in kernels:
|
||||
- cooperative @ref qv with ARM-Clang, ARM-Keil, GNU-ARM (Makefile and Atollic TRUEstudio), and IAR-ARM toolchains
|
||||
- preemptive, run-to-completion @ref qk with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
- dual-mode (run-to-completion/blocking) @ref qxk with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
|
||||
Features:
|
||||
- multiple active objects, including 5 instances of the same AO class (Philo)
|
||||
- extended threads (the QXK version)
|
||||
- [QP/Spy software tracing](https://www.state-machine.com/qtools/qpspy.html) using the virtual COM-port
|
||||
- bi-directional [QP/Spy](https://www.state-machine.com/qtools/qs.html#qs_rx) (sending commands to the target)
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_dpp_nucleo-l552ze DPP on STM32 STM32 NUCLEO-L552ZE Q
|
||||
|
||||
|
||||
|
||||
@ref dpp "Dining Philosophers Problem (DPP)" example for STM32 NUCLEO-L552ZE Q (Cortex-M33).
|
||||
|
||||
Demonstrated built-in kernels:
|
||||
- cooperative @ref qv with ARM-Clang, ARM-Keil, GNU-ARM (Makefile and Atollic TRUEstudio), and IAR-ARM toolchains
|
||||
- preemptive, run-to-completion @ref qk with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
- dual-mode (run-to-completion/blocking) @ref qxk with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
|
||||
|
||||
Features:
|
||||
- multiple active objects, including 5 instances of the same AO class (Philo)
|
||||
- extended threads (the QXK version)
|
||||
- [QP/Spy software tracing](https://www.state-machine.com/qtools/qpspy.html) using the virtual COM-port
|
||||
- bi-directional [QP/Spy](https://www.state-machine.com/qtools/qs.html#qs_rx) (sending commands to the target)
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cm_game_efm32-slstk3401a "Fly 'n' Shoot" Game on EFM32-SLSTK3401A
|
||||
|
||||
@image html bd_EFM32-SLSTK3401A.jpg EFM32-SLSTK3401A board
|
||||
|
||||
"Fly 'n' Shoot" game example for Silicon Labs Pearl Gecko MCU (Cortex-M4F), ARM (MDK-ARM), GNU-ARM, IAR EWARM toolchains.
|
||||
|
||||
@image html game_win32.jpg Game emulation running in Windows GUI
|
||||
@n
|
||||
@n
|
||||
@image html under_construction.jpg
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cr_blinky_launchxl2-tms57012 Blinky on LAUNCHXL2-TMS57012
|
||||
|
||||
@image html bd_LAUNCHXL2-TMS57012.jpg LAUNCHXL2-TMS57012
|
||||
|
||||
@ref blinky "Blinky" example for LAUNCHXL2-TMS57012 MCU (Cortex-R, Hercules) with IAR-ARM and TI toolchains.
|
||||
|
||||
@image html under_construction.jpg
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page arm-cr_dpp_launchxl2-tms57012 DPP on LAUNCHXL2-TMS57012
|
||||
|
||||
@image html bd_LAUNCHXL2-TMS57012.jpg LAUNCHXL2-TMS57012
|
||||
|
||||
Dining Philosophers Problem (DPP) example for LAUNCHXL2-TMS57012 MCU (Cortex-R, Hercules) with IAR-ARM and TI toolchains.
|
||||
|
||||
@image html under_construction.jpg
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page msp430_blinky_msp-exp430f5529lp Blinky on MSP-EXP430F5529LP
|
||||
|
||||
@image html bd_MSP-EXP430F5529LP.jpg MSP-EXP430F5529LP board
|
||||
|
||||
Simple Blinky example for MSP-EXP430F5529LP with CCS-430 and IAR-430 toolchains. The application blinks the LED1 (P1.0) once per second. The LED2 is rapidly toggled from the idle callback, which results in a "glow" with intensity proportional to the frequency of calling the idle callback.
|
||||
|
||||
@note
|
||||
The simple Blinky application does NOT support the Spy build configuration. Please see the @ref msp430_dpp_msp-exp430f5529lp "DPP example" for QS output.
|
||||
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page msp430_dpp_msp-exp430f5529lp DPP on MSP-EXP430F5529LP
|
||||
|
||||
@image html bd_MSP-EXP430F5529LP.jpg MSP-EXP430F5529LP board
|
||||
|
||||
DPP example for MSP-EXP430F5529LP with CCS-430 and IAR-430 toolchains. The application blinks the LED1 (P1.0) when a Philosopher gets a permission to "eat". The LED2 is rapidly toggled from the idle callback, which results in a "glow" with intensity proportional to the frequency of calling the idle callback.
|
||||
|
||||
@section msp430_dpp_msp-exp430f5529lp_qs QS Output
|
||||
This example demonstrates the QS software tracing output in the Spy build configuration. QS uses the hardware UART1 of the MSP-EXP430F5529LP board connected to the Virtual COM Port on the debugger. This means that you don't need any additional wiring to receive the QS output on your development workstation.
|
||||
|
||||
The QS trace date requires the following setting of the QSPY host utility
|
||||
|
||||
@verbatim
|
||||
qspy -cCOM_PORT -O2 -F2 -E1 -P1 -B1
|
||||
@endverbatim
|
||||
|
||||
where `COM_PORT` denotes the Virtual COM port, which you can find out in the Device Manager.
|
||||
*/
|
||||
|
||||
} // namespace QP
|
||||
@ -1,134 +0,0 @@
|
||||
/*! @page exa_os Examples for Workstations (Windows/POSIX)
|
||||
|
||||
<p>The examples in the <span class="img folder">qpcpp/examples/workstation</span> directory are designed for workstations (running Windows, Linux, or MacOS). Currently, the following examples are provided:
|
||||
</p>
|
||||
|
||||
- <span class="img folder">blinky</span> — Simple "Blinky" active object (command-line)
|
||||
- <span class="img folder">calc</span> — Calculator example from Chapter 2 of [PSiCC2](https://www.state-machine.com/psicc2)
|
||||
- <span class="img folder">calc1</span> — Improved Calculator example from Chapter 2 of [PSiCC2](https://www.state-machine.com/psicc2)
|
||||
- <span class="img folder">calc1_sub</span> — Calculator example with sub-machines
|
||||
- <span class="img folder">comp</span> — Orthogonal Component design pattern
|
||||
- <span class="img folder">defer</span> — Deferred Event design pattern
|
||||
- <span class="img folder">dpp</span> — DPP application from Chapter 9 of [PSiCC2](https://www.state-machine.com/psicc2) (**Spy**)
|
||||
- <span class="img folder">dpp_comp</span> — DPP with Orthogonal-Component pattern (**Spy**)
|
||||
- <span class="img folder">dpp-gui</span> — DPP (with GUI on Windows) (**Spy**)
|
||||
- <span class="img folder">game-gui</span> — "Fly 'n' Shoot" game from Chapter 1 of [PSiCC2](https://www.state-machine.com/psicc2) (**Spy**)
|
||||
- <span class="img folder">history_qhsm</span> — Transition-to-History (with QP::QHsm class)
|
||||
- <span class="img folder">history_qmsm</span> — Transition-to-History (with QP::QMsm class)
|
||||
- <span class="img folder">qhsmtst</span> — Test State Machine based on QP::QHsm from Chapter 2 of [PSiCC2](https://www.state-machine.com/psicc2) (**Spy**)
|
||||
- <span class="img folder">qmsmtst</span> — Test State Machine based on QP::QMsm (**Spy**)
|
||||
- <span class="img folder">reminder</span> — Reminder design pattern from Chapter 5 of PSiCC2
|
||||
- <span class="img folder">reminder2</span> — Reminder design pattern different version
|
||||
|
||||
@remark
|
||||
The examples marked with (**Spy**) provide the @ref exa_os-spy "Spy Configuration".
|
||||
|
||||
|
||||
|
||||
@section exa_win_posix Windows and POSIX Workstations
|
||||
All examples in the <span class="img folder">qpcpp/examples/workstation</span> directory work both on Windows as well as on POSIX (Linux, MacOS). On each of these operating systems you use the same cross-platform `Makefile` co-located with each example. The provided cross-platform `Makefiles` assume the **GNU GCC toolchain**. The `Makefile` discovers the host operating system and chooses the appropriate QP port version:
|
||||
|
||||
- On Windows — @ref win32 "win32" or @ref win32-qv "win32-qv"; and
|
||||
- On POSIX — @ref posix "posix" or @ref posix-qv "posix-qv" (Linux, MacOS, etc.)
|
||||
|
||||
@note
|
||||
On Windows, the **make** utility and the GNU GCC toolchain (**MinGW**) are provided in the [<b>QTools collection</b>](https://www.state-machine.com/qtools), which is available for a separate download. The code can be also built with other tools as well, such as the Microsoft Visual Studio 2013 and newer.
|
||||
|
||||
|
||||
@n
|
||||
|
||||
@n
|
||||
|
||||
|
||||
|
||||
|
||||
@section exa_os-qv Single-Threaded and Multi-Threaded QP/C++ Ports
|
||||
Each of the examples can be linked to either the single-threaded QP/C++ ports (@ref win32-qv or @ref posix-qv) or multi-threaded ports (@ref win32 or @ref posix). The choice is made in the `Makefiles`, by editing the line, which defines the `QP_PORT_DIR` symbol. For instance, the following lines select the @ref win32-qv port and leave the @ref win32 port commented-out:
|
||||
|
||||
@code
|
||||
QP_PORT_DIR := $(QPC)/ports/win32-qv
|
||||
#QP_PORT_DIR := $(QPC)/ports/win32
|
||||
@endcode
|
||||
|
||||
To reverse the selection, you need to move the comment `#` character.
|
||||
|
||||
@remarks
|
||||
The single-threaded QP/C++ ports (@ref win32-qv "win32-qv" and @ref posix-qv "posix-qv") are recommended for **emulating** software intended for deeply-embedded targets ("dual-targeting" the embedded software development).@n
|
||||
|
||||
|
||||
@attention
|
||||
Examples in the <span class="img folder">workstation</span> directory can also be used on the **embedded versions** of the desktop operating systems, such as **Embedded Linux** and **Windows Embedded**. For the embedded applications, the **multi-threaded** @ref ports_os "QP ports" ( @ref posix "posix" and @ref win32 "win32", respectively) are recommended.
|
||||
|
||||
|
||||
|
||||
@section exa_os_conf Debug, Release, and Spy Build Configurations
|
||||
The `Makefiles` for the examples generally support the following three build configurations.
|
||||
|
||||
|
||||
|
||||
@subsection exa_os-dbg Debug Configuration
|
||||
This is the default build configuration, with full debugging information and minimal optimization. To build this configuration, type:
|
||||
|
||||
@code
|
||||
make
|
||||
@endcode
|
||||
|
||||
To clean this build, type
|
||||
|
||||
@code
|
||||
make clean
|
||||
@endcode
|
||||
|
||||
The object files and the executable is located in the <span class="img folder">build</span> sub-directory.
|
||||
|
||||
|
||||
|
||||
@subsection exa_os-rel Release Configuration
|
||||
This configuration is built with no debugging information and high optimization. Single-stepping and debugging might be difficult due
|
||||
to the lack of debugging information and optimized code. To build this configuration, type:
|
||||
|
||||
@code
|
||||
make CONF=rel
|
||||
@endcode
|
||||
|
||||
To clean this build, type
|
||||
|
||||
@code
|
||||
make CONF=rel clean
|
||||
@endcode
|
||||
|
||||
The object files and the executable is located in the <span class="img folder">build_rel</span> directory.
|
||||
|
||||
|
||||
|
||||
@subsection exa_os-spy Spy Configuration
|
||||
This configuration is built with the QP's Q-SPY trace functionality. The QP/Spy output is performed by a TCP/IP socket and requires launching the QSPY host application with the -t option. To build this configuration, type:
|
||||
|
||||
@code
|
||||
make CONF=spy
|
||||
@endcode
|
||||
|
||||
To clean this build, type
|
||||
|
||||
@code
|
||||
make CONF=spy clean
|
||||
@endcode
|
||||
|
||||
The object files and the executable are located in the <span class="img folder">build_spy</span> sub-directory.
|
||||
|
||||
@note
|
||||
The Spy build configuration requires launching the [QSPY host utility](https://www.state-machine.com/qtools/qspy.html) with the `-t` command-line option **before** running the example. This is so that the example code can output the QS software tracing to the TCP/IP socket of QSPY.
|
||||
|
||||
|
||||
@remark
|
||||
Only specific examples support the Spy build configuration. The examples that don't support it, will report an error or will fail the linking stage.
|
||||
|
||||
|
||||
@n
|
||||
|
||||
@n
|
||||
|
||||
|
||||
|
||||
@next{exa_mware}
|
||||
*/
|
||||
@ -1,137 +0,0 @@
|
||||
/*! @page exa_qutest Examples for QUTest Unit Testing Harness
|
||||
|
||||
<p>The examples in the <span class="img folder">qpcpp/examples/qutest</span> directory demonstrate how to test embedded code with the [<b>QUTest</b>](https://www.state-machine.com/qtools/qutest.html) unit testing harness. Currently, the following examples are provided:
|
||||
</p>
|
||||
|
||||
- <span class="img folder">blinky</span> — Simple "Blinky" single-active-object application
|
||||
- <span class="img folder">dpp</span> — DPP application from Chapter 9 of PSiCC2
|
||||
- <span class="img folder">evt-par</span> — testing events with parameters
|
||||
- <span class="img folder">qhsmtst</span> — Test State Machine based on QP::QHsm with QM model
|
||||
- <span class="img folder">qmsmtst</span> — Test State Machine based on QP::QMsm with QM model
|
||||
- <span class="img folder">unity_basic</span> — Comparison of a basic testing with Unity and QUTest
|
||||
- <span class="img folder">unity_mock</span> — Comparison of a advanced testing (mocking) with Unity and QUTest
|
||||
|
||||
|
||||
|
||||
@section exa_qutest-dir General Code Organization
|
||||
The projects within the <span class="img folder">examples/qutest</span> directory have the customary structure used for testing. The production code to be tested is located in the <span class="img folder">src</span> sub-directory. The testing code is located in the <span class="img folder">test_...</span> sub-folder(s). The following directory tree illustrates the structure for the `dpp` example:
|
||||
|
||||
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">examples/</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">qutest/</span> — Examples for QUTest unit testing harness
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">dpp/</span> — The simple Blinky example
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">src/</span> — source code under test <span class="tag">A</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img file_h">bsp.h</span> — BSP header
|
||||
</li>
|
||||
<li><span class="img file_h">dpp.h</span> — DPP header
|
||||
</li>
|
||||
<li><span class="img file_qm">dpp.qm</span> — DPP model
|
||||
</li>
|
||||
<li><span class="img file_c">philo.cpp</span> — `Philo` active object
|
||||
</li>
|
||||
<li><span class="img file_c">table.cpp</span> — `Table` active object
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">test_philo/</span> — code for unit testing of `Philo` AO <span class="tag">B</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img file_mak">Makefile</span> — cross-platform makefile (host)
|
||||
</li>
|
||||
<li><span class="img file_c">test_philo.cpp</span> — test fixture for `Philo` AO
|
||||
</li>
|
||||
<li><span class="img file_py">test_philo.py</span> — test script for `Philo` (Python)
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">test_table/</span> — code for unit testing of `Table` AO <span class="tag">B</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img file_mak">Makefile</span> — cross-platform makefile (host)
|
||||
</li>
|
||||
<li><span class="img file_c">test_philo.cpp</span> — test fixture for `Table` AO
|
||||
</li>
|
||||
<li><span class="img file_py">test_philo.py</span> — test script for `Table` (Python)
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">test_dpp/</span> — code for unit testing of DPP application <span class="tag">C</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img file_mak">Makefile</span> — cross-platform makefile (host)
|
||||
</li>
|
||||
<li><span class="img file_mak">make_efm32</span> — makefile for the EFM32 **embedded board**
|
||||
</li>
|
||||
<li><span class="img file_mak">make_tm4c123</span> — makefile for the TM4C123 **embedded board**
|
||||
</li>
|
||||
<li><span class="img file_c">main.cpp</span> — `main()` function for DPP application
|
||||
</li>
|
||||
<li><span class="img file_c">test_dpp.cpp</span> — test fixture for DPP application
|
||||
</li>
|
||||
<li><span class="img file_py">test_init.py</span> — test script for DPP initialization (Python)
|
||||
</li>
|
||||
<li><span class="img file_py">test_tick.py</span> — test script for DPP tick processing (Python)
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<li><span class="img folder">.../</span> — Other QUTest examples...
|
||||
</li>
|
||||
<li><span class="img folder">target_efm32/</span> — Code for the **embedded target** (EFM32) <span class="tag">D</span>
|
||||
</li>
|
||||
<li><span class="img folder">target_tm4c123/</span> — Code for the **embedded target** (TM4C123) <span class="tag">D</span>
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
<ul class="tag">
|
||||
<li><span class="tag">A</span> The <span class="img folder">src</span> sub-directory contains the production code to be tested. This directory contains the <span class="img file_qm">.qm</span> model file as well as the generated code from the model.
|
||||
</li>
|
||||
|
||||
<li><span class="tag">B</span> The <span class="img folder">test_philo</span> sub-directory contains the unit test code for a component, such as `Philo` in this case. Here, you can find the <span class="img file_cpp">test_*.cpp</span> **test fixture**, the test scripts <span class="img file_py">test_*.py</span> (Python) as well as the cross-platform <span class="img file_mak">Makefile</span> to build the code and *run* the tests on the host.
|
||||
</li>
|
||||
|
||||
<li><span class="tag">C</span> The <span class="img folder">test_dpp</span> sub-directory contains integration-test code for the application, such as `DPP` in this case. The objective is to test the initialization and interactions *among* components. Here, you can find the <span class="img file_c">main.c</span> `main()` function as well as the <span class="img file_c">test_dpp.cpp</span> *test fixture*. This directory also contains <span class="img file_mak">make_*</span> *makefiles* to build and run the code on the **embedded targets**.
|
||||
</li>
|
||||
|
||||
<li><span class="tag">D</span> The <span class="img folder">target_efm32</span> sub-directory contains the Code needed to build and run the test code on the **embedded target**, like EFM32 in this case.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
@section exa_qutest-test Building and Running the Tests
|
||||
As usual in Test-Driven Development (TDD), the provided <span class="img file_mak">Makefiles</span> both *build* the code and *run* the tests.
|
||||
|
||||
|
||||
@subsection exa_qutest_host Host Computers
|
||||
Typically, you start testing on your host computer. Before building/running the code, you need to open a terminal window and launch the [QSPY host application](https://www.state-machine.com/qtools/qspy.html) with the `-t` [command-line option](https://www.state-machine.com/qtools/qspy.html#qspy_command).
|
||||
|
||||
Next, you open another terminal window, change directory to the <span class="img folder">test_...</span> folder of interest, and type `make`. This will build the application and run the tests (Python), as shown in the screen shot below:
|
||||
|
||||
|
||||
|
||||
|
||||
@subsection exa_qutest_target Embedded Targets
|
||||
The QUTest testing system allows you also to easily test the code directly on the embedded target board. The <span class="img folder">dpp/test_dpp/</span> directory illustrates this option by providing the `makefiles` for embedded boards, such as the TM4C123 (Tiva LaunchPad) <span class="img file_mak">make_tm4c123</span>.
|
||||
|
||||
To test the code on an embedded board, you need to connect the board to the host computer and launch the and launch the [QSPY host application](https://www.state-machine.com/qtools/qspy.html) with the `-c COM<n>` [command-line option](https://www.state-machine.com/qtools/qspy.html#qspy_command), where `<n>` is the specific COM port number on your host that the board is using.
|
||||
|
||||
Next, you open another terminal window, change directory to the <span class="img folder">test_...</span> folder of interest, and type `make -f make_tm4c123`. This will build the application and run the tests (Python), as shown in the screen shot below:
|
||||
|
||||
|
||||
|
||||
|
||||
@next{exa_os}
|
||||
*/
|
||||
@ -1,687 +0,0 @@
|
||||
namespace QP {
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_rtos Examples for Third-Party RTOS
|
||||
|
||||
The main purpose of integrating QP/C++ with conventional RTOSes is to enable you to incorporate various communication stacks (TCP/IP, USB, CAN, etc.) as well as other middleware, which requires the ability to **block** the task code. Currently the following 3rd-party RTOSes are supported:
|
||||
|
||||
- @subpage exa_embos (directory <span class="img folder">examples/embos/</span>)
|
||||
- @subpage exa_freertos (directory <span class="img folder">examples/freertos/</span>)
|
||||
- @subpage exa_threadx (directory <span class="img folder">examples/threadx/</span>)
|
||||
- @subpage exa_uc-os2 (directory <span class="img folder">examples/uc-os2/</span>)
|
||||
- @subpage exa_zephyr (directory <span class="img folder">examples/zephyr/</span>)
|
||||
|
||||
@note
|
||||
You do **not** need to use a third-party RTOS just to achieve preemptive multitasking with QP/C++. The framework contains a selection of built-in real-time kernels, such as the cooperative @ref srs_qv "QV kernel", the preemptive non-blocking @ref srs_qk "QK kernel", and the preemptive, dual-mode, blocking @ref srs_qxk "QXK kernel". Specifically, the QXK kernel has been designed specifically for mixing event-driven active objects with traditional **blocking code**, such as commercial middleware (TCP/IP stacks, UDP stacks, embedded file systems, etc.) or legacy software.
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{exa_embos}
|
||||
@endif
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_embos embOS
|
||||
|
||||
The QP/C++ examples for SEGGER embOS are as follows:
|
||||
|
||||
- ARM Cortex-M
|
||||
- @subpage embos_dpp_nucleo-h743zi (Cortex-M7) <a class="preview board" href="bd_NUCLEO-H743ZI.jpg" title="NUCLEO-H743ZI"></a><br>(GNU-ARM and IAR EWARM toolsets)
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{embos_dpp_nucleo-h743zi}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page embos_dpp_nucleo-h743zi DPP on NUCLEO-H743ZI
|
||||
|
||||
The @ref dpp "DPP example" for embOS on NUCLEO-H743ZI board is located directory <span class="img folder">examples/embos/arm-cm/dpp_nucleo-h743zi</span>.
|
||||
|
||||
@image html bd_NUCLEO-H743ZI.jpg
|
||||
@image latex bd_NUCLEO-H743ZI.jpg width=4.5in
|
||||
@caption{NUCLEO-H743ZI}
|
||||
|
||||
@ref dpp "Dining Philosophers Problem (DPP)" example for NUCLEO-H743ZI MCU (Cortex-M7).
|
||||
|
||||
|
||||
Toolsets:
|
||||
- GNU-ARM in directory <span class="img folder">examples/embos/arm-cm/dpp_nucleo-h743zi/gnu</span>. Makefile provided.
|
||||
|
||||
@verbatim
|
||||
make
|
||||
make CONF=rel
|
||||
make CONF=spy
|
||||
@endverbatim
|
||||
|
||||
- IAR EWARM in directory <span class="img folder">examples/embos/arm-cm/dpp_nucleo-h743zi/iar</span>. Workspace `dpp.eww` provided.
|
||||
|
||||
Features:
|
||||
- embOS RTOS kernel
|
||||
- BSP with embOS-specific: OS_TICK_HOOK, OS_Idle(), "kernel unaware" ISRs
|
||||
- multiple active objects, including 5 instances of the same AO class (Philo)
|
||||
- [QP/Spy software tracing](https://www.state-machine.com/qtools/qpspy.html) using the virtual COM-port
|
||||
- bi-directional [QP/Spy](https://www.state-machine.com/qtools/qs.html#qs_rx) (sending commands to the target)
|
||||
|
||||
The output is generated at 115200 baud rate.
|
||||
|
||||
Here is an example invocation of the QSPY host application to receive the QS data from NUCLEO-H743ZI:
|
||||
|
||||
@verbatim
|
||||
qspy -c COM4
|
||||
@endverbatim
|
||||
|
||||
The actual COM port number might be different on your Windows machine. Please check the Device Manager to find the COM port number.
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{exa_freertos}
|
||||
@endif
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_freertos FreeRTOS
|
||||
|
||||
The QP/C++ examples for FreeRTOS are as follows:
|
||||
|
||||
- ARM Cortex-M
|
||||
- @subpage freertos_dpp_ek-tm4c123gxl (Cortex-M4F) <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a><br>(ARM-KEIL, GNU-ARM and IAR EWARM toolchains)
|
||||
- @subpage freertos_dpp_stm32f746g-disco (Cortex-M7) <a class="preview board" href="bd_STM32F746G-Disco.jpg" title="STM32F746G-Discovery"></a><br>(ARM-KEIL, GNU-ARM and IAR EWARM toolchains)
|
||||
- @subpage freertos_dpp_nucleo-h743zi (Cortex-M7) <a class="preview board" href="bd_NUCLEO-H743ZI.jpg" title="NUCLEO-H743ZI"></a><br>(ARM-KEIL, GNU-ARM and IAR EWARM toolchains)
|
||||
- @subpage freertos_start-stop_nucleo-h743zi (Cortex-M7) <a class="preview board" href="bd_NUCLEO-H743ZI.jpg" title="NUCLEO-H743ZI"></a><br>(ARM-KEIL, GNU-ARM and IAR EWARM toolchains)
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{exa_os}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page freertos_dpp_ek-tm4c123gxl DPP on EK-TM4C123GXL
|
||||
|
||||
@image html bd_EK-TM4C123GXL.jpg
|
||||
@image latex bd_EK-TM4C123GXL.jpg width=2.5in
|
||||
@caption{EK-TM4C123GXL (TivaC LaunchPad)}
|
||||
|
||||
@ref dpp "DPP example" for @ref freertos "FreeRTOS" on Texas Instruments TivaC123GXL MCU (Cortex-M4F) with the following toolchains:
|
||||
- ARM-Keil
|
||||
- GNU-ARM
|
||||
- IAR-ARM
|
||||
|
||||
Demonstrated features:
|
||||
- Multiple Active Objects
|
||||
- Regular "kernel-aware" ISR with "FromISR" APIs
|
||||
+ `QF::TICK_X_FROM_ISR()`
|
||||
+ `QF::PUBLISH_FROM_ISR()`
|
||||
+ `Q_NEW_FROM_ISR()`
|
||||
+ `QActive::POST_FROM_ISR()`
|
||||
- Hi-priority "kernel-unaware" ISR
|
||||
- `vApplicationTickHook()`
|
||||
- QP/Spy output over the virtual COM port (Spy build configuration)
|
||||
- QP/Spy input over the virtual COM port (bi-directional Spy) (Spy build configuration)
|
||||
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{freertos_dpp_stm32f746g-disco}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page freertos_dpp_stm32f746g-disco DPP on STM32F746G-Discovery
|
||||
|
||||
@image html bd_STM32F746G-Disco.jpg
|
||||
@image latex bd_STM32F746G-Disco.jpg width=4.75in
|
||||
@caption{STM32F746G-Discovery}
|
||||
|
||||
@ref dpp "DPP example" for @ref freertos "FreeRTOS" on STM32F746G-Discovery MCU (Cortex-M7) with the following toolchains:
|
||||
- ARM-Keil
|
||||
- GNU-ARM
|
||||
- IAR-ARM
|
||||
|
||||
Demonstrated features:
|
||||
- Multiple Active Objects
|
||||
- Regular "kernel-aware" ISR with "FromISR" APIs
|
||||
+ `QF::TICK_X_FROM_ISR()`
|
||||
+ `QF::PUBLISH_FROM_ISR()`
|
||||
+ `Q_NEW_FROM_ISR()`
|
||||
+ `QActive::POST_FROM_ISR()`
|
||||
- Hi-priority "kernel-unaware" ISR
|
||||
- `vApplicationTickHook()`
|
||||
- QP/Spy output over the virtual COM port (Spy build configuration)
|
||||
- QP/Spy input over the virtual COM port (bi-directional Spy) (Spy build configuration)
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{freertos_dpp_nucleo-h743zi}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page freertos_dpp_nucleo-h743zi DPP on NUCLEO-H743ZI
|
||||
|
||||
@image html bd_NUCLEO-H743ZI.jpg
|
||||
@image latex bd_NUCLEO-H743ZI.jpg width=4.5in
|
||||
@caption{NUCLEO-H743ZI}
|
||||
|
||||
@ref dpp "Dining Philosophers Problem (DPP)" example for NUCLEO-H743ZI MCU (Cortex-M7).
|
||||
|
||||
Features:
|
||||
- multiple active objects, including 5 instances of the same AO class (Philo)
|
||||
- [QP/Spy software tracing](https://www.state-machine.com/qtools/qpspy.html) using the virtual COM-port
|
||||
- bi-directional [QP/Spy](https://www.state-machine.com/qtools/qs.html#qs_rx) (sending commands to the target)
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{freertos_start-stop_nucleo-h743zi}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page freertos_start-stop_nucleo-h743zi Start-Stop on NUCLEO-H743ZI
|
||||
|
||||
@image html bd_NUCLEO-H743ZI.jpg
|
||||
@image latex bd_NUCLEO-H743ZI.jpg width=4.5in
|
||||
@caption{NUCLEO-H743ZI}
|
||||
|
||||
Start-Stop example for NUCLEO-H743ZI MCU (Cortex-M7) demonstrates staring and stopping active objects multiple times
|
||||
during the runtime, as opposed to starting AOs only at the beginning.
|
||||
|
||||
The code for the example is generated automatically by the [QM Model-Based Design tool](https://www.state-machine.com/products/qm/) (QM version 4.5.0 or higher).
|
||||
|
||||
The start-stop application consists of two AOs:
|
||||
|
||||
- the Launcher AO is started at the beginning and its job is to periodically (re)start another AO
|
||||
|
||||
- the Worker AO is NOT started at the beginning, but instead it is instantiated and started by the Launcher AO.
|
||||
|
||||
|
||||
@image html start-stop.png
|
||||
@image latex start-stop.png width=5.0in
|
||||
@caption{Launcher and Worker state machines}
|
||||
|
||||
|
||||
The actual visible work is performed by the Worker AO, which blinks the yellow LED (LD1) on the NUCLEO-H743ZI board. After blinking the LED five times, the Worker AO publishes turns the blue LED (LD2), publishes the DONE event and stops itself (by calling QP::QActive::stop() on itself).
|
||||
|
||||
The Launcher AO subscribes to the DONE event. Upon reception of this event, The Launcher AO gives the Worker a bit of time (at least one clock tick) to cleanly terminate and then it explicitly destroys the Worker. The Worker destructor turns the blue LED (LD2) off.
|
||||
|
||||
Next the Launcher instantiates the Worker AO by means of the placement new operator and then it starts it again to repeat the cycle, which goes no forever.
|
||||
|
||||
|
||||
@remarks
|
||||
Because this application is intended for embedded real-time systems, it does not use the dynamic memory (heap). Instead it uses statically allocated memory (static mode of FreeRTOS) as well as **placement-new** and explicit destructor call.
|
||||
|
||||
|
||||
It is possible to use the standard **new** and **delete** operators with the standard heap, or some customized memory allocation (overloaded new/delete). This goes beyond the scope of this example.
|
||||
|
||||
|
||||
**Supported Toolchains**<br>
|
||||
This example contains sub-directories for building it with various toolchains. The following toolchains are supported:
|
||||
|
||||
- ARM-Keil MDK
|
||||
- GNU-ARM
|
||||
- IAR EWARM
|
||||
|
||||
Please refer to the README.txt files in these sub-directories for more information about building and running the examples.
|
||||
|
||||
|
||||
**QP/Spy Support**<br>
|
||||
This example demonstrates the [QP/Spy software tracing](https://www.state-machine.com/qtools/qpspy.html) in the **Spy build configuration**. The QP/Spy uses the virtual COM port provided by the NUCLEO-H743ZI board. To see the QP/Spy output, you need to launch the qspy host utility, as follows (Windows command prompt):
|
||||
|
||||
@verbatim
|
||||
qspy -u -c COM4
|
||||
@endverbatim
|
||||
|
||||
where COM4 is the particular virtual serial port registered by your NUCLEO board. You need to adjust the COM port number for your machine.
|
||||
|
||||
|
||||
**Programming the NUCLEO Board**<br>
|
||||
The NUCLEO boards appear as a USB-flash drive in the file system. Programming of the board is done by simply copying the binary into
|
||||
thy flash drive letter.
|
||||
|
||||
For example, assuming that the NUCLEO board appears as drive E:, you program it with the following command:
|
||||
|
||||
@verbatim
|
||||
copy dbg\start-stop.bin E:
|
||||
@endverbatim
|
||||
|
||||
|
||||
**Demonstrated Features** @n
|
||||
- multiple active objects (Launcher and Worker)
|
||||
- instantiating, starting and stopping active objects multiple times
|
||||
- [QP/Spy software tracing](https://www.state-machine.com/qtools/qpspy.html) using the virtual COM-port
|
||||
- bi-directional [QP/Spy](https://www.state-machine.com/qtools/qs.html#qs_rx) (sending commands to the target)
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{exa_threadx}
|
||||
@endif
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_threadx ThreadX
|
||||
|
||||
The QP/C++ examples for ThreadX (Express Logic) are as follows:
|
||||
|
||||
- @subpage threadx_dpp_ek-tm4c123gxl (Cortex-M4F) <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a><br>(IAR EWARM toolchain)
|
||||
- @subpage threadx_dpp_stm32f429-discovery <a class="preview board" href="bd_STM32F4-Discovery.jpg" title="STM32F4-Discovery"></a><br>(IAR EWARM toolchain)
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{exa_uc-os2}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page threadx_dpp_ek-tm4c123gxl DPP on EK-TM4C123GXL
|
||||
|
||||
@image html bd_EK-TM4C123GXL.jpg
|
||||
@image latex bd_EK-TM4C123GXL.jpg width=2.5in
|
||||
@caption{EK-TM4C123GXL (TivaC LaunchPad)}
|
||||
|
||||
@ref dpp "DPP example" for ThreadX on Texas Instruments TivaC123GXL MCU (Cortex-M4F) with the following toolchain:
|
||||
- IAR-ARM
|
||||
|
||||
Demonstrated features:
|
||||
- Multiple Active Objects
|
||||
- QP/Spy output over the virtual COM port (Spy build configuration)
|
||||
- QP/Spy input over the virtual COM port (bi-directional Spy) (Spy build configuration)
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{threadx_dpp_stm32f429-discovery}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page threadx_dpp_stm32f429-discovery DPP on STM32F4-Discovery
|
||||
|
||||
The @ref dpp "DPP example" for ThreadX on STM32F4-Discovery board is located directory <span class="img folder">examples/threadx/arm-cm/dpp_stm32f429-discovery</span>.
|
||||
|
||||
@image html bd_STM32F4-Disco.jpg
|
||||
@image latex bd_STM32F4-Disco.jpg width=2.8in
|
||||
@caption{STM32F4-Discovery}
|
||||
|
||||
The sub-directory <span class="img folder">iar</span> contains the workspace and project file that you can open in IAR EWARM IDE.
|
||||
|
||||
After you load the DPP example into the STM32F4-Discovery board, the application should start blinking the 4 on-board LEDs. You can press the User button (blue) to PAUSE the philosophers for as long as the button is depressed. The philosophers resume dining when you release the User button. (In the PAUSED state the Table active object stops granting permissions to eat, so eventually all philosophers end in the "hungry" state.)
|
||||
|
||||
|
||||
@section threadx_dpp_stm32f429-discovery_qs QS Software Tracing
|
||||
|
||||
The DPP example for ThreadX on STM32F4-Discovery board provides the "Spy" build configuration, which outputs the QS (Quantum Spy) software tracing data through USART2. To get the data out of the board, you need to connect the TTL/RS232 converter as follows:
|
||||
|
||||
<center>
|
||||
STM32F4-Discovery | TTL/RS232 Converter
|
||||
-------------------|:------------------------
|
||||
PA2 | TX
|
||||
PA3 | RX (currently not used)
|
||||
VDD | VCC
|
||||
GND | GND
|
||||
</center>
|
||||
|
||||
@image html bd_STM32F4-Disco.jpg
|
||||
@image latex bd_STM32F4-Disco.jpg width=2.8in
|
||||
@caption{STM32F4-Discovery}
|
||||
|
||||
The output is generated at 115200 baud rate.
|
||||
|
||||
Here is an example invocation of the QSPY host application to receive the QS data from STM32F4-Discovery:
|
||||
|
||||
@verbatim
|
||||
qspy -cCOM1
|
||||
@endverbatim
|
||||
|
||||
The actual COM port number might be different on your Windows machine. Please check the Device Manager to find the COM port number.
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{exa_uc-os2}
|
||||
@endif
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_uc-os2 uC-OS2
|
||||
|
||||
The QP/C++ examples for uC-OS2 are as follows:
|
||||
|
||||
- ARM Cortex-M
|
||||
- @subpage uc-os2_dpp_ek-tm4c123gxl (Cortex-M4F) <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a><br>(ARM-CLANG, GNU-ARM and IAR EWARM toolsets)
|
||||
- @subpage uc-os2_dpp_nucleo-l053r8 (Cortex-M0+) <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="NUCLEO-L053R8"></a><br>(ARM-CLANG, GNU-ARM, and IAR EWARM toolsets)
|
||||
|
||||
@note
|
||||
You can hover the mouse cursor over the <span class="board"></span> icon in the list below to see the picture of the board.
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{exa_os}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page uc-os2_dpp_ek-tm4c123gxl DPP on EK-TM4C123GXL
|
||||
|
||||
@image html bd_EK-TM4C123GXL.jpg
|
||||
@image latex bd_EK-TM4C123GXL.jpg width=2.5in
|
||||
@caption{EK-TM4C123GXL (TivaC LaunchPad)}
|
||||
|
||||
DPP example for Texas Instruments TivaC123GXL MCU (Cortex-M4F) and ARM-CLANG, GNU-ARM and IAR EWARM toolsets.
|
||||
|
||||
@image html under-constr.png
|
||||
@image latex under-constr.png width=1in
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{uc-os2_dpp_nucleo-l053r8}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page uc-os2_dpp_nucleo-l053r8 DPP on STM32-NUCLEO-L053R8
|
||||
|
||||
@image html bd_NUCLEO-L053R8.jpg
|
||||
@image latex bd_NUCLEO-L053R8.jpg width=2.5in
|
||||
@caption{NUCLEO-L053R8}
|
||||
|
||||
DPP example for STM32 L053R8 MCU (Cortex-M0+) and ARM-CLANG, GNU-ARM and IAR EWARM toolsets.
|
||||
|
||||
@image html under-constr.png
|
||||
@image latex under-constr.png width=1in
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{exa_zephyr}
|
||||
@endif
|
||||
*/
|
||||
|
||||
/*##########################################################################*/
|
||||
/*! @page exa_zephyr Zephyr
|
||||
|
||||
The QP/C++ examples for Zephyr are as follows:
|
||||
|
||||
- @subpage zephyr_blinky
|
||||
- @subpage zephyr_dpp
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{zephyr_blinky}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page zephyr_blinky Blinky
|
||||
|
||||
The "Blinky" example blinks an on-board LED once per second. The blinking is done by an Active Object (Blinky) with a state machine. The example directory contains the following files:
|
||||
|
||||
@verbatim
|
||||
<qpcpp>/examples/zephyr/blinky
|
||||
|
|
||||
+-src/ - project sources
|
||||
| |
|
||||
| +-bsp.hpp
|
||||
| +-bsp.cpp
|
||||
| +-blinky.hpp
|
||||
| +-blinky.cpp
|
||||
| +-main.cpp
|
||||
|
|
||||
+-CMakeLists.txt - project files
|
||||
+-prj.conf - project config
|
||||
+-README.md
|
||||
@endverbatim
|
||||
|
||||
|
||||
@section zephyr_blinky-build Building and Running
|
||||
|
||||
- Linux:
|
||||
|
||||
@verbatim
|
||||
[1] cd <qpcpp>/examples/zephyr/blinky
|
||||
|
||||
[2] source ~/zephyrproject/zephyr/zephyr-env.sh
|
||||
|
||||
[3] west build -b <board>
|
||||
[3a] west build -b nucleo_h743zi
|
||||
[3b] west build -b nucleo_l053r8
|
||||
...
|
||||
|
||||
[4] west flush
|
||||
@endverbatim
|
||||
|
||||
`[1]` Open a terminal in the Blinky example directory.<br>
|
||||
`[2]` If Zephyr project is not in your path, you might need to source the `zephyr-env.sh` shell script.<br>
|
||||
`[3]` build the example project, where `<board>` is any of the boards supported by Zepyr. The example has been tested with the following boards:<br>
|
||||
`[3a]` nucleo_h743zi (ARM Cortex-M7)<br>
|
||||
`[3b]` nucleo_l053r8 (ARM Cortex-M0+)<br>
|
||||
`[4]` flash the board
|
||||
|
||||
@remark
|
||||
The example has been tested with the following boards:
|
||||
|
||||
@image html bd_NUCLEO-L053R8.jpg
|
||||
@image latex bd_NUCLEO-L053R8.jpg width=2.5in
|
||||
@caption{NUCLEO-L053R8}
|
||||
|
||||
<br>
|
||||
|
||||
@image html bd_NUCLEO-H743ZI.jpg
|
||||
@image latex bd_NUCLEO-H743ZI.jpg width=4.5in
|
||||
@caption{NUCLEO-H743ZI}
|
||||
|
||||
@note
|
||||
The example should also work with most boards supported by Zephyr.
|
||||
|
||||
|
||||
@section zephyr_blinky-output Sample Output
|
||||
Once flashed to the board, the application also produces ASCII output to the serial terminal (if supported by the board):
|
||||
|
||||
@verbatim
|
||||
*** Booting Zephyr OS build v2.6.0-rc2-88-g3d39f72a88b3 ***
|
||||
BSP::ledOff
|
||||
QF::onStartup
|
||||
BSP::ledOn
|
||||
BSP::ledOff
|
||||
BSP::ledOn
|
||||
BSP::ledOff
|
||||
@endverbatim
|
||||
|
||||
@section zephyr_blinky-limits Limitations
|
||||
The simple Blinky example does not support the QS software tracing.
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{zephyr_dpp}
|
||||
@endif
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page zephyr_dpp DPP
|
||||
|
||||
DPP example with multiple active objects.
|
||||
|
||||
@verbatim
|
||||
<qpcpp>/examples/zephyr/dpp
|
||||
|
|
||||
+-src/ - project sources
|
||||
| |
|
||||
| +-bsp.hpp
|
||||
| +-bsp.cpp
|
||||
| +-dpp.hpp
|
||||
| +-philo.cpp
|
||||
| +-table.cpp
|
||||
| +-main.cpp
|
||||
|
|
||||
+-CMakeLists.txt - project files
|
||||
+-prj.conf - project config
|
||||
+-README.md
|
||||
@endverbatim
|
||||
|
||||
@section zephyr_dpp-build Building and Running
|
||||
|
||||
- Linux:
|
||||
|
||||
@verbatim
|
||||
[1] cd <qpcpp>/examples/zephyr/dpp
|
||||
|
||||
[2] source ~/zephyrproject/zephyr/zephyr-env.sh
|
||||
|
||||
[3] west build -b <board>
|
||||
[3a] west build -b nucleo_h743zi
|
||||
[3b] west build -b nucleo_l053r8
|
||||
...
|
||||
|
||||
[4] west flush
|
||||
@endverbatim
|
||||
|
||||
`[1]` Open a terminal in the DPP example directory.<br>
|
||||
`[2]` If Zephyr project is not in your path, you might need to source the `zephyr-env.sh` shell script.<br>
|
||||
`[3]` build the example project, where `<board>` is any of the boards supported by Zepyr. The example has been tested with the following boards:<br>
|
||||
`[3a]` nucleo_h743zi (ARM Cortex-M7)<br>
|
||||
`[3b]` nucleo_l053r8 (ARM Cortex-M0+)<br>
|
||||
`[4]` flash the board
|
||||
|
||||
@remark
|
||||
The example has been tested with the following boards:
|
||||
|
||||
@image html bd_NUCLEO-L053R8.jpg
|
||||
@image latex bd_NUCLEO-L053R8.jpg width=2.5in
|
||||
@caption{NUCLEO-L053R8}
|
||||
|
||||
<br>
|
||||
|
||||
@image html bd_NUCLEO-H743ZI.jpg
|
||||
@image latex bd_NUCLEO-H743ZI.jpg width=4.5in
|
||||
@caption{NUCLEO-H743ZI}
|
||||
|
||||
@note
|
||||
The example should also work with most boards supported by Zephyr.
|
||||
|
||||
|
||||
@section zephyr_dpp-output Sample Output
|
||||
Once flashed to the board, the application also produces ASCII output to the serial terminal (if supported by the board):
|
||||
|
||||
@verbatim
|
||||
*** Booting Zephyr OS build v2.6.0-rc2-88-g3d39f72a88b3 ***
|
||||
Philo[4]->thinking
|
||||
Philo[3]->eating
|
||||
Philo[1]->thinking
|
||||
Philo[0]->eating
|
||||
Philo[4]->hungry
|
||||
Philo[3]->thinking
|
||||
Philo[2]->eating
|
||||
Philo[1]->hungry
|
||||
Philo[0]->thinking
|
||||
Philo[4]->eating
|
||||
Philo[3]->hungry
|
||||
Philo[0]->hungry
|
||||
Philo[4]->thinking
|
||||
Philo[0]->eating
|
||||
Philo[2]->thinking
|
||||
Philo[3]->eating
|
||||
Philo[4]->hungry
|
||||
Philo[2]->hungry
|
||||
Philo[3]->thinking
|
||||
Philo[2]->eating
|
||||
Philo[0]->thinking
|
||||
@endverbatim
|
||||
|
||||
|
||||
@section zephyr_dpp-qpspy Using the QP/SPY Software Tracing
|
||||
The @ref zephyr "QP/C Zephyr port" supports the
|
||||
[QSPY Software Tracing](https://www.state-machine.com/qtools/qpspy.html)
|
||||
option and will add the appropriate macros and files to build the "QSPY"
|
||||
configuration.
|
||||
|
||||
If you wish to enable "QSPY" you can provide the option "QSPY"
|
||||
in the command-line for the build. For example:
|
||||
|
||||
@verbatim
|
||||
west build -b nucleo_h743zi -- -DQSPY=ON
|
||||
@endverbatim
|
||||
|
||||
@note
|
||||
The QP/Spy software tracing uses the Zephyr's console UART. This means that the Zephyr `printk()` facility cannot be used while QP/Spy is configured.
|
||||
|
||||
|
||||
If yo have built the example with QP/Spy, you might want to watch the QP/Spy output.
|
||||
|
||||
|
||||
@section zephyr_dpp-qspy The QSPY Host Utility
|
||||
To receive the QP/Spy software tracing output you need to run a special [qspy host application](https://www.state-machine.com/qtools/qspy.html).
|
||||
|
||||
@note
|
||||
You might need to build the `qspy` host utility on your Linux machine. The QSPY utility is available in
|
||||
[QTools collection](https://github.com/QuantumLeaps/qtools/tree/master/qspy).
|
||||
|
||||
|
||||
To launch the `qspy` host utility, open a separate terminal and run
|
||||
@verbatim
|
||||
qspy -c <serial-port>
|
||||
```
|
||||
specific example:
|
||||
```
|
||||
qspy -c /dev/ttyACM0
|
||||
@endverbatim
|
||||
|
||||
|
||||
@subsection zephyr_dpp-qs-output QSPY Output Example
|
||||
After resetting the board, you should see output similar to the following:
|
||||
@verbatim
|
||||
########## Trg-RST QP-Ver=701,Build=220810_150847
|
||||
Obj-Dict 0x20003154->QS_RX
|
||||
Obj-Dict 0x20000680->AO_Table
|
||||
Obj-Dict 0x20000180->AO_Philo[0]
|
||||
Obj-Dict 0x20000280->AO_Philo[1]
|
||||
Obj-Dict 0x20000380->AO_Philo[2]
|
||||
Obj-Dict 0x20000480->AO_Philo[3]
|
||||
Obj-Dict 0x20000580->AO_Philo[4]
|
||||
Obj-Dict 0x0000A52C->timerID
|
||||
Usr-Dict 00000100->PHILO_STAT
|
||||
Usr-Dict 00000101->PAUSED_STAT
|
||||
Usr-Dict 00000102->COMMAND_STAT
|
||||
Usr-Dict 00000103->CONTEXT_SW
|
||||
Obj-Dict 0x20003054->EvtPool1
|
||||
Obj-Dict 0x20000180->Philo::inst[0]
|
||||
Obj-Dict 0x2000026C->Philo::inst[0].m_timeEvt
|
||||
Obj-Dict 0x20000280->Philo::inst[1]
|
||||
Obj-Dict 0x2000036C->Philo::inst[1].m_timeEvt
|
||||
Obj-Dict 0x20000380->Philo::inst[2]
|
||||
Obj-Dict 0x2000046C->Philo::inst[2].m_timeEvt
|
||||
Obj-Dict 0x20000480->Philo::inst[3]
|
||||
Obj-Dict 0x2000056C->Philo::inst[3].m_timeEvt
|
||||
Obj-Dict 0x20000580->Philo::inst[4]
|
||||
Obj-Dict 0x2000066C->Philo::inst[4].m_timeEvt
|
||||
Fun-Dict 0x00008929->Philo::initial
|
||||
Fun-Dict 0x0000890F->Philo::thinking
|
||||
Fun-Dict 0x00008917->Philo::hungry
|
||||
Fun-Dict 0x0000891F->Philo::eating
|
||||
Sig-Dict 00000004,Obj=0x00000000->TIMEOUT_SIG
|
||||
0000000327 AO-Subsc Obj=Philo::inst[0],Sig=00000005,Obj=0x20000180
|
||||
0000000327 AO-Subsc Obj=Philo::inst[0],Sig=00000009,Obj=0x20000180
|
||||
===RTC===> St-Init Obj=Philo::inst[0],State=0x00009B1B->Philo::thinking
|
||||
===RTC===> St-Entry Obj=Philo::inst[0],State=Philo::thinking
|
||||
0000000328 Init===> Obj=Philo::inst[0],State=Philo::thinking
|
||||
0000000334 AO-Subsc Obj=Philo::inst[1],Sig=00000005,Obj=0x20000280
|
||||
0000000334 AO-Subsc Obj=Philo::inst[1],Sig=00000009,Obj=0x20000280
|
||||
===RTC===> St-Init Obj=Philo::inst[1],State=0x00009B1B->Philo::thinking
|
||||
===RTC===> St-Entry Obj=Philo::inst[1],State=Philo::thinking
|
||||
0000000334 Init===> Obj=Philo::inst[1],State=Philo::thinking
|
||||
0000000340 AO-Subsc Obj=Philo::inst[2],Sig=00000005,Obj=0x20000380
|
||||
0000000340 AO-Subsc Obj=Philo::inst[2],Sig=00000009,Obj=0x20000380
|
||||
===RTC===> St-Init Obj=Philo::inst[2],State=0x00009B1B->Philo::thinking
|
||||
===RTC===> St-Entry Obj=Philo::inst[2],State=Philo::thinking
|
||||
0000000340 Init===> Obj=Philo::inst[2],State=Philo::thinking
|
||||
0000000346 AO-Subsc Obj=Philo::inst[3],Sig=00000005,Obj=0x20000480
|
||||
0000000346 AO-Subsc Obj=Philo::inst[3],Sig=00000009,Obj=0x20000480
|
||||
===RTC===> St-Init Obj=Philo::inst[3],State=0x00009B1B->Philo::thinking
|
||||
===RTC===> St-Entry Obj=Philo::inst[3],State=Philo::thinking
|
||||
0000000346 Init===> Obj=Philo::inst[3],State=Philo::thinking
|
||||
0000000352 AO-Subsc Obj=Philo::inst[4],Sig=00000005,Obj=0x20000580
|
||||
0000000352 AO-Subsc Obj=Philo::inst[4],Sig=00000009,Obj=0x20000580
|
||||
===RTC===> St-Init Obj=Philo::inst[4],State=0x00009B1B->Philo::thinking
|
||||
===RTC===> St-Entry Obj=Philo::inst[4],State=Philo::thinking
|
||||
0000000352 Init===> Obj=Philo::inst[4],State=Philo::thinking
|
||||
Obj-Dict 0x20000680->Table::inst
|
||||
Sig-Dict 00000006,Obj=0x00000000->DONE_SIG
|
||||
Sig-Dict 00000005,Obj=0x00000000->EAT_SIG
|
||||
Sig-Dict 00000007,Obj=0x00000000->PAUSE_SIG
|
||||
Sig-Dict 00000008,Obj=0x00000000->SERVE_SIG
|
||||
Sig-Dict 00000009,Obj=0x00000000->TEST_SIG
|
||||
Sig-Dict 00000011,Obj=0x20000680->HUNGRY_SIG
|
||||
0000000370 AO-Subsc Obj=Table::inst,Sig=DONE_SIG
|
||||
0000000370 AO-Subsc Obj=Table::inst,Sig=PAUSE_SIG
|
||||
0000000370 AO-Subsc Obj=Table::inst,Sig=SERVE_SIG
|
||||
0000000371 AO-Subsc Obj=Table::inst,Sig=TEST_SIG
|
||||
0000000371 PHILO_STAT 0 thinking
|
||||
0000000371 PHILO_STAT 1 thinking
|
||||
0000000371 PHILO_STAT 2 thinking
|
||||
0000000371 PHILO_STAT 3 thinking
|
||||
@endverbatim
|
||||
|
||||
@ifnot LATEX
|
||||
@nav_next{exa_os}
|
||||
@endif
|
||||
*/
|
||||
} // namespace QP
|
||||
@ -1,232 +0,0 @@
|
||||
@code{.c}
|
||||
================================================
|
||||
NLOC CCN token PARAM length location
|
||||
------------------------------------------------
|
||||
3 1 13 1 4 QP::QEvt::QEvt@182-185@..\include\qep.hpp
|
||||
7 1 27 2 7 QP::QEvt::QEvt@190-196@..\include\qep.hpp
|
||||
2 1 6 0 3 QP::QEvt::~QEvt@201-203@..\include\qep.hpp
|
||||
2 1 6 0 3 QP::QHsm::~QHsm@373-375@..\include\qep.hpp
|
||||
3 1 17 1 3 QP::QHsm::init@404-406@..\include\qep.hpp
|
||||
3 1 12 0 3 QP::QHsm::state@453-455@..\include\qep.hpp
|
||||
3 1 11 0 3 QP::QHsm::getStateHandler@459-461@..\include\qep.hpp
|
||||
4 1 18 1 4 QP::QHsm::tran@491-494@..\include\qep.hpp
|
||||
4 1 18 1 4 QP::QHsm::tran_hist@497-500@..\include\qep.hpp
|
||||
4 1 18 1 4 QP::QHsm::super@503-506@..\include\qep.hpp
|
||||
4 1 30 1 4 QP::QHsm::qm_tran@510-513@..\include\qep.hpp
|
||||
4 1 30 1 4 QP::QHsm::qm_tran_init@517-520@..\include\qep.hpp
|
||||
8 1 42 2 8 QP::QHsm::qm_tran_hist@524-531@..\include\qep.hpp
|
||||
4 1 30 1 4 QP::QHsm::qm_tran_ep@535-538@..\include\qep.hpp
|
||||
8 1 40 2 8 QP::QHsm::qm_tran_xp@542-549@..\include\qep.hpp
|
||||
4 1 20 1 4 QP::QHsm::qm_entry@553-556@..\include\qep.hpp
|
||||
4 1 22 1 4 QP::QHsm::qm_entry@561-564@..\include\qep.hpp
|
||||
4 1 20 1 4 QP::QHsm::qm_exit@569-572@..\include\qep.hpp
|
||||
4 1 22 1 4 QP::QHsm::qm_exit@577-580@..\include\qep.hpp
|
||||
4 1 20 1 4 QP::QHsm::qm_sm_exit@584-587@..\include\qep.hpp
|
||||
4 1 20 1 4 QP::QHsm::qm_super_sub@591-594@..\include\qep.hpp
|
||||
6 1 26 1 6 QP::QMsm::QMsm@680-685@..\include\qep.hpp
|
||||
3 1 20 1 3 QP::QMsm::init@698-700@..\include\qep.hpp
|
||||
3 1 12 0 3 QP::QMsm::stateObj@743-745@..\include\qep.hpp
|
||||
3 1 14 0 3 QP::QMsm::getStateHandler@774-776@..\include\qep.hpp
|
||||
3 1 10 0 3 QP::QEQueue::getNFree@289-291@..\include\qequeue.hpp
|
||||
3 1 10 0 3 QP::QEQueue::getNMin@304-306@..\include\qequeue.hpp
|
||||
3 1 12 0 3 QP::QEQueue::isEmpty@318-320@..\include\qequeue.hpp
|
||||
5 2 24 0 8 QP::QPSet::setEmpty@234-241@..\include\qf.hpp
|
||||
4 3 35 0 7 QP::QPSet::isEmpty@244-250@..\include\qf.hpp
|
||||
4 3 35 0 7 QP::QPSet::notEmpty@253-259@..\include\qf.hpp
|
||||
6 3 97 1 9 QP::QPSet::hasElement@262-270@..\include\qf.hpp
|
||||
11 3 101 1 14 QP::QPSet::insert@273-286@..\include\qf.hpp
|
||||
12 3 117 1 15 QP::QPSet::remove@289-303@..\include\qf.hpp
|
||||
6 3 45 0 9 QP::QPSet::findMax@306-314@..\include\qf.hpp
|
||||
9 1 49 5 9 QP::QActive::start@481-489@..\include\qf.hpp
|
||||
3 1 18 0 3 QP::QActive::getPrio@713-715@..\include\qf.hpp
|
||||
4 1 38 1 4 QP::QActive::setPrio@720-723@..\include\qf.hpp
|
||||
3 1 9 0 3 QP::QActive::getOsObject@735-737@..\include\qf.hpp
|
||||
3 1 9 0 3 QP::QActive::getThread@743-745@..\include\qf.hpp
|
||||
5 1 20 1 5 QP::QMActive::QMActive@895-899@..\include\qf.hpp
|
||||
3 1 12 0 3 QP::QMActive::stateObj@920-922@..\include\qf.hpp
|
||||
3 1 10 0 3 QP::QTimeEvt::getAct@1115-1117@..\include\qf.hpp
|
||||
3 1 10 0 3 QP::QTimeEvt::getCtr@1120-1122@..\include\qf.hpp
|
||||
3 1 10 0 3 QP::QTimeEvt::getInterval@1125-1127@..\include\qf.hpp
|
||||
3 1 16 0 3 QP::QTimeEvt::toActive@1182-1184@..\include\qf.hpp
|
||||
3 1 16 0 3 QP::QTimeEvt::toTimeEvt@1187-1189@..\include\qf.hpp
|
||||
6 1 23 2 6 QP::QF::psInit@1348-1353@..\include\qf.hpp
|
||||
7 1 34 3 7 QP::QF::publish_@1360-1366@..\include\qf.hpp
|
||||
6 1 26 2 6 QP::QF::tick_@1373-1378@..\include\qf.hpp
|
||||
3 1 29 1 3 QP::QEvt_refCtr_inc_@112-114@..\include\qf_pkg.hpp
|
||||
3 1 29 1 3 QP::QEvt_refCtr_dec_@117-119@..\include\qf_pkg.hpp
|
||||
3 1 10 0 3 QP::QMPool::getNMin@263-265@..\include\qmpool.hpp
|
||||
3 1 10 0 3 QP::QMPool::getNFree@275-277@..\include\qmpool.hpp
|
||||
3 1 18 0 3 QP::QSpyId::getPrio@335-337@..\include\qs.hpp
|
||||
7 1 28 1 7 QP::QS::force_cast@417-423@..\include\qs.hpp
|
||||
14 3 70 1 14 QP::QS::rxPut@831-844@..\include\qs.hpp
|
||||
9 1 49 5 9 QP::QActiveDummy::start@1562-1570@..\include\qs.hpp
|
||||
3 1 18 0 3 QP::QSpyId::getPrio@137-139@..\include\qs_dummy.hpp
|
||||
3 1 11 0 3 QP::QXThread::getTimeEvt@208-210@..\include\qxk.hpp
|
||||
9 1 49 5 9 QP::QXThread::start@310-318@..\include\qxk.hpp
|
||||
2 1 39 2 3 QP::QEvt@86-88@..\src\qf\qep_hsm.cpp
|
||||
7 1 41 3 7 hsm_reservedEvt_@103-109@..\src\qf\qep_hsm.cpp
|
||||
17 3 102 3 20 hsm_state_entry_@117-136@..\src\qf\qep_hsm.cpp
|
||||
23 3 114 3 26 hsm_state_exit_@148-173@..\src\qf\qep_hsm.cpp
|
||||
4 1 27 1 4 QP::QHsm::QHsm@183-186@..\src\qf\qep_hsm.cpp
|
||||
54 9 359 2 78 QP::QHsm::init@189-266@..\src\qf\qep_hsm.cpp
|
||||
103 15 609 2 158 QP::QHsm::dispatch@269-426@..\src\qf\qep_hsm.cpp
|
||||
8 1 31 2 8 QP::QHsm::top@429-436@..\src\qf\qep_hsm.cpp
|
||||
16 3 87 1 22 QP::QHsm::isIn@439-460@..\src\qf\qep_hsm.cpp
|
||||
20 4 107 1 29 QP::QHsm::childState@463-491@..\src\qf\qep_hsm.cpp
|
||||
90 15 487 2 132 QP::QHsm::hsm_tran@494-625@..\src\qf\qep_hsm.cpp
|
||||
25 3 165 2 38 QP::QMsm::init@79-116@..\src\qf\qep_msm.cpp
|
||||
117 21 664 2 169 QP::QMsm::dispatch@119-287@..\src\qf\qep_msm.cpp
|
||||
13 3 59 1 14 QP::QMsm::isInState@290-303@..\src\qf\qep_msm.cpp
|
||||
28 7 137 1 35 QP::QMsm::childStateObj@306-340@..\src\qf\qep_msm.cpp
|
||||
51 9 294 2 62 QP::QMsm::execTatbl_@343-404@..\src\qf\qep_msm.cpp
|
||||
22 4 107 3 29 QP::QMsm::exitToTranSource_@407-435@..\src\qf\qep_msm.cpp
|
||||
44 6 227 2 55 QP::QMsm::enterHistory_@438-492@..\src\qf\qep_msm.cpp
|
||||
82 14 410 3 120 QP::QActive::post_@77-196@..\src\qf\qf_actq.cpp
|
||||
42 7 237 1 63 QP::QActive::postLIFO@204-266@..\src\qf\qf_actq.cpp
|
||||
34 3 205 0 45 QP::QActive::get_@274-318@..\src\qf\qf_actq.cpp
|
||||
10 2 72 1 11 QP::QF::getQueueMin@328-338@..\src\qf\qf_actq.cpp
|
||||
5 1 30 1 6 QP::QTicker::QTicker@351-356@..\src\qf\qf_actq.cpp
|
||||
8 1 34 2 8 QP::QTicker::init@359-366@..\src\qf\qf_actq.cpp
|
||||
3 1 21 1 3 QP::QTicker::init@369-371@..\src\qf\qf_actq.cpp
|
||||
16 2 81 2 18 QP::QTicker::dispatch@374-391@..\src\qf\qf_actq.cpp
|
||||
30 3 166 3 42 QP::QTicker::post_@394-435@..\src\qf\qf_actq.cpp
|
||||
15 1 79 2 17 QP::QActive::defer@70-86@..\src\qf\qf_defer.cpp
|
||||
32 3 157 1 50 QP::QActive::recall@94-143@..\src\qf\qf_defer.cpp
|
||||
11 3 62 1 13 QP::QActive::flushDeferred@151-163@..\src\qf\qf_defer.cpp
|
||||
18 3 151 3 26 QP::QF::poolInit@97-122@..\src\qf\qf_dyn.cpp
|
||||
41 7 282 3 57 QP::QF::newX_@125-181@..\src\qf\qf_dyn.cpp
|
||||
35 5 257 1 57 QP::QF::gc@184-240@..\src\qf\qf_dyn.cpp
|
||||
3 1 21 0 3 QP::QF::poolGetMaxBlockSize@243-245@..\src\qf\qf_dyn.cpp
|
||||
19 2 104 2 26 QP::QF::newRef_@248-273@..\src\qf\qf_dyn.cpp
|
||||
11 2 68 1 14 QP::QF::deleteRef_@276-289@..\src\qf\qf_dyn.cpp
|
||||
10 3 77 1 12 QP::QF::getPoolMin@292-303@..\src\qf\qf_dyn.cpp
|
||||
9 1 42 0 9 QP::QMPool::QMPool@71-79@..\src\qf\qf_mem.cpp
|
||||
33 5 234 3 55 QP::QMPool::init@82-136@..\src\qf\qf_mem.cpp
|
||||
43 4 208 2 71 QP::QMPool::get@139-209@..\src\qf\qf_mem.cpp
|
||||
20 2 107 2 26 QP::QMPool::put@212-237@..\src\qf\qf_mem.cpp
|
||||
3 1 12 0 3 QP::QMPool::getBlockSize@240-242@..\src\qf\qf_mem.cpp
|
||||
9 1 44 2 9 QP::QActive::psInit@83-91@..\src\qf\qf_ps.cpp
|
||||
42 6 238 3 71 QP::QActive::publish_@99-169@..\src\qf\qf_ps.cpp
|
||||
16 5 108 1 20 QP::QActive::subscribe@177-196@..\src\qf\qf_ps.cpp
|
||||
16 5 108 1 23 QP::QActive::unsubscribe@204-226@..\src\qf\qf_ps.cpp
|
||||
19 5 127 0 25 QP::QActive::unsubscribeAll@234-258@..\src\qf\qf_ps.cpp
|
||||
10 2 59 2 10 QP::QF::bzero@107-116@..\src\qf\qf_qact.cpp
|
||||
9 4 65 1 17 QP::QActive::QActive@127-143@..\src\qf\qf_qact.cpp
|
||||
30 10 198 0 46 QP::QActive::register_@151-196@..\src\qf\qf_qact.cpp
|
||||
10 3 72 0 11 QP::QActive::unregister_@204-214@..\src\qf\qf_qact.cpp
|
||||
24 6 158 1 29 QP::QPSet::QF_LOG2@225-253@..\src\qf\qf_qact.cpp
|
||||
9 1 43 0 9 QP::QEQueue::QEQueue@71-79@..\src\qf\qf_qeq.cpp
|
||||
14 2 74 2 14 QP::QEQueue::init@82-95@..\src\qf\qf_qeq.cpp
|
||||
57 8 281 3 76 QP::QEQueue::post@98-173@..\src\qf\qf_qeq.cpp
|
||||
36 5 174 2 46 QP::QEQueue::postLIFO@176-221@..\src\qf\qf_qeq.cpp
|
||||
36 4 190 1 46 QP::QEQueue::get@224-269@..\src\qf\qf_qeq.cpp
|
||||
7 1 41 2 7 QP::QMActive::init@78-84@..\src\qf\qf_qmact.cpp
|
||||
4 1 33 1 4 QP::QMActive::init@87-90@..\src\qf\qf_qmact.cpp
|
||||
6 1 32 2 6 QP::QMActive::dispatch@93-98@..\src\qf\qf_qmact.cpp
|
||||
3 1 27 1 3 QP::QMActive::isInState@101-103@..\src\qf\qf_qmact.cpp
|
||||
4 1 27 1 4 QP::QMActive::childStateObj@106-109@..\src\qf\qf_qmact.cpp
|
||||
3 1 20 0 3 QP::QMActive::getStateHandler@113-115@..\src\qf\qf_qmact.cpp
|
||||
18 2 101 3 34 QP::QTimeEvt::QTimeEvt@72-105@..\src\qf\qf_time.cpp
|
||||
34 8 217 2 58 QP::QTimeEvt::armX@108-165@..\src\qf\qf_time.cpp
|
||||
32 3 169 0 41 QP::QTimeEvt::disarm@168-208@..\src\qf\qf_time.cpp
|
||||
33 8 217 1 58 QP::QTimeEvt::rearm@211-268@..\src\qf\qf_time.cpp
|
||||
5 1 37 0 6 QP::QTimeEvt::wasDisarmed@271-276@..\src\qf\qf_time.cpp
|
||||
72 7 396 2 112 QP::QTimeEvt::tick_@279-390@..\src\qf\qf_time.cpp
|
||||
14 3 70 1 16 QP::QTimeEvt::noActive@393-408@..\src\qf\qf_time.cpp
|
||||
13 1 50 0 27 QP::QTimeEvt::QTimeEvt@411-437@..\src\qf\qf_time.cpp
|
||||
22 2 136 1 32 QP::QK::schedLock@76-107@..\src\qk\qk.cpp
|
||||
20 4 129 1 32 QP::QK::schedUnlock@110-141@..\src\qk\qk.cpp
|
||||
14 3 144 0 25 QP::QF::init@151-175@..\src\qk\qk.cpp
|
||||
3 1 9 0 4 QP::QF::stop@178-181@..\src\qk\qk.cpp
|
||||
19 6 85 0 34 QP::QF::run@184-217@..\src\qk\qk.cpp
|
||||
25 3 146 6 34 QP::QActive::start@228-261@..\src\qk\qk.cpp
|
||||
19 4 93 0 24 QK_sched_@274-297@..\src\qk\qk.cpp
|
||||
66 17 426 0 113 QK_activate_@300-412@..\src\qk\qk.cpp
|
||||
7 3 66 0 13 QP::QF::init@83-95@..\src\qv\qv.cpp
|
||||
3 1 9 0 4 QP::QF::stop@98-101@..\src\qv\qv.cpp
|
||||
45 15 248 0 92 QP::QF::run@104-195@..\src\qv\qv.cpp
|
||||
18 1 114 6 25 QP::QActive::start@206-230@..\src\qv\qv.cpp
|
||||
24 3 152 1 35 QP::QXK::schedLock@77-111@..\src\qxk\qxk.cpp
|
||||
20 4 129 1 32 QP::QXK::schedUnlock@114-145@..\src\qxk\qxk.cpp
|
||||
14 3 144 0 25 QP::QF::init@155-179@..\src\qxk\qxk.cpp
|
||||
3 1 9 0 4 QP::QF::stop@182-185@..\src\qxk\qxk.cpp
|
||||
20 6 103 0 36 QP::QF::run@188-223@..\src\qxk\qxk.cpp
|
||||
29 5 159 6 40 QP::QActive::start@234-273@..\src\qxk\qxk.cpp
|
||||
43 8 230 0 54 QXK_sched_@286-339@..\src\qxk\qxk.cpp
|
||||
59 16 382 0 96 QXK_activate_@342-437@..\src\qxk\qxk.cpp
|
||||
12 2 69 0 18 QXK_current@440-457@..\src\qxk\qxk.cpp
|
||||
19 5 105 1 26 QXK_contextSw@461-486@..\src\qxk\qxk.cpp
|
||||
14 2 110 0 23 QXK_threadExit_@490-512@..\src\qxk\qxk.cpp
|
||||
3 1 15 0 3 QP::QXMutex::QXMutex@76-78@..\src\qxk\qxk_mutex.cpp
|
||||
8 2 60 1 11 QP::QXMutex::init@81-91@..\src\qxk\qxk_mutex.cpp
|
||||
59 9 467 0 94 QP::QXMutex::tryLock@94-187@..\src\qxk\qxk_mutex.cpp
|
||||
80 11 644 1 133 QP::QXMutex::lock@190-322@..\src\qxk\qxk_mutex.cpp
|
||||
76 13 599 0 128 QP::QXMutex::unlock@325-452@..\src\qxk\qxk_mutex.cpp
|
||||
9 1 58 2 11 QP::QXSemaphore::init@76-86@..\src\qxk\qxk_sema.cpp
|
||||
54 7 346 1 79 QP::QXSemaphore::wait@89-167@..\src\qxk\qxk_sema.cpp
|
||||
27 3 131 0 38 QP::QXSemaphore::tryWait@170-207@..\src\qxk\qxk_sema.cpp
|
||||
41 7 251 0 64 QP::QXSemaphore::signal@210-273@..\src\qxk\qxk_sema.cpp
|
||||
9 1 56 2 9 QP::QXThread::QXThread@77-85@..\src\qxk\qxk_xthr.cpp
|
||||
21 4 178 1 36 QP::QXThread::delay@88-123@..\src\qxk\qxk_xthr.cpp
|
||||
14 2 57 0 16 QP::QXThread::delayCancel@126-141@..\src\qxk\qxk_xthr.cpp
|
||||
58 7 429 1 86 QP::QXThread::queueGet@144-229@..\src\qxk\qxk_xthr.cpp
|
||||
8 1 33 2 8 QP::QXThread::init@232-239@..\src\qxk\qxk_xthr.cpp
|
||||
4 1 22 1 4 QP::QXThread::init@242-245@..\src\qxk\qxk_xthr.cpp
|
||||
8 1 33 2 8 QP::QXThread::dispatch@248-255@..\src\qxk\qxk_xthr.cpp
|
||||
30 7 191 6 49 QP::QXThread::start@258-306@..\src\qxk\qxk_xthr.cpp
|
||||
96 15 480 3 133 QP::QXThread::post_@309-441@..\src\qxk\qxk_xthr.cpp
|
||||
4 1 23 1 4 QP::QXThread::postLIFO@444-447@..\src\qxk\qxk_xthr.cpp
|
||||
5 1 49 0 6 QP::QXThread::block_@450-455@..\src\qxk\qxk_xthr.cpp
|
||||
8 3 58 0 9 QP::QXThread::unblock_@458-466@..\src\qxk\qxk_xthr.cpp
|
||||
22 3 153 2 40 QP::QXThread::teArm_@469-508@..\src\qxk\qxk_xthr.cpp
|
||||
11 2 41 0 14 QP::QXThread::teDisarm_@511-524@..\src\qxk\qxk_xthr.cpp
|
||||
34 file analyzed.
|
||||
==============================================================
|
||||
NLOC Avg.NLOC AvgCCN Avg.token function_cnt file
|
||||
--------------------------------------------------------------
|
||||
6 0.0 0.0 0.0 0 ..\include\qassert.h
|
||||
235 4.1 1.0 20.6 25 ..\include\qep.hpp
|
||||
46 3.0 1.0 10.7 3 ..\include\qequeue.hpp
|
||||
322 5.1 1.6 34.3 22 ..\include\qf.hpp
|
||||
24 3.0 1.0 29.0 2 ..\include\qf_pkg.hpp
|
||||
22 0.0 0.0 0.0 0 ..\include\qk.hpp
|
||||
49 3.0 1.0 10.0 2 ..\include\qmpool.hpp
|
||||
5 0.0 0.0 0.0 0 ..\include\qpcpp.hpp
|
||||
401 8.2 1.5 41.2 4 ..\include\qs.hpp
|
||||
5 0.0 0.0 0.0 0 ..\include\qstamp.cpp
|
||||
4 0.0 0.0 0.0 0 ..\include\qstamp.hpp
|
||||
25 3.0 1.0 18.0 1 ..\include\qs_dummy.hpp
|
||||
25 0.0 0.0 0.0 0 ..\include\qs_pkg.hpp
|
||||
9 0.0 0.0 0.0 0 ..\include\quit.hpp
|
||||
8 0.0 0.0 0.0 0 ..\include\qv.hpp
|
||||
119 6.0 1.0 30.0 2 ..\include\qxk.hpp
|
||||
364 31.3 5.1 182.1 11 ..\src\qf\qep_hsm.cpp
|
||||
317 42.9 7.6 236.1 7 ..\src\qf\qep_msm.cpp
|
||||
2 0.0 0.0 0.0 0 ..\src\qf\qf_act.cpp
|
||||
251 25.6 3.8 139.6 9 ..\src\qf\qf_actq.cpp
|
||||
73 19.3 2.3 99.3 3 ..\src\qf\qf_defer.cpp
|
||||
160 19.6 3.3 137.1 7 ..\src\qf\qf_dyn.cpp
|
||||
119 21.6 2.6 120.6 5 ..\src\qf\qf_mem.cpp
|
||||
127 20.4 4.4 125.0 5 ..\src\qf\qf_ps.cpp
|
||||
122 16.6 5.0 110.4 5 ..\src\qf\qf_qact.cpp
|
||||
163 30.4 4.0 152.4 5 ..\src\qf\qf_qeq.cpp
|
||||
33 4.5 1.0 30.0 6 ..\src\qf\qf_qmact.cpp
|
||||
233 27.6 4.1 157.1 8 ..\src\qf\qf_time.cpp
|
||||
210 23.5 5.0 146.0 8 ..\src\qk\qk.cpp
|
||||
92 18.2 5.0 109.2 4 ..\src\qv\qv.cpp
|
||||
279 23.4 5.0 144.7 11 ..\src\qxk\qxk.cpp
|
||||
237 45.2 7.2 357.0 5 ..\src\qxk\qxk_mutex.cpp
|
||||
142 32.8 4.5 196.5 4 ..\src\qxk\qxk_sema.cpp
|
||||
309 21.3 3.5 128.8 14 ..\src\qxk\qxk_xthr.cpp
|
||||
|
||||
=========================================================================================================
|
||||
!!!! Warnings (cyclomatic_complexity > 20 or length > 500 or nloc > 1000000 or parameter_count > 10) !!!!
|
||||
================================================
|
||||
NLOC CCN token PARAM length location
|
||||
------------------------------------------------
|
||||
117 21 664 2 169 QP::QMsm::dispatch@119-287@..\src\qf\qep_msm.cpp
|
||||
==========================================================================================
|
||||
Total nloc Avg.NLOC AvgCCN Avg.token Fun Cnt Warning cnt Fun Rt nloc Rt
|
||||
------------------------------------------------------------------------------------------
|
||||
4538 18.1 3.3 108.7 178 1 0.01 0.04
|
||||
@endcode
|
||||
503
doxygen/gs.dox
503
doxygen/gs.dox
@ -1,503 +0,0 @@
|
||||
/*! @page gs Getting Started
|
||||
|
||||
The following sections describe how to get started with QP™/C++ quickly:
|
||||
- @subpage gs_get
|
||||
- @subpage gs_tut
|
||||
|
||||
The YouTube Video <a class="extern" target="_blank" href="https://youtu.be/O7ER6_VqIH0"><strong>Getting Started with QP™ Frameworks</strong></a> provides instructions on how to download, install and get started with QP quickly.
|
||||
|
||||
[](https://youtu.be/O7ER6_VqIH0)
|
||||
|
||||
@note
|
||||
<a href="modules.html" title="QP Cert-Pack"><img src="cert-pack.png" style="float:right; margin:0 20px 20px 0;"></img></a>
|
||||
Information about the QP/C++ functionality, architecture, design, and other aspects is provided in the [Certification Package](modules.html):
|
||||
- @ref srs — QP/C++ functionality
|
||||
- @ref sas — QP/C++ architecture
|
||||
- @ref sds — QP/C++ design
|
||||
- @ref autosar — QP/C++ compliance with AUTOSAR-C++ guidelines
|
||||
|
||||
@nav{index,gs_get}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page gs_get Downloading & Installing QP™/C++
|
||||
@nav{gs,gs_tut}
|
||||
|
||||
@section gs_bundle Downloading QP™/C++ in QP™-Bundle
|
||||
The most recommended way of obtaining QP™/C++ is by downloading the @webref{#Downloads, <b>QP-bundle™</b>}, which includes QP™/C++ as well as other QP™ frameworks and also the @webref{products/qm, QM™ modeling tool} and the @webref{products/qtools, QTools™ collection}. The main advantage of obtaining QP™/C++ bundled together like that is that you get all components, tools and examples ready to go.
|
||||
|
||||
[](https://www.state-machine.com/#Downloads)
|
||||
|
||||
@note
|
||||
<a target="_blank" href="https://github.com/QuantumLeaps/qpc" title="QP™/C++ on GitHub"><img style="float:right; clear:right;" src="img/github-corner.png"></a>
|
||||
If you are allergic to installers and GUIs or don't have administrator privileges you can also **download and install QP™/C++ separately** from the <a class="extern" target="_blank" href="https://github.com/QuantumLeaps/qpc"><b>QP™/C++ GitHub repository</b></a>, as described in the next section.
|
||||
|
||||
|
||||
@section gs_gh Downloading QP™/C++ from GitHub
|
||||
Go to the <a class="extern" href="https://github.com/QuantumLeaps/qpcpp/releases" target="_blank">QP™/C++ <strong>release</strong> page on GitHub</a>, and choose the QP™/C++ version number you wish to download. You should select the latest QP™/C++ version, unless you have a very specific reason to go with an older release.
|
||||
|
||||
|
||||
|
||||
|
||||
@section gs_dir QP™/C++ Installation Folder
|
||||
The following annotated directory tree lists the top-level directories provided in the standard QP™/C++ distribution.
|
||||
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">qpcpp/</span>
|
||||
</li>
|
||||
<ul class="tag">
|
||||
<li><span class="img folder">3rd_party/</span> — 3rd-Party code used in the @ref exa "QP™/C++ Examples"
|
||||
</li>
|
||||
<li><span class="img folder">examples/</span> — @ref exa "QP™/C++ Examples"
|
||||
</li>
|
||||
<li><span class="img folder">ports/</span> — @ref ports "QP™/C++ Ports"
|
||||
</li>
|
||||
<li><span class="img folder">@ref /qp-dev/qpcpp/include "include/"</span> — Platform-independent QP™/C++ API, see also @ref api
|
||||
</li>
|
||||
<li><span class="img folder">@ref /qp-dev/qpcpp/src "src/"</span> — Platform-independent QP™/C++ source code
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
@attention
|
||||
The QP/C++ GitHub repository does not contain the `3rd_party` folder, which is needed to build the @ref exa "QP™/C++ Examples". Therefore, it is highly **recommended** to download the latest [QP/C++ Release](https://github.com/QuantumLeaps/qpcpp/releases) as opposed to cloning the repo directly.
|
||||
|
||||
@remark
|
||||
The standard QP™/C++ distribution contains the `examples` folder with many @ref exa "Example Projects", which are specifically designed to help you learn to use QP™/C++ and to serve you as starting points for your own projects.
|
||||
|
||||
<div style="clear:both;"></div>
|
||||
@nav{gs,gs_tut}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page gs_tut QP™/C++ Tutorial
|
||||
@nav{gs_over,tut_blinky}
|
||||
|
||||
This Tutorial describes how to use the QP/C++™ real-time embedded framework in a series of progressively advancing examples. The first example ("Blinky") uses only one Active Object with a simple non-hierarchical state machine. The following example ("DPP") demonstrates multiple, communicating Active Objects. Finally, the last example ("Fly'n'Shoot" game) demonstrates all features the QP™ framework. It is highly recommended to study the simpler examples before the more advanced ones, as the basic information won't be repeated in the later examples.
|
||||
|
||||
This Tutorial consists of the following lessons:
|
||||
- @subpage tut_blinky
|
||||
- @subpage tut_dpp
|
||||
- @subpage tut_game
|
||||
- @subpage tut_low
|
||||
|
||||
@remark
|
||||
Perhaps the most important fact of life to remember is that in embedded systems nothing works until everything works. This means that you should always start with a *working* system and *gradually* evolve it, changing one thing at a time and making sure that it keeps *working* every step of the way.<br>
|
||||
<br>
|
||||
Keeping this in mind, the provided @ref exa "QP™/C++ application examples", such as the super-simple Blinky, or a bit more advanced DPP or “Fly 'n' Shoot” game, allow you to get started with a working project rather than starting from scratch. You should also always try one of the provided example projects on the same evaluation board that it was designed for, before making any changes.
|
||||
|
||||
|
||||
Only after convincing yourself that the example project works "as is", you can think about creating your own projects. At this point, the easiest and recommended way is to copy the existing working example project folder (such as the Blinky example) and rename it.
|
||||
|
||||
After copying the project folder, you still need to change the name of the project/workspace. The easiest and safest way to do this is to open the project/workspace in the corresponding IDE and use the Save As... option to save the project under a different name. (You can do this also with the @webref{products/qm, QM model file}, which you can open in QM and "Save As" a different model.)
|
||||
|
||||
@note
|
||||
By copying and re-naming an existing, working project, as opposed to creating a new one from scratch, you inherit the correct compiler and linker options an other project settings, which will help you get started much faster.
|
||||
|
||||
<div style="clear:both;"></div>
|
||||
@nav{gs_over,tut_blinky}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page tut_blinky Simple Blinky Application
|
||||
@nav{gs_tut,tut_dpp}
|
||||
|
||||
The ultra-simple Blinky example is the embedded systems' equivalent of the venerable <i>"Hello World!"</i> program, that is, the simplest possible working QP™ application that does "something". In the case of Blinky, this "something" is blinking an LED at the rate of 1Hz, where an LED turns on and remains on for 0.5 seconds on then turns off and remains off for 0.5 seconds.
|
||||
|
||||
|
||||
|
||||
@note
|
||||
The Blinky example is provided for other supported boards as well, not just TivaC LaunchPad. Please look for examples named <span class="img folder">dpp_<board-name></span> in the @ref exa "qpcpp/examples/examples" directory (e.g., `qpcpp/examples/arm-cm/blinky_ek-tm4c123gxl` for the EK-TM4C123GXL board (TivaC LaunchPad)).
|
||||
|
||||
|
||||
The ultra-simple Blinky application, which consists of just one active object named `Blinky`, is intentionally kept small and illustrates only the most basic QP features, such as:
|
||||
|
||||
- a simple Blinky active object (AO) @ref oop "class";
|
||||
- hand-coding the simple state machine of the Blinky AO;
|
||||
- using a periodic time event;
|
||||
- initializing the QP™ framework;
|
||||
- starting an active object; and
|
||||
- transferring control to QP™ to run the application.
|
||||
|
||||
The details of the Blinky application are describe in the Quantum Leaps Application Note @webref{doc/AN_Getting_Started_with_QP.pdf, Getting Started with QP™ Real-Time Embedded Frameworks}.
|
||||
|
||||
[](https://www.state-machine.com/doc/AN_Getting_Started_with_QP.pdf)
|
||||
|
||||
<div style="clear:both;"></div>
|
||||
@nav{gs_tut,tut_dpp}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page tut_dpp Dining Philosophers Problem (DPP)
|
||||
@nav{tut_blinky,tut_game}
|
||||
|
||||
The Dining Philosophers Problem (DPP) example is an intermediate-level application with *multiple* active objects. It illustrates the following QP™ features, such as:
|
||||
|
||||
- multiple active objects, including an array of active objects;
|
||||
- designing the simple state machines in the QM tool and generating the code automatically (can be also done manually);
|
||||
- using multiple periodic time events;
|
||||
- using mutable events with parameters;
|
||||
- direct event posting to active objects;
|
||||
- publish-subscribe event delivery;
|
||||
- initializing the QP™ framework;
|
||||
- starting multiple active objects; and
|
||||
- transferring control to QP™ to run the application.
|
||||
|
||||
@note
|
||||
The DPP example is provided for most supported boards as well as in the command-line version (on the host). Please look for examples named <span class="img folder">dpp_<board-name></span> in the @ref exa "qpcpp/examples/examples" directory (e.g., `qpcpp/examples/arm-cm/dpp_ek-tm4c123gxl` for the EK-TM4C123GXL board (TivaC LaunchPad)).
|
||||
|
||||
The Dining Philosophers Problem (DPP) example is described in the @webref{doc/AN_DPP.pdf, Application Note: Dining Philosophers Problem (DPP) Example}.
|
||||
|
||||
[](https://www.state-machine.com/doc/AN_DPP.pdf)
|
||||
|
||||
|
||||
@note
|
||||
There is also a DPP variant that implements the "Philosophers" as passive "Orthogonal Components" of the "Table" active object. That DPP version is located in <span class="img folder">qpcpp/examples/examples/workstation/dpp-comp/</span>
|
||||
|
||||
<div style="clear:both;"></div>
|
||||
@nav{tut_blinky,tut_game}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page tut_game "Fly 'n' Shoot" Game
|
||||
@nav{tut_dpp,tut_low}
|
||||
|
||||
The "Fly 'n' shoot" game example is a moderately advanced application of a vintage computer game. It requires a LCD screen and push-buttons on the board.
|
||||
|
||||
|
||||
|
||||
"Fly 'n' shoot" game and illustrates the following QP™ features, such as:
|
||||
|
||||
- multiple active objects;
|
||||
- multiple passive state machines ("Orthogonal Components");
|
||||
- multiple periodic time events;
|
||||
- mutable events with parameters;
|
||||
- direct event posting to active objects;
|
||||
- publish-subscribe event delivery;
|
||||
- developing of embedded software on Windows (see also @webref{qtools/qwin.html,QWin™ GUI Prototyping Toolkit})
|
||||
|
||||
|
||||
|
||||
The "Fly 'n' Shoot" game example is described in the @webref{doc/AN_Fly-n-Shoot.pdf, Application Note: Fly 'n' Shoot Game Example}.
|
||||
|
||||
|
||||
[](https://www.state-machine.com/doc/AN_Fly-n-Shoot.pdf)
|
||||
|
||||
|
||||
[](https://youtu.be/h_u92uLssDo)
|
||||
|
||||
<div style="clear:both;"></div>
|
||||
@nav{tut_dpp,tut_low}
|
||||
*/
|
||||
/*##########################################################################*/
|
||||
/*! @page tut_low Low-Power Example
|
||||
@nav{tut_game,exa}
|
||||
|
||||
The main principle of low-power design for software is to keep the hardware in the most appropriate low-power sleep mode for as long as possible. Most commonly, the software enters a low-power sleep mode from the **idle callback** (a.k.a. "idle hook"), which is called when the software has nothing left to do and is waiting for an interrupt to deliver more work. The QP/C++ and QP/C++ Real-Time Embedded Frameworks (RTEFs) support the *idle callback* in all of the built-in real-time kernels, such as the cooperative @ref srs_qv "QV kernel", the preemptive non-blocking @ref srs_qk "QK kernel" and the preemptive blocking @ref srs_qxk "QXK kernel". Also, such an *idle callback* is provided in all 3rd-party traditional RTOS kernels that QP/C/C++ have been @ref ports_rtos "ported to".
|
||||
|
||||
@remark
|
||||
Design for low-power is a broad subject that requires a holistic system approach to achieve a really long battery-powered operation. This example covers only certain *software-related* aspects of the problem.
|
||||
|
||||
|
||||
@section arm-cm_low_power_tick The System Clock Tick
|
||||
Most real-time systems, including traditional RTOSes and RTEFs, require a periodic time
|
||||
source called the **system clock tick** to keep track of time delays, timeouts, and QP::QTimeEvt "time events" in case of the event-driven QP frameworks. The system clock tick is typically a periodic
|
||||
interrupt that occurs at a predetermined rate, typically between 10Hz and 1000Hz.
|
||||
|
||||
While the system clock tick is very useful, it also has the unfortunate side effect of taking the processor out of a low power state as many as 1000 times per second regardless if real work needs to be done or not. This effect can have a significant negative impact on the power efficiency of the system.
|
||||
|
||||
|
||||
|
||||
|
||||
@subsection arm-cm_low_power_tickless The "Tickless Mode"
|
||||
Some real-time kernels use the low-power optimization called the "tickless mode" (a.k.a. "tick supression" or "dynamic tick"). In this mode, instead of indiscriminately making the clock tick fire with a fixed period, the kernel adjusts the clock ticks *dynamically*, as needed. Specifically, after each clock tick the kernel re-calculates the time for the next clock tick and then sets the clock tick interrupt for the earliest timeout it has to wait for. So for example, if the shortest wait the kernel has to attend to is 300 milliseconds into the future, then the clock interrupt will be set for 300 milliseconds.
|
||||
|
||||
This approach maximizes the amount of time the processor can remain asleep, but requires the kernel to perform the additional work to calculate the dynamic tick intervals and to program them into the hardware. This additional bookkeeping adds complexity to the kernel, is often non-deterministic and, most importantly, extends the time CPU spends in the high-power active mode and thus eliminates some of the power gains the "tickless mode" was supposed to bring.
|
||||
|
||||
Also, the "tickless mode" requires a more capable hardware timer that must be able of being reprogrammed for every interrupt in a wide dynamic range and also must accurately keep track of the elapsed time to correct for the irregular (dynamic) tick intervals. Still, "tickless mode" often causes a drift in the timing of the clock tick.
|
||||
|
||||
|
||||
@subsection arm-cm_low_power_multiple Multiple Tick Rates
|
||||
For the reasons just mentioned, the QP™ Real-Time Embedded Frameworks don't provide the "tickless mode". Instead, the QP™ frameworks support **multiple clock tick rates**, which can be turned on and off, as needed. The QP™ frameworks also provide methods for finding out *when* a given clock tick rate is not used, which allows the idle callback inside the application to shut down the given clock tick rate and also to decide which sleep mode to use for the CPU and the peripherals.
|
||||
|
||||
The support for multiple static clock tick rates is much *simpler* than the "dynamic tick", and essentially does not increase the complexity of the kernel (because the same code for the single tick rate can handle other tick rates the same way). Also, multiple static tick rates require much simpler hardware timers, which can be clocked specifically to the desired frequency and don't need particularly wide dynamic range. For example, 16-bit timers or even 8-bit timers are completely adequate.
|
||||
|
||||
Yet the *multiple clock rates* can deliver similar low-power operation for the system, while keeping the QP framework much simpler and easier to certify than "tickless" kernels. The rest of this example explains how to use the multiple static clock rates in QP/C/C++ and shows how to leverage this feature to achieve low-power software design.
|
||||
|
||||
|
||||
@section arm-cm_low_power_app The Low-Power Example Application
|
||||
The low-power example is located in QP/C and QP/C++ distributions, in the directory with the following structure:
|
||||
|
||||
@code{.c}
|
||||
qpc|qpcpp/ // QP/C/C++ installation directory
|
||||
+-examples/ // QP/C/C++ examples directory (application)
|
||||
| +-arm-cm/ // QP/C/C++ examples for ARM Cortex-M
|
||||
| | +-low-power_ek-tm4c123gxl/ // Low-Power example on the EK-TM4C123GLX board
|
||||
| | | +-qk/ //----------- Projects for the preemptive QK kernel
|
||||
| | | | +-arm/ // ARM-KEIL toolchain
|
||||
| | | | | +-low-power-qk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-low-power-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.c // BSP for the QK kernel
|
||||
| | | +-qv/ //----------- Projects for the cooperative QV kernel
|
||||
| | | | +-arm/ // ARM-KEIL toolchain
|
||||
| | | | | +-low-power-qv.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project with GNU-ARM
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-low-power-qk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.c|.cpp // BSP for the QV kernel
|
||||
| | | +-qxk/ //----------- Projects for the dual-mode QXK kernel
|
||||
| | | | +-arm/ // ARM-KEIL toolchain
|
||||
| | | | | +-low-power-qxk.uvprojx // uVision project
|
||||
| | | | +-gnu/ // GNU-ARM toolchain
|
||||
| | | | | +-Makefile // Makefile for building the project
|
||||
| | | | +-iar/ // IAR-ARM toolchain
|
||||
| | | | | +-low-power-qxk.eww // IAR EW-ARM workspace
|
||||
| | | | +-bsp.c|.cpp // BSP for the QxK kernel
|
||||
| | | | +-xblinky1.c|.cpp // eXtended thread for the QXK kernel
|
||||
@endcode
|
||||
|
||||
|
||||
@note
|
||||
To focus the discussion, this example uses the **EK-TM4C123GXL** evaluation board (a.k.a. TivaC LaunchPad) with Cortex-M4 MCU. However, the general demonstrated principles apply to most modern microcontrollers.
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
@subsection arm-cm_low_power_behave Behavior
|
||||
The the low-power example illustrates the use of two clock tick rates to toggle the LEDs available on the EK-TM4C123GXL board. After the application code is loaded to the board, the **Green-LED** starts blinking once per two seconds (a second on and a second off), while the **Red-LED** lights up and stays on. If no buttons on the board are pressed, the **Green-LED** stops blinking after 4 times. The **Red-LED** shows the **idle** condition, where the system is in a sleep mode.
|
||||
|
||||
When your press the **SW1-Button**, the **Green-LED** starts blinking as before, but additionally, the **Blue-LED** starts blinking rapidly for 13 times (1/10 of a second on and 1/10 off).
|
||||
|
||||
So, depending when the SW1 switch is pressed, you can have only **Green-LED** blinking, or both green and blue blinking at different rates. The **Red-LED** appears to be on all the time.
|
||||
|
||||
@note
|
||||
Actually, the **Red-LED** is also turned off for very brief moments, but this is imperceptible to the human eye. Instead, the **Red-LED** appears to be on all the time, which corresponds to the application being mostly idle.
|
||||
|
||||
|
||||
The behavior just described is designed for the slow human interaction with the application. However, for more precise measurements with a logic analyzer, it is more convenient to speed up the application by factor of 100. This speed up can be achieved by editing the `bsp.h` header file:
|
||||
|
||||
@code{.c}
|
||||
/* The following ticks-per-second constants determine the speed of the app.
|
||||
* The default (#if 1) is the SLOW speed for humans to see the blinking.
|
||||
* Change the #if 1 into #if 0 for FAST speed appropriate for logic analyzers.
|
||||
*/
|
||||
#if 0
|
||||
#define BSP_TICKS0_PER_SEC 2U
|
||||
#define BSP_TICKS1_PER_SEC 20U
|
||||
#else
|
||||
#define BSP_TICKS0_PER_SEC 200U
|
||||
#define BSP_TICKS1_PER_SEC 2000U
|
||||
#endif
|
||||
|
||||
. . .
|
||||
@endcode
|
||||
|
||||
The following logic analyzer trace shows the behavior of the low-power application at the faster time scale. The explanation section immediately following the tarce explains the most interesting points:
|
||||
|
||||
|
||||
|
||||
<dl class="tag">
|
||||
<dt>0</dt><dd>
|
||||
The plot shows the logic-analyzer traces of the following signals (from the top): **SW1** button (active low), **Blinky1** (Blue-LED), **Blinky0** (Green-LED) and **Idle** (Red-LED). The Idle callback turns the **Red-LED** on when the system enters the low-power sleep mode and it turns the **Red-LED** off when the system is active.
|
||||
</dd>
|
||||
<dt>1</dt><dd>
|
||||
At this time the **SW1** button is depressed, which triggers an interrupt that activates both the slow and the fast clock tick rates. The clock tick interrupts trigger toggling of the **Blinky0** (Green-LED) at the slower tick rate-0 and **Blinky1** (Blue-LED) at the faster tick rate-1.
|
||||
</dd>
|
||||
<dt>2</dt><dd>
|
||||
The **Blinky1** (Blue-LED) stops toggling after 13 cycles. At this point also the **Idle** callback turns the **fast tick rate-1** off.
|
||||
</dd>
|
||||
<dt>3</dt><dd>
|
||||
The **Blinky0** (Green-LED) stops toggling after 4 cycles.
|
||||
</dd>
|
||||
<dt>4</dt><dd>
|
||||
The **Idle** callback turns the **slow tick rate-0** off. The system enters the low-power sleep mode without any clock ticks running and remains in this state until the **SW1** button is pressed again.
|
||||
</dd>
|
||||
</dl>
|
||||
<div style="clear:both;"></div>
|
||||
|
||||
@note
|
||||
The **Idle** line (Red-LED) goes down twice as fast as the changes in the state of the **Green-LED** or the **Blue-LED**. This is because the application uses timeouts of **2 clock ticks** for toggling these lines instead of just one clock tick, which then could be slower. This is not quite optimal for the energy dissipation (as the CPU is woken up twice as often as it needs to be), but it illustrates more accurately how the fixed clock rates work as well as the one-tick delay to enter the low-power sleep mode from the idle callback.
|
||||
|
||||
|
||||
@subsection arm-cm_low_power_sm State Machines
|
||||
The versions of this low-power example for the **QK** and **QV** kernels use two active objects **Blinky0** and **Blinky1**, which toggle the **Green-LED** at the slow tick rate 0, and the **Blue-LED** at the fast tick rate 1, respectively. The state machines of the Blinky0 and Blinky1 active objects are shown below:
|
||||
|
||||
|
||||
|
||||
<dl class="tag">
|
||||
<dt>0</dt><dd>
|
||||
The **Blinky0** state machine, in the entry action to the "active" state, calls `BSP_tickRate0_on()` to turn the tick rate-0 on. This is done *before* arming the time event `me->timeEvt0` that uses the clock rate-0.
|
||||
</dd>
|
||||
<dt>1</dt><dd>
|
||||
Similarly, the **Blinky1** state machine, in the entry action to the "active" state, calls `BSP_tickRate1_on()` to turn the tick rate-1 on. This is done *before* arming the time event `me->timeEvt1` that uses the clock rate-1.
|
||||
</dd>
|
||||
</dl>
|
||||
<div style="clear:both;"></div>
|
||||
|
||||
|
||||
@subsection arm-cm_low_power_xt Extended Thread (QXK)
|
||||
The version of this low-power example for the **QXK** kernel uses one active object **Blinky0** (with the state machine shown above), but instead of the Blinky1 active object, the QXK version uses an eXtended thread (::QXThread) called **XBlinky1**, with the code shown below:
|
||||
|
||||
@code{.cpp}
|
||||
#include "qpcpp.hpp"
|
||||
#include "low_power.hpp"
|
||||
#include "bsp.hpp"
|
||||
|
||||
/* local objects -----------------------------------------------------------*/
|
||||
static void XBlinky1_run(QXThread * const me);
|
||||
|
||||
/* global objects ----------------------------------------------------------*/
|
||||
QXThread XT_Blinky1;
|
||||
QXSemaphore XSEM_sw1;
|
||||
|
||||
/*..........................................................................*/
|
||||
void XBlinky1_ctor(void) {
|
||||
QXThread_ctor(&XT_Blinky1,
|
||||
&XBlinky1_run, /* thread routine */
|
||||
1U); /* associate the thread with tick rate-1 */
|
||||
}
|
||||
|
||||
/*..........................................................................*/
|
||||
static void XBlinky1_run(QXThread * const me) {
|
||||
bool isActive = false;
|
||||
|
||||
(void)me; /* unused parameter */
|
||||
for (;;) {
|
||||
if (!isActive) {
|
||||
[0] QXSemaphore_wait(&XSEM_sw1, QXTHREAD_NO_TIMEOUT);
|
||||
isActive = true;
|
||||
}
|
||||
else {
|
||||
uint8_t count;
|
||||
[1] BSP_tickRate1_on();
|
||||
for (count = 13U; count > 0U; --count) {
|
||||
BSP_led1_on();
|
||||
QXThread_delay(1U);
|
||||
BSP_led1_off();
|
||||
QXThread_delay(1U);
|
||||
}
|
||||
isActive = false;
|
||||
}
|
||||
}
|
||||
}
|
||||
@endcode
|
||||
|
||||
<dl class="tag">
|
||||
<dt>0</dt><dd> The **XBlinky1** extended thread emulates the states with the `isActive` flag. When the flag is not set (meaning that the system is not active), the thread waits (and blocks) on the global semaphore `XSEM_sw1`.
|
||||
</dd>
|
||||
<dt>1</dt><dd> After the semaphore is signalled (from the GPIO interrupt in the BSP), the **XBlinky1** extened thread calls `BSP_tickRate1_on()` to turn the tick rate-1 on. This is done *before* later calling QXThread_delay() function, which in case uses the clock rate-1.
|
||||
</dd>
|
||||
</dl>
|
||||
<div style="clear:both;"></div>
|
||||
|
||||
|
||||
@subsection arm-cm_low_power_idle The Idle Callback (QK/QXK)
|
||||
The most important functionality in this low-power example is implemented in the **idle callback** located in the BSP (Board Support Package). The idle callback QK_onIdle() for the preemptive QK kernel and the idle callback QXK_onIdle() for the QXK kernel are almost identical and are explained in this section.
|
||||
|
||||
@code{.cpp}
|
||||
[0] void QXK::onIdle(void) {
|
||||
|
||||
[1] QF_INT_DISABLE();
|
||||
[2] if (((l_activeSet & (1U << SYSTICK_ACTIVE)) != 0U) /* rate-0 enabled? */
|
||||
[3] && QF_noTimeEvtsActiveX(0U)) /* no time events at rate-0? */
|
||||
{
|
||||
/* safe to disable SysTick and interrupt */
|
||||
[4] SysTick->CTRL &= ~(SysTick_CTRL_TICKINT_Msk | SysTick_CTRL_ENABLE_Msk);
|
||||
[5] l_activeSet &= ~(1U << SYSTICK_ACTIVE); /* mark rate-0 as disabled */
|
||||
}
|
||||
[6] if (((l_activeSet & (1U << TIMER0_ACTIVE)) != 0U) /* rate-1 enabled? */
|
||||
[7] && QF_noTimeEvtsActiveX(1U)) /* no time events at rate-1? */
|
||||
{
|
||||
/* safe to disable Timer0 and interrupt */
|
||||
[8] TIMER0->CTL &= ~(1U << 0); /* disable Timer0 */
|
||||
[9] TIMER0->IMR &= ~(1U << 0); /* disable timer interrupt */
|
||||
[10] l_activeSet &= ~(1U << TIMER0_ACTIVE); /* mark rate-1 as disabled */
|
||||
}
|
||||
[11] QF_INT_ENABLE();
|
||||
|
||||
[12] GPIOF->DATA_Bits[LED_RED] = 0xFFU; /* turn LED on, see NOTE2 */
|
||||
[13] __WFI(); // wait for interrupt */
|
||||
[14] GPIOF->DATA_Bits[LED_RED] = 0x00U; /* turn LED off, see NOTE2 */
|
||||
}
|
||||
@endcode
|
||||
|
||||
<dl class="tag">
|
||||
<dt>0</dt><dd> The idle callback for QK and QXK are called from the idle loop with interrupts enabled.
|
||||
</dd>
|
||||
<dt>1</dt><dd> Interrupts are disabled to access the shared bitmask `l_activeSet`, which stores the information about active clock rates and peripherals. This bitmask is shared between the idle callback and the application-level threads.
|
||||
</dd>
|
||||
<dt>2</dt><dd> If the SYSTICK timer is active (source of the tick-0 rate)...
|
||||
</dd>
|
||||
<dt>3</dt><dd> The `QF_noTimeEvtsActiveX(0)` function is called to check whether no time events are active at the clock rate-0.
|
||||
|
||||
> <b>NOTE:</b> The QF_noTimeEvtsActiveX() function is designed to be called from a critical section, which is the case here.
|
||||
|
||||
</dd>
|
||||
<dt>4</dt><dd> If both of these conditions hold, it is safe to turn the clock rate-0 off, which is done here.
|
||||
</dd>
|
||||
<dt>5</dt><dd> The bit indicating that SYSTICK timer is active is cleared in the `l_activeSet` bitmask.
|
||||
</dd>
|
||||
<dt>6</dt><dd> Simliarly, the bit corresponding to TIMER0 is checked in the `l_activeSet` bitmask.
|
||||
</dd>
|
||||
<dt>7</dt><dd> The `QF_noTimeEvtsActiveX(1)` function is called to check whether no time events are active at the clock rate-1.
|
||||
</dd>
|
||||
<dt>8-9</dt><dd> If both of these conditions hold, it is safe to turn the clock rate-1 off, which is done here.
|
||||
</dd>
|
||||
<dt>10</dt><dd> The bit indicating that TIMER0 timer is active is cleared in the `l_activeSet` bitmask.
|
||||
</dd>
|
||||
<dt>11</dt><dd> Interrupts are enabled, so the following code is no logner inside critical section
|
||||
</dd>
|
||||
<dt>12</dt><dd> The **Red-LED** is turned ON right before entering the low-power sleep mode
|
||||
</dd>
|
||||
<dt>13</dt><dd> The `__WFI()` instruction stops the CPU and enters the **low-power sleep mode**
|
||||
</dd>
|
||||
<dt>14</dt><dd> The **Red-LED** is turned off after waking up from the sleep mode
|
||||
</dd>
|
||||
</dl>
|
||||
<div style="clear:both;"></div>
|
||||
|
||||
|
||||
@subsection arm-cm_low_power_idle-qv The Idle Callback (QV)
|
||||
The idle callback QV_onIdle() for the cooperative QV kernel is slightly different, because it is called with interrupts **disabled**. The following listing shows the complete QV_onIdle() callback, with the most important points explained in the section below:
|
||||
|
||||
@code{.cpp}
|
||||
[0] void QV::onIdle(void) { /* NOTE: called with interrupts DISABLED */
|
||||
|
||||
[1] if (((l_activeSet & (1U << SYSTICK_ACTIVE)) != 0U) /* rate-0 enabled? */
|
||||
[2] && QF_noTimeEvtsActiveX(0U)) /* no time events at rate-0? */
|
||||
{
|
||||
/* safe to disable SysTick and interrupt */
|
||||
SysTick->CTRL &= ~(SysTick_CTRL_TICKINT_Msk | SysTick_CTRL_ENABLE_Msk);
|
||||
l_activeSet &= ~(1U << SYSTICK_ACTIVE); /* mark rate-0 as disabled */
|
||||
}
|
||||
if (((l_activeSet & (1U << TIMER0_ACTIVE)) != 0U) /* rate-1 enabled? */
|
||||
&& QF_noTimeEvtsActiveX(1U)) /* no time events at rate-1? */
|
||||
{
|
||||
/* safe to disable Timer0 and interrupt */
|
||||
TIMER0->CTL &= ~(1U << 0); /* disable Timer0 */
|
||||
TIMER0->IMR &= ~(1U << 0); /* disable timer interrupt */
|
||||
l_activeSet &= ~(1U << TIMER0_ACTIVE); /* mark rate-1 as disabled */
|
||||
}
|
||||
|
||||
GPIOF->DATA_Bits[LED_RED] = 0xFFU; /* turn LED on, see NOTE2 */
|
||||
[3] QV_CPU_SLEEP(); /* atomically go to sleep and enable interrupts */
|
||||
GPIOF->DATA_Bits[LED_RED] = 0x00U; /* turn LED off, see NOTE2 */
|
||||
}
|
||||
@endcode
|
||||
|
||||
<dl class="tag">
|
||||
<dt>0</dt><dd> The idle callback for QV is called from the QV event-loop with interrupts **disabled**.
|
||||
</dd>
|
||||
<dt>1</dt><dd> The `l_activeSet` bitmask is tested right away, because interrupts are already disabled
|
||||
</dd>
|
||||
<dt>2</dt><dd> The `QF_noTimeEvtsActiveX(0)` function is called to check whether no time events are active at the clock rate-0.
|
||||
|
||||
> <b>NOTE:</b> The QF_noTimeEvtsActiveX() function is designed to be called from a critical section, which is the case here.
|
||||
|
||||
</dd>
|
||||
<dt>3</dt><dd> The QV_CPU_SLEEP() macro enters **low-power sleep mode** with interrupts still disabled. This port-specific macro is designed to re-anable interrupts **atomically** with entering the sleep mode.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<div style="clear:both;"></div>
|
||||
@nav{tut_game,exa}
|
||||
*/
|
||||
2959
doxygen/history.dox
2959
doxygen/history.dox
File diff suppressed because it is too large
Load Diff
Binary file not shown.
|
Before Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 82 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.2 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 70 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 104 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 55 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 93 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 89 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 111 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 112 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 82 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 127 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 107 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 179 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 136 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 253 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 77 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 59 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 97 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 106 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 115 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 87 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.0 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 6.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 67 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.8 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 94 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 105 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 238 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 255 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 373 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 364 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 79 KiB |
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user