GitHub/qpc
1
0
Fork 0
mirror of https://github.com/QuantumLeaps/qpc.git synced 2025-01-28 07:03:10 +08:00
Code Issues Projects Releases Wiki Activity

7.3.0

Browse Source 
Added QP Functional Safety (FuSa) Subsystem
Memory Isolation with MPU
MISRA-C:2023 compliance
Changed comments from C-style to C++ style
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 2023-01-19 21:13:24 -05:00
parent 009bdb4175
commit 012c5c360e
1897 changed files with 324146 additions and 191680 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@ -39,8 +39,7 @@ JLink*.*
html/ html/
latex/ latex/
cert-pack/ doxygen/gen/
cert-latex/
test_priv/ test_priv/
dbg/ dbg/
rel/ rel/

2
3rd_party

@ -1 +1 @@
Subproject commit fa06969955bfa96cbdb5b9ff8b05b66f49fad890 Subproject commit de077b869b8980d124d9df3e5f7327500e28f178

8
LICENSES/LicenseRef-QL-dual.qlc
View File

@ -1,9 +1,13 @@
Any user of the QP/C real-time embedded framework Any user of the QP/C real-time embedded framework
qpc qpc
2023-12-31 2024-12-31
Copyright (C) 2005 Quantum Leaps, LLC <state-machine.com>. 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 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 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: Contact information:
<www.state-machine.com/licensing> <www.state-machine.com/licensing>
<info@state-machine.com> <info@state-machine.com>
#F04C7A28E6F84BAFDD11A028A9B7CFE2F4DE1FD7 #5B2B82CE252E0FB7975E7196F9141A16DD356860

7
README.md
View File

@ -1,6 +1,9 @@
![QP Framework](doxygen/images/qp_banner.jpg) ![QP Framework](https://www.state-machine.com/img/qp_banner.jpg)
# What's New? # What's New?
[![GitHub release (latest by date)](https://img.shields.io/github/v/release/QuantumLeaps/qpc)](https://github.com/QuantumLeaps/qpc/releases/latest)
View QP/C Revision History at: https://www.state-machine.com/qpc/history.html View QP/C Revision History at: https://www.state-machine.com/qpc/history.html
> **NOTE:** If you're interested in the latest QP/C version from GitHub, > **NOTE:** If you're interested in the latest QP/C version from GitHub,
@ -121,7 +124,7 @@ open the file [html/index.html](html/index.html) in your web browser.
# How to Help this Project? # How to Help this Project?
If you like this project, please give it a star (in the upper-right corner of your browser window): If you like this project, please give it a star (in the upper-right corner of your browser window):
![GitHub star](doxygen/images/github-star.jpg) ![GitHub star](https://www.state-machine.com/img/github-star.jpg)
[RTEF]: <https://www.state-machine.com/rtef> [RTEF]: <https://www.state-machine.com/rtef>

309
doxygen/Doxyfile
View File

@ -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 = QPC
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-c.dox \
../../cert-pack/misra.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.h \
../include \
../src \
../ports/sample \
../ports/lint-plus/std.lnt \
../ports/lint-plus/qpc.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.h
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 = ../qpc.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 = QPC
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 = *.h
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

12
doxygen/Doxyfile-CHM
View File

@ -1,12 +0,0 @@
# Doxyfile 1.9.5
@INCLUDE = Doxyfile
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

43
doxygen/Doxyfile-LATEX
View File

@ -1,43 +0,0 @@
# Doxyfile 1.9.5
@INCLUDE = Doxyfile
#---------------------------------------------------------------------------
# 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-c.dox \
../../cert-pack/misra.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 \
dir.dox \
config.h \
../include \
../src \
../ports/lint-plus/std.lnt \
../ports/lint-plus/qpc.lnt \
../ports/lint-plus/options.lnt
GENERATE_LATEX = YES
ENABLED_SECTIONS += LATEX
# no source code in latex
SOURCE_BROWSER = NO
VERBATIM_HEADERS = NO

245
doxygen/api.dox
View File

@ -1,245 +0,0 @@
/*! @page api API Reference
@ifnot LATEX
@nav_next{deprecated}
@endif
@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_ctor()
- QHSM_INIT()
- QHSM_DISPATCH()
- QHsm_isIn()
- QHsm_state()
- QHsm_top()
- ::QMsm class
- QMsm_ctor()
- 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_ctor()
- QACTIVE_START()
- QACTIVE_POST()
- QACTIVE_POST_X()
- QACTIVE_POST_LIFO()
- QActive_defer()
- QActive_recall()
- QActive_flushDeferred()
- QActive_stop()
- ::QMActive class
- QMActive_ctor()
@subsection api_qf_ps Publish-Subscribe
- ::QSubscrList (Subscriber List struct)
- QF_psInit()
- QF_PUBLISH()
- QActive_subscribe()
- QActive_unsubscribe()
- QActive_unsubscribeAll()
@subsection api_qf_evt Event Management
- ::QEvt class
- QF_poolInit()
- Q_NEW()
- Q_NEW_X()
- Q_NEW_REF()
- Q_DELETE_REF()
- QF_gc()
- Q_EVT_CAST()
@subsection api_qf_time Time Events
- ::QTimeEvt class
- QF_TICK_X()
- QTimeEvt_ctorX()
- QTimeEvt_armX()
- QTimeEvt_disarm()
- QTimeEvt_rearm()
- QTimeEvt_currCtr()
- ::QTicker active object
@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 (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_RX_PUT()
- 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()
- QS_ENUM_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_STR()
- QS_MEM()
- QS_ENUM()
@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 RTC Kernel)
QK is a tiny **preemptive**, run-to-completion (RTC) 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 (Dual-Mode Kernel)
QXK is a small, preemptive, priority-based, dual-mode (run-to-completion/<b>blocking</b>) kernel that executes active objects like the @ref srs_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_ctor()
- QXTHREAD_START()
- QXTHREAD_POST_X()
- Q_XTHREAD_CAST()
- QXThread_delay()
- QXThread_delayCancel()
- QXThread_queueGet()
- 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_X() - posting messages to blocking threads
- QACTIVE_POST_X() - posting events to Active Objects
- QXThread_queueGet() - waiting (blocking) on message queue
@subsection api_qxk_mem Memory Pools
- ::QMPool class
- QMPool_init()
- QMPool_get()
- QMPool_put()
@ifnot LATEX
@nav_next{deprecated}
@endif
*/
##############################################################################
/*! @page deprecated Deprecated APIs
**The following QP/C APIs are now deprecated:**
*/

65
doxygen/config.h
View File

@ -1,65 +0,0 @@
/**
* @file
* @brief Various macros for configuring QP/C (typically used as
* command-line options)
*/
/*! 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 The notable exceptions are the macros #Q_ALLEGE and
* #Q_ALLEGE_ID, that still evaluate the test condition, but do 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 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
/*! The preprocessor switch to activate the QUTest unit testing
* instrumentation in the code
*
* @note
* This macro requires that #Q_SPY be defined as well.
*/
#define Q_UTEST
/*! The preprocessor switch to enable constructor in the ::QEvt class
* instrumentation in the code
*
* @tr{RQP005}
*/
#define Q_EVT_CTOR
/*! This macro enables calling the context-switch callback
* QF_onContextSw() in all build-in kernels (QV, QK, QXK)
*/
#define QF_ON_CONTEXT_SW
/*! Macro defined only for the internal QP implementation. It should
* be not defined for the application-level code
*/
#define QP_IMPL

48
doxygen/dir.dox
View File

@ -1,48 +0,0 @@
/*##########################################################################*/
/*! @dir include
@brief Platform-independent QP&trade;/C API
@attention
The QP&trade;/C <span class="img folder">include</span> directory needs to be added to the compiler's include path in the applications using QP&trade;/C.
*/
/*##########################################################################*/
/*! @dir src
@brief Platform-independent QP&trade;/C source code
Files from this directory need to be added to the project, to build the QP&trade;/C framework from source code.
@attention
The QP&trade;/C <span class="img folder">src</span> directory needs to be added to the compiler's include path in the applications that build QP&trade;/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).
*/

425
doxygen/exa.dox
View File

@ -1,425 +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> &mdash; 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> &mdash; 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> &mdash; 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:
<br>
@code{.c}
qpc/ // QP/C installation directory
+---examples/ // examples directory (applications)
| |
| [1]--arm-cm/ // examples for ARM Cortex-M
| | +---dpp_ek-tm4c123gxl/ // DPP example on the EK-TM4C123GLX board
| | | +---qk/ // version for preemptive QK kernel
| | | | +---armclang/ // build with ARM-Clang (Compiler Version 6) toolchain
| | | | | +---dbg/ // debug build configuration
| | | | | +---rel/ // release build configuration
| | | | | +---spy/ // spy build configuration (QP/Spy tracing enabled)
| | | | +---gnu/ // build with GNU-ARM toolchain
| | | | +---iar/ // build with IAR toolchain
| | | | ~ ~ ~ // source files independent from the toolchain
| | | +---qv/ // version for cooperative QV kernel
| | | \---qxk/ // version for dual-mode QXK kernel
| |
| [2]--freertos/ // examples for FreeRTOS (3rd-party RTOS)
| | +---arm-cm/ // examples for ARM Cortex-M
| | | +---dpp_ek-tm4c123gxl/ // DPP example on the EK-TM4C123GLX board
| | | | +---gnu/ // build with GNU-ARM toolchain
| |
| [3]--lwip/ // examples for lwIP (3rd-party middleware)
| | +---arm-cm/ // examples for ARM Cortex-M
| | | +---qk/ // version for preemptive QK kernel
| | | +---qv/ // version for cooperative QV kernel
| | | \---qxk/ // version for dual-mode QXK kernel
| |
| [4]--qutest/ // examples for QUTest unit testing harness
| | +---blinky/ // simple Blinky example
| | | +---src/ // source code under test
| | | | blinky.h // header file
| | | | blinky.c // source file
| | | +---test/ // code for unit testing
| | | | Makefile // makefile for testing on the host
| | | | make_nucleo-l053r8 // makefile for testing on NUCLEO board
| | | | make_tm4c123 // makefile for testing on NUCLEO board
| | | | test_blinky.c // test fixture
| | | | test_blinky.py // test script
| |
| [5]--workstation/ // examples for workstations (Windows, Linux, macOS)
| | +---blinky/ // simple Blinky example
| | +---calc/ // calculator example
| | +---comp/ // "Orthogonal Component" example
| | +--- ~ ~ ~ // other examples from the PSiCC2 book
@endcode
`[1]` @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.
`[2]` @subpage exa_rtos "Examples for 3rd-party RTOS"
are located in sub-directories named after the RTOS/OS, such as <span class="img folder">freertos</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.
`[3]` @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.
`[4]` @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>
`[5]` @subpage exa_os "Examples for Workstations"
General-Purpose OS (GPOS) 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>
@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 "example applications", which are described on the @ref gs_tut "QP&trade;/C Tutorial":
- @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** &mdash; 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** &mdash; 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** &mdash; 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/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/ )
@ifnot LATEX
@nav_next{exa_ref}
@endif
*/
/*##########################################################################*/
/*! @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> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="NUCLEO-L053R8"></a> &nbsp; (Cortex-M0+)
- @ref arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="NUCLEO-L152RE"></a> &nbsp; (Cortex-M3)
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> &nbsp; (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> &nbsp; (Cortex-M0+)
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_nucleo-h743zi <a class="preview board" href="bd_NUCLEO-H743ZI.jpg" title="NUCLEO-H743ZI"></a> &nbsp; (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> &nbsp; (Cortex-M4)
- @ref arm-cm_blinky_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="NUCLEO-L053R8"></a> &nbsp; (Cortex-M0+)
- @ref arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="NUCLEO-L152RE"></a> &nbsp; (Cortex-M3)
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> &nbsp; (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> &nbsp; (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> &nbsp; (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> &nbsp; (Cortex-M4)
- @ref arm-cm_blinky_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_ek-tm4c123gxl <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_mbed-lpc1768 <a class="preview board" href="bd_mbed-LPC1768.jpg" title="mbed-LPC1768"></a> &nbsp; (Cortex-M4)
- @ref arm-cm_dpp_nucleo-l053r8 <a class="preview board" href="bd_NUCLEO-L053R8.jpg" title="NUCLEO-L053R8"></a> &nbsp; (Cortex-M0+)
- @ref arm-cm_dpp_nucleo-l152re <a class="preview board" href="bd_NUCLEO-L152RE.jpg" title="NUCLEO-L152RE"></a> &nbsp; (Cortex-M3)
- @ref arm-cm_game_efm32-slstk3401a <a class="preview board" href="bd_EFM32-SLSTK3401A.jpg" title="EFM32-SLSTK3401A"></a> &nbsp; (Cortex-M4)
- @ref arm-cr_blinky_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a> &nbsp; (Cortex-R4)
- @ref arm-cr_dpp_launchxl2-tms57012 <a class="preview board" href="bd_LAUNCHXL2-TMS57012.jpg" title="LAUNCHXL2-TMS57012"></a> &nbsp; (Cortex-R4)
- @ref lwip_ek-lm3s6965 <a class="preview board" href="bd_EK-LM3S6965.jpg" title="EK-LM3S6965"></a> &nbsp; (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" &mdash; single-threaded examples for POSIX-QV (Linux, MacOS)
- @ref exa_os "POSIX" &mdash; multi-threaded examples for POSIX (Linux, MacOS, QNX, etc.)
- @ref exa_os "Windows-QV" &mdash; single-threaded examples for Windows
- @ref exa_os "Windows" &mdash; 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>&nbsp;&nbsp; icon in the list below to see the picture of the board.
@subsection exa_ref_arm-cm ARM Cortex-M Boards
@anchor EK-TM4C123GXL
@image html bd_EK-TM4C123GXL.jpg
@image latex bd_EK-TM4C123GXL.jpg width=2.5in
@caption{EK-TM4C123GXL (TivaC LaunchPad)}
- @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
@image html bd_EFM32-SLSTK3401A.jpg
@image latex bd_EFM32-SLSTK3401A.jpg width=4.5in
@caption{EFM32-SLSTK3401A (Pearl-Gecko)}
- @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
@image html bd_mbed-LPC1768.jpg
@image latex bd_mbed-LPC1768.jpg width=2.5in
@caption{mbed-LPC1768}
- @ref arm-cm_dpp_mbed-lpc1768 (QV, QK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
@anchor NUCLEO-L053R8
@image html bd_NUCLEO-L053R8.jpg
@image latex bd_NUCLEO-L053R8.jpg width=2.5in
@caption{NUCLEO-L053R8}
- @ref arm-cm_dpp_nucleo-l053r8 (QV, QK, QXK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
@anchor NUCLEO-L152RE
@image html bd_NUCLEO-L152RE.jpg
@image latex bd_NUCLEO-L152RE.jpg width=2.4in
@caption{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 EK-LM3S6965
@image html bd_EK-LM3S6965.jpg
@image latex bd_EK-LM3S6965.jpg width=2.0in
@caption{EK-LM3S6965}
- @ref lwip_ek-lm3s6965 (**LwIP TCP/IP**; QV, QK kernels; ARM-KEIL, GNU-ARM, IAR-EWARM toolchains)
@anchor NUCLEO-H743ZI
@image html bd_NUCLEO-H743ZI.jpg
@image latex bd_NUCLEO-H743ZI.jpg width=4.5in
@caption{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
@image html bd_STM32F4-Disco.jpg
@image latex bd_STM32F4-Disco.jpg width=2.8in
@caption{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
@image html bd_STM32F746G-Disco.jpg
@image latex bd_STM32F746G-Disco.jpg width=4.75in
@caption{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
@image html bd_LAUNCHXL2-TMS57012.jpg
@image latex bd_LAUNCHXL2-TMS57012.jpg width=4.0in
@caption{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
@image html bd_MSP-EXP430F5529LP.jpg
@image latex bd_MSP-EXP430F5529LP.jpg width=3.5in
@caption{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>
@ifnot LATEX
@nav_next{exa_native}
@endif
*/

52
doxygen/exa_mware.dox
View File

@ -1,52 +0,0 @@
/*! @page exa_mware Examples for Third-Party Middleware
- @subpage exa_lwip
- @subpage exa_emwin
*/
/*##########################################################################*/
/*! @page exa_lwip lwIP TCP/IP
- @subpage lwip_ek-lm3s6965
*/
/*##########################################################################*/
/*! @page lwip_ek-lm3s6965 lwIP on EK-LM3S6965
@image html bd_EK-LM3S6965.jpg
@image latex bd_EK-LM3S6965.jpg width=2.0in
@caption{EK-LM3S6965}
lwIP example for Texas Instruments EK-LM3S6965 (Cortex-M3) with GNU-ARM and IAR-ARM toolsets.
@image html bd_EK-LM3S6965_lwip.jpg
@image latex bd_EK-LM3S6965_lwip.jpg width=2.0in
@caption{QP-lwIP on EK-LM3S6965}
<br>
@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.
@image html AN-QL.png
@image latex AN-QL.png width=2in
@caption{Application Note: QP and lwIP TCP/IP}
@ifnot LATEX
@nav_next{exa_emwin}
@endif
*/
/*##########################################################################*/
/*! @page exa_emwin emWin Embedded GUI
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&trade; with the <a href="https://www.segger.com/emwin.html" target="_blank" class="extern">emWin&trade; Embedded GUI from SEGGER</a> and also <a href="https://www.micrium.com/rtos/gui/" target="_blank" class="extern">&micro;C/GUI from Micrium</a>, which technically are the same products.
@image html emWin_demo.jpg
@image latex emWin_demo.jpg width=4.0in
@caption{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 (&micro;C/GUI) integration runs on Windows, the application-level code uses exclusively the embedded emWin&trade; API and is designed to run without any modifications on embedded targets.
*/

680
doxygen/exa_native.dox
View File

@ -1,680 +0,0 @@
/*##########################################################################*/
/*! @page exa_native Native Examples (Built-in Kernels)
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:
- @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_arm7-9
- @subpage exa_msp430
*/
/*##########################################################################*/
/*! @page exa_qv QV Kernel (Non-Preemptive, Priority-Based, Non-Blocking)
@ifnot LATEX
@remark
You can hover the mouse cursor over the <span class="board"></span>&nbsp;&nbsp; icon in the list below to see the picture of the board.
@endif
- @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)
@ifnot LATEX
@remark
You can hover the mouse cursor over the <span class="board"></span>&nbsp;&nbsp; icon in the list below to see the picture of the board.
@endif
- @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)
@ifnot LATEX
@remark
You can hover the mouse cursor over the <span class="board"></span>&nbsp;&nbsp; icon in the list below to see the picture of the board.
@endif
- @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)
@ifnot LATEX
@remark
You can hover the mouse cursor over the <span class="board"></span>&nbsp;&nbsp; icon in the list below to see the picture of the board.
@endif
- @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_low <a class="preview board" href="bd_EK-TM4C123GXL.jpg" title="EK-TM4C123GXL"></a>
*/
/*##########################################################################*/
/*! @page exa_arm-cr ARM Cortex-R
@ifnot LATEX
@remark
You can hover the mouse cursor over the <span class="board"></span>&nbsp;&nbsp; icon in the list below to see the picture of the board.
@endif
- @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)
@ifnot LATEX
@remark
You can hover the mouse cursor over the <span class="board"></span>&nbsp;&nbsp; icon in the list below to see the picture of the board.
@endif
- @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
This example implements the @ref blinky "Blinky sample application" on the EK-TM4C123GLX board (ARM Cortex-M4F).
@image html bd_EK-TM4C123GXL.jpg
@image latex bd_EK-TM4C123GXL.jpg width=2.5in
@caption{EK-TM4C123GXL (TivaC LaunchPad)}
The Blinky example is located in the directory <span class="img folder">qpc/examples/arm-cm/blinky_ek-tm4c123gxl</span>, which is organized as follows:
<br>
@code{.c}
qpc/ // 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.c // 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.c // BSP for the QV kernel
@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 bd_EK-TM4C123GXL.jpg
@image latex bd_EK-TM4C123GXL.jpg width=2.5in
@caption{EK-TM4C123GXL (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
@image latex blinky_win32.png width=4.5in
@caption{Blinky emulation running in a Windows console}
@ifnot LATEX
@nav_next{arm-cm_blinky_efm32-slstk3401a}
@endif
*/
/*##########################################################################*/
/*! @page arm-cm_blinky_efm32-slstk3401a Blinky on EFM32-SLSTK3401A
This example implements the @ref blinky "Blinky sample application" on the EFM32-SLSTK3401A board (ARM Cortex-M4F).
@image html bd_EFM32-SLSTK3401A.jpg
@image latex bd_EFM32-SLSTK3401A.jpg width=4.5in
@caption{EFM32-SLSTK3401A (Pearl-Gecko)}
The Blinky example is located in the directory <span class="img folder">qpc/examples/arm-cm/blinky_efm32-slstk3401a</span>, which is organized as follows:
@code{c}
qpc/ // 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.c // 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.c // BSP for the QV kernel
| | | +-win32/ // Windows emulation (multithreaded)
| | | | +-Makefile // Makefile for building the project with MinGW
| | | | +-bsp.c // BSP for the Win32
| | | +-win32-qv/ // Windows emulation (single thread)
| | | | +-Makefile // Makefile for building the project with MinGW
| | | | +-bsp.c // 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
@image latex blinky_win32.png width=4.5in
@caption{Blinky emulation running in a Windows console}
@ifnot LATEX
@nav_next{arm-cm_dpp_ek-tm4c123gxl}
@endif
*/
/*##########################################################################*/
/*! @page arm-cm_dpp_ek-tm4c123gxl DPP on EK-TM4C123GXL
This example implements the @ref dpp "Dining Philosophers Problem" sample application on the EK-TM4C123GLX board (ARM Cortex-M4F).
@image html bd_EK-TM4C123GXL.jpg
@image latex bd_EK-TM4C123GXL.jpg width=2.5in
@caption{EK-TM4C123GXL (TivaC LaunchPad)}
The DPP example is located in the directory <span class="img folder">qpc/examples/arm-cm/dpp_ek-tm4c123gxl</span>, which is organized as follows:
<br>
@code{.c}
qpc/ // 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/ // PC-Lint 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
| | | | +-ti/ // TI-ARM toolchain (CCS)
| | | | | +-.ccsproject // CCS project
| | | | | +-.cproject // C Eclipse project
| | | | | +-.project // Eclipse project
| | | | +-bsp.c // BSP for the QK kernel
| | | | +-main.c // 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.c // BSP for the QV kernel
| | | | +-main.c // 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.c // BSP for the QXK kernel
| | | | +-main.c // main() for the QXK kernel
| | | | +-test.c // 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
@image latex bd_EFM32-SLSTK3401A.jpg width=4.5in
@caption{EFM32-SLSTK3401A (Pearl-Gecko)}
The DPP example is located in the directory <span class="img folder">qpc/examples/arm-cm/dpp_efm32-slstk3401a</span> and includes versions for @ref srs_qv "cooperative QV kernel", the @ref srs_qk "preemptive QK kernel", and the @ref srs_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:
<br>
@code{.c}
qpc/ // 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/ // PC-Lint 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.c // BSP for the QK kernel
| | | | +-main.c // 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.c // BSP for the QV kernel
| | | | +-main.c // 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
| | | | +-bsp.c // BSP for the QXK kernel
| | | | +-main.c // main() for the QXK kernel
| | | | +-test.c // 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
@image latex bd_mbed-LPC1768.jpg width=2.5in
@caption{mbed-LPC1768}
Dining Philosophers Problem (DPP) example for NXP LPC1768 MCU (Cortex-M3) with GNU-ARM toolchain.
@image html mbed-LPC1768_button.jpg
@image latex mbed-LPC1768_button.jpg width=3.0in
@captionAdding External Button to mbed-LPC1768{}
@image html under-constr.png
@image latex under-constr.png width=1in
*/
/*##########################################################################*/
/*! @page arm-cm_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}
@ref dpp "Dining Philosophers Problem (DPP)" example for STM32 NUCLEO-L053R8 MCU (Cortex-M0+).
Demonstrated built-in kernels:
- cooperative @ref srs_qv with ARM-Clang, ARM-Keil, GNU-ARM (Makefile and Atollic TRUEstudio), and IAR-ARM toolchains
- preemptive, run-to-completion @ref srs_qk with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
- dual-mode (run-to-completion/blocking) @ref srs_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
@image latex bd_NUCLEO-L152RE.jpg width=2.4in
@caption{NUCLEO-L152RE}
@ref dpp "Dining Philosophers Problem (DPP)" example for STM32 NUCLEO-L152RE MCU (Cortex-M3).
Demonstrated built-in kernels:
- cooperative @ref srs_qv with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
- preemptive, run-to-completion @ref srs_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>.
@image html bd_STM32F4-Disco.jpg
@image latex bd_STM32F4-Disco.jpg width=2.8in
@caption{STM32F4-Discovery}
Demonstrated built-in kernels:
- cooperative @ref srs_qv with ARM-Keil, GNU-ARM, and IAR-ARM toolchains
- preemptive, run-to-completion @ref srs_qk with ARM-Keil, GNU-ARM, and IAR-ARM toolchains
- dual-mode (run-to-completion/blocking) @ref srs_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>
@image html bd_STM32F4-Disco_RS232.jpg
@image latex bd_STM32F4-Disco_RS232.jpg width=3.5in
@caption{STM32F4-Discovery board connected to RS232 level shifter}
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{arm-cm_dpp_nucleo-l552ze}
@endif
*/
/*##########################################################################*/
/*! @page arm-cm_dpp_nucleo-h743zi DPP on STM32 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 STM32 NUCLEO-H743ZI MCU (Cortex-M7).
Demonstrated built-in kernels:
- cooperative @ref srs_qv with ARM-Clang, ARM-Keil, GNU-ARM (Makefile and Atollic TRUEstudio), and IAR-ARM toolchains
- preemptive, run-to-completion @ref srs_qk with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
- dual-mode (run-to-completion/blocking) @ref srs_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 NUCLEO-L552ZE Q
@image html bd_NUCLEO-L552ZE.jpg
@image latex bd_NUCLEO-L552ZE.jpg width=3.5in
@caption{STM32 NUCLEO-L552ZE Q}
@ref dpp "Dining Philosophers Problem (DPP)" example for STM32 NUCLEO-L552ZE Q (Cortex-M33).
Demonstrated built-in kernels:
- cooperative @ref srs_qv with ARM-Clang, ARM-Keil, GNU-ARM (Makefile and Atollic TRUEstudio), and IAR-ARM toolchains
- preemptive, run-to-completion @ref srs_qk with ARM-Clang, ARM-Keil, GNU-ARM, and IAR-ARM toolchains
- dual-mode (run-to-completion/blocking) @ref srs_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
@image latex bd_EFM32-SLSTK3401A.jpg width=4.5in
@caption{EFM32-SLSTK3401A (Pearl-Gecko)}
"Fly 'n' Shoot" game example for Silicon Labs Pearl Gecko MCU (Cortex-M4F), ARM (MDK-ARM), GNU-ARM, IAR EWARM toolchains.
@image html qwin_ani.gif "Fly 'n' Shoot game running on Windows"
@image latex qwin_static.jpg "Fly 'n' Shoot game running on Windows"
@image html under-constr.png
@image latex under-constr.png width=0.93in
*/
/*##########################################################################*/
/*! @page arm-cr_blinky_launchxl2-tms57012 Blinky on LAUNCHXL2-TMS57012
@image html bd_LAUNCHXL2-TMS57012.jpg
@image latex bd_LAUNCHXL2-TMS57012.jpg width=4.0in
@caption{LAUNCHXL2-TMS57012}
@ref blinky "Blinky" example for LAUNCHXL2-TMS57012 MCU (Cortex-R, Hercules) with IAR-ARM and TI toolchains.
@image html under-constr.png
@image latex under-constr.png width=0.93in
*/
/*##########################################################################*/
/*! @page arm-cr_dpp_launchxl2-tms57012 DPP on LAUNCHXL2-TMS57012
@image html bd_LAUNCHXL2-TMS57012.jpg
@image latex bd_LAUNCHXL2-TMS57012.jpg width=4.0in
@caption{LAUNCHXL2-TMS57012}
Dining Philosophers Problem (DPP) example for LAUNCHXL2-TMS57012 MCU (Cortex-R, Hercules) with IAR-ARM and TI toolchains.
@image html under-constr.png
@image latex under-constr.png width=0.93in
*/
/*##########################################################################*/
/*! @page msp430_blinky_msp-exp430f5529lp Blinky on MSP-EXP430F5529LP
@image html bd_MSP-EXP430F5529LP.jpg
@image latex bd_MSP-EXP430F5529LP.jpg width=2.5in
@caption{MSP-EXP430F5529LP}
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
@image latex bd_MSP-EXP430F5529LP.jpg width=2.5in
@caption{MSP-EXP430F5529LP}
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 -c <COM#> -O2 -F2 -E1 -P1 -B1
@endverbatim
where `<COM#>` denotes the Virtual COM port, which you can find out in the Device Manager.
*/

142
doxygen/exa_os.dox
View File

@ -1,142 +0,0 @@
/*! @page exa_os Examples for Workstations (Windows/POSIX)
<p>The examples in the <span class="img folder">qpc/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> &mdash; Simple "Blinky" active object (command-line)
- <span class="img folder">calc</span> &mdash; Calculator example from Chapter 2 of [PSiCC2](https://www.state-machine.com/psicc2)
- <span class="img folder">calc1</span> &mdash; Improved Calculator example from Chapter 2 of [PSiCC2](https://www.state-machine.com/psicc2)
- <span class="img folder">calc1_sub</span> &mdash; Calculator example with sub-machines
- <span class="img folder">comp</span> &mdash; Orthogonal Component design pattern
- <span class="img folder">defer</span> &mdash; Deferred Event design pattern
- <span class="img folder">dpp</span> &mdash; DPP application from Chapter 9 of [PSiCC2](https://www.state-machine.com/psicc2) (**Spy**)
- <span class="img folder">dpp_comp</span> &mdash; DPP with Orthogonal-Component pattern (**Spy**)
- <span class="img folder">dpp-gui</span> &mdash; DPP (with GUI on Windows) (**Spy**)
- <span class="img folder">game-gui</span> &mdash; "Fly 'n' Shoot" game from Chapter 1 of [PSiCC2](https://www.state-machine.com/psicc2) (**Spy**)
- <span class="img folder">history_qhsm</span> &mdash; Transition-to-History (with ::QHsm class)
- <span class="img folder">history_qmsm</span> &mdash; Transition-to-History (with ::QMsm class)
- <span class="img folder">qhsmtst</span> &mdash; Test State Machine based on ::QHsm from Chapter 2 of [PSiCC2](https://www.state-machine.com/psicc2) (**Spy**)
- <span class="img folder">qmsmtst</span> &mdash; Test State Machine based on ::QMsm (**Spy**)
- <span class="img folder">reminder</span> &mdash; Reminder design pattern from Chapter 5 of PSiCC2
- <span class="img folder">reminder2</span> &mdash; 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">qpc/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 &mdash; @ref win32 "win32" or @ref win32-qv "win32-qv"; and
- On POSIX &mdash; @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.
@image html blinky_win32.png
@image latex blinky_win32.png width=4.0in
@caption{Blinky example on Windows}
<br>
@image html blinky_posix.png
@image latex blinky_posix.png width=4.0in
@caption{Blinky example on Linux}
@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:
<br>
@verbatim
QP_PORT_DIR := $(QPC)/ports/win32-qv
#QP_PORT_DIR := $(QPC)/ports/win32
@endverbatim
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:
<br>
@verbatim
make
@endverbatim
To clean this build, type
@verbatim
make clean
@endverbatim
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:
@verbatim
make CONF=rel
@endverbatim
To clean this build, type
@verbatim
make CONF=rel clean
@endverbatim
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:
@verbatim
make CONF=spy
@endverbatim
To clean this build, type
@verbatim
make CONF=spy clean
@endverbatim
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.
@image html dpp_win.png
@image latex dpp_win.png width=5.0in
@caption{DPP with QSPY example on Windows (QSPY running in a separate command-prompt)}
<br>
@image html dpp_posix.png
@image latex dpp_posix.png width=6.0in
@caption{DPP with QSPY example on Linux (QSPY running in a separate command-prompt)}
@ifnot LATEX
@nav_next{exa_mware}
@endif
*/

140
doxygen/exa_qutest.dox
View File

@ -1,140 +0,0 @@
/*! @page exa_qutest Examples for QUTest Unit Testing Harness
<p>The examples in the <span class="img folder">qpc/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> &mdash; Simple "Blinky" single-active-object application
- <span class="img folder">dpp</span> &mdash; DPP application from Chapter 9 of PSiCC2
- <span class="img folder">evt-par</span> &mdash; testing events with parameters
- <span class="img folder">qhsmtst</span> &mdash; Test State Machine based on ::QHsm with QM model
- <span class="img folder">qmsmtst</span> &mdash; Test State Machine based on ::QMsm with QM model
- <span class="img folder">unity_basic</span> &mdash; Comparison of a basic testing with Unity and QUTest
- <span class="img folder">unity_mock</span> &mdash; 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> &mdash; Examples for QUTest unit testing harness
</li>
<ul class="tag">
<li><span class="img folder">dpp/</span> &mdash; The simple Blinky example
</li>
<ul class="tag">
<li><span class="img folder">src/</span> &mdash; source code under test &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span class="tag">A</span>
</li>
<ul class="tag">
<li><span class="img file_h">bsp.h</span> &mdash; BSP header
</li>
<li><span class="img file_h">dpp.h</span> &mdash; DPP header
</li>
<li><span class="img file_qm">dpp.qm</span> &mdash; DPP model
</li>
<li><span class="img file_c">philo.c</span> &mdash; `Philo` active object
</li>
<li><span class="img file_c">table.c</span> &mdash; `Table` active object
</li>
</ul>
</ul>
<ul class="tag">
<li><span class="img folder">test_philo/</span> &mdash; code for unit testing of `Philo` AO &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span class="tag">B</span>
</li>
<ul class="tag">
<li><span class="img file_mak">Makefile</span> &mdash; cross-platform makefile (host)
</li>
<li><span class="img file_c">test_philo.c</span> &mdash; test fixture for `Philo` AO
</li>
<li><span class="img file_py">test_philo.py</span> &mdash; test script for `Philo` (Python)
</li>
</ul>
</ul>
<ul class="tag">
<li><span class="img folder">test_table/</span> &mdash; code for unit testing of `Table` AO &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span class="tag">B</span>
</li>
<ul class="tag">
<li><span class="img file_mak">Makefile</span> &mdash; cross-platform makefile (host)
</li>
<li><span class="img file_c">test_philo.c</span> &mdash; test fixture for `Table` AO
</li>
<li><span class="img file_py">test_philo.py</span> &mdash; test script for `Table` (Python)
</li>
</ul>
</ul>
<ul class="tag">
<li><span class="img folder">test_dpp/</span> &mdash; code for unit testing of DPP application &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span class="tag">C</span>
</li>
<ul class="tag">
<li><span class="img file_mak">Makefile</span> &mdash; cross-platform makefile (host)
</li>
<li><span class="img file_mak">make_efm32</span> &mdash; makefile for the EFM32 **embedded board**
</li>
<li><span class="img file_mak">make_tm4c123</span> &mdash; makefile for the TM4C123 **embedded board**
</li>
<li><span class="img file_c">main.c</span> &mdash; `main()` function for DPP application
</li>
<li><span class="img file_c">test_dpp.c</span> &mdash; test fixture for DPP application
</li>
<li><span class="img file_py">test_init.py</span> &mdash; test script for DPP initialization (Python)
</li>
<li><span class="img file_py">test_tick.py</span> &mdash; test script for DPP tick processing (Python)
</li>
</ul>
</ul>
<li><span class="img folder">~~~/</span> &mdash; Other QUTest examples~~~
</li>
<li><span class="img folder">target_efm32/</span> &mdash; Code for the **embedded target** (EFM32) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span class="tag">D</span>
</li>
<li><span class="img folder">target_tm4c123/</span> &mdash; Code for the **embedded target** (TM4C123) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <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_c">test_*.c</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.c</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:
@image html qutest_py.png
@image latex qutest_py.png width=6.5in
@caption{Testing on the host (Python)}
@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:
@image html qutest_tm4c123_py.png
@image latex qutest_tm4c123_py.png width=6.5in
@caption{Testing on the TM4C123 embedded target (Python)}
@ifnot LATEX
@nav_next{exa_os}
@endif
*/

684
doxygen/exa_rtos.dox
View File

@ -1,684 +0,0 @@
/*##########################################################################*/
/*! @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>&nbsp;&nbsp; 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>&nbsp;&nbsp; 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>&nbsp;&nbsp; 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>&nbsp;&nbsp; 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
<qpc>/examples/zephyr/blinky
|
+-src/ - project sources
| |
| +-bsp.h
| +-bsp.c
| +-blinky.h
| +-blinky.c
| +-main.c
|
+-CMakeLists.txt - project files
+-prj.conf - project config
+-README.md
@endverbatim
@section zephyr_blinky-build Building and Running
- Linux:
@verbatim
[1] cd <qpc>/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
<qpc>/examples/zephyr/dpp
|
+-src/ - project sources
| |
| +-bsp.h
| +-bsp.c
| +-dpp.h
| +-philo.c
| +-table.c
| +-main.c
|
+-CMakeLists.txt - project files
+-prj.conf - project config
+-README.md
@endverbatim
@section zephyr_dpp-build Building and Running
- Linux:
@verbatim
[1] cd <qpc>/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
*/

174
doxygen/gen/metrics.txt
View File

@ -1,174 +0,0 @@
@code{.c}
================================================
NLOC CCN token PARAM length location
------------------------------------------------
3 1 16 1 3 QHsm_state@410-412@..\include\qep.h
3 1 15 1 3 QEQueue_getNFree@306-308@..\include\qequeue.h
3 1 15 1 3 QEQueue_getNMin@323-325@..\include\qequeue.h
3 1 21 1 3 QEQueue_isEmpty@342-344@..\include\qequeue.h
5 2 33 1 8 QPSet_setEmpty@245-252@..\include\qf.h
4 3 44 1 7 QPSet_isEmpty@255-261@..\include\qf.h
4 3 44 1 7 QPSet_notEmpty@264-270@..\include\qf.h
8 3 95 2 11 QPSet_hasElement@273-283@..\include\qf.h
11 3 105 2 14 QPSet_insert@286-299@..\include\qf.h
12 3 117 2 15 QPSet_remove@302-316@..\include\qf.h
6 3 56 1 9 QPSet_findMax@319-327@..\include\qf.h
6 1 20 2 6 QF_psInit@1405-1410@..\include\qf.h
3 1 20 1 3 QEvt_refCtr_inc_@180-182@..\include\qf_pkg.h
3 1 20 1 3 QEvt_refCtr_dec_@189-191@..\include\qf_pkg.h
14 3 67 1 14 QS_rxPut@892-905@..\include\qs.h
7 1 33 3 7 QHsm_reservedEvt_@90-96@..\src\qf\qep_hsm.c
18 3 101 2 24 QHsm_isIn@103-126@..\src\qf\qep_hsm.c
22 4 125 2 31 QHsm_childState@129-159@..\src\qf\qep_hsm.c
12 2 57 2 14 QHsm_ctor@162-175@..\src\qf\qep_hsm.c
7 1 29 2 7 QHsm_top@178-184@..\src\qf\qep_hsm.c
55 10 386 3 82 QHsm_init_@187-268@..\src\qf\qep_hsm.c
101 15 631 3 154 QHsm_dispatch_@271-424@..\src\qf\qep_hsm.c
3 1 16 1 3 QHsm_getStateHandler_@428-430@..\src\qf\qep_hsm.c
91 15 480 3 132 QHsm_tran_@434-565@..\src\qf\qep_hsm.c
14 3 79 3 17 QHsm_state_entry_@568-584@..\src\qf\qep_hsm.c
20 3 96 3 23 QHsm_state_exit_@587-609@..\src\qf\qep_hsm.c
15 3 69 2 16 QMsm_isInState@81-96@..\src\qf\qep_msm.c
3 1 17 1 3 QMsm_stateObj@99-101@..\src\qf\qep_msm.c
31 7 153 2 38 QMsm_childStateObj@104-141@..\src\qf\qep_msm.c
12 2 60 2 15 QMsm_ctor@144-158@..\src\qf\qep_msm.c
27 4 202 3 45 QMsm_init_@161-205@..\src\qf\qep_msm.c
118 19 740 3 169 QMsm_dispatch_@208-376@..\src\qf\qep_msm.c
3 1 18 1 3 QMsm_getStateHandler_@380-382@..\src\qf\qep_msm.c
55 9 317 3 70 QMsm_execTatbl_@386-455@..\src\qf\qep_msm.c
24 4 132 4 33 QMsm_exitToTranSource_@458-490@..\src\qf\qep_msm.c
45 6 243 3 56 QMsm_enterHistory_@493-548@..\src\qf\qep_msm.c
82 14 431 4 122 QActive_post_@70-191@..\src\qf\qf_actq.c
44 7 266 2 66 QActive_postLIFO_@196-261@..\src\qf\qf_actq.c
34 3 233 1 44 QActive_get_@266-309@..\src\qf\qf_actq.c
10 2 60 1 11 QF_getQueueMin@315-325@..\src\qf\qf_actq.c
16 2 79 2 20 QTicker_ctor@344-363@..\src\qf\qf_actq.c
10 1 45 3 11 QTicker_init_@366-376@..\src\qf\qf_actq.c
16 2 90 3 18 QTicker_dispatch_@379-396@..\src\qf\qf_actq.c
30 2 156 4 39 QTicker_post_@399-437@..\src\qf\qf_actq.c
8 1 30 2 9 QTicker_postLIFO_@440-448@..\src\qf\qf_actq.c
15 1 84 3 17 QActive_defer@65-81@..\src\qf\qf_defer.c
34 3 169 2 54 QActive_recall@86-139@..\src\qf\qf_defer.c
13 3 68 2 15 QActive_flushDeferred@144-158@..\src\qf\qf_defer.c
17 3 116 3 26 QF_poolInit@86-111@..\src\qf\qf_dyn.c
3 1 17 1 3 QF_poolGetMaxBlockSize@114-116@..\src\qf\qf_dyn.c
9 3 59 1 12 QF_getPoolMin@119-130@..\src\qf\qf_dyn.c
39 7 234 3 57 QF_newX_@133-189@..\src\qf\qf_dyn.c
30 4 188 1 46 QF_gc@192-237@..\src\qf\qf_dyn.c
20 3 99 2 30 QF_newRef_@240-269@..\src\qf\qf_dyn.c
11 2 67 1 15 QF_deleteRef_@272-286@..\src\qf\qf_dyn.c
32 5 233 4 50 QMPool_init@67-116@..\src\qf\qf_mem.c
45 5 241 3 74 QMPool_get@119-192@..\src\qf\qf_mem.c
19 3 117 3 28 QMPool_put@195-222@..\src\qf\qf_mem.c
8 1 35 2 13 QActive_psInit@73-85@..\src\qf\qf_ps.c
42 6 231 3 75 QActive_publish_@90-164@..\src\qf\qf_ps.c
18 5 111 2 24 QActive_subscribe@169-192@..\src\qf\qf_ps.c
18 5 111 2 27 QActive_unsubscribe@197-223@..\src\qf\qf_ps.c
19 5 130 1 24 QActive_unsubscribeAll@228-251@..\src\qf\qf_ps.c
10 2 46 2 10 QF_bzero@85-94@..\src\qf\qf_qact.c
16 2 72 2 23 QActive_ctor@101-123@..\src\qf\qf_qact.c
28 10 225 1 47 QActive_register_@128-174@..\src\qf\qf_qact.c
10 3 79 1 15 QActive_unregister_@179-193@..\src\qf\qf_qact.c
24 6 143 1 29 QF_LOG2@201-229@..\src\qf\qf_qact.c
14 2 84 3 14 QEQueue_init@67-80@..\src\qf\qf_qeq.c
57 8 301 4 78 QEQueue_post@83-160@..\src\qf\qf_qeq.c
36 5 199 3 48 QEQueue_postLIFO@163-210@..\src\qf\qf_qeq.c
38 4 219 2 50 QEQueue_get@213-262@..\src\qf\qf_qeq.c
16 2 79 2 35 QMActive_ctor@74-108@..\src\qf\qf_qmact.c
15 2 96 4 32 QTimeEvt_ctorX@78-109@..\src\qf\qf_time.c
33 8 225 3 59 QTimeEvt_armX@112-170@..\src\qf\qf_time.c
31 3 173 1 41 QTimeEvt_disarm@173-213@..\src\qf\qf_time.c
36 8 230 2 64 QTimeEvt_rearm@216-279@..\src\qf\qf_time.c
5 1 36 1 5 QTimeEvt_wasDisarmed@282-286@..\src\qf\qf_time.c
7 1 30 1 8 QTimeEvt_currCtr@289-296@..\src\qf\qf_time.c
69 7 380 2 112 QTimeEvt_tick_@299-410@..\src\qf\qf_time.c
14 3 75 1 16 QTimeEvt_noActive@413-428@..\src\qf\qf_time.c
21 2 112 1 31 QK_schedLock@74-104@..\src\qk\qk.c
20 4 118 1 33 QK_schedUnlock@107-139@..\src\qk\qk.c
11 3 101 1 23 QF_init@144-166@..\src\qk\qk.c
3 1 10 1 4 QF_stop@169-172@..\src\qk\qk.c
18 6 76 1 33 QF_run@175-207@..\src\qk\qk.c
25 3 156 7 34 QActive_start_@214-247@..\src\qk\qk.c
19 4 78 1 24 QK_sched_@252-275@..\src\qk\qk.c
66 17 382 1 113 QK_activate_@278-390@..\src\qk\qk.c
7 3 52 1 13 QF_init@73-85@..\src\qv\qv.c
3 1 10 1 4 QF_stop@88-91@..\src\qv\qv.c
46 15 251 1 97 QF_run@94-190@..\src\qv\qv.c
18 1 124 7 25 QActive_start_@197-221@..\src\qv\qv.c
23 3 131 1 34 QXK_schedLock@71-104@..\src\qxk\qxk.c
20 4 118 1 33 QXK_schedUnlock@107-139@..\src\qxk\qxk.c
12 3 110 1 24 QF_init@144-167@..\src\qxk\qxk.c
3 1 10 1 4 QF_stop@170-173@..\src\qxk\qxk.c
20 6 98 1 35 QF_run@176-210@..\src\qxk\qxk.c
29 5 178 7 42 QActive_start_@217-258@..\src\qxk\qxk.c
42 8 220 1 53 QXK_sched_@266-318@..\src\qxk\qxk.c
59 16 377 1 96 QXK_activate_@321-416@..\src\qxk\qxk.c
12 2 72 1 18 QXK_current@419-436@..\src\qxk\qxk.c
19 5 105 1 26 QXK_contextSw@440-465@..\src\qxk\qxk.c
13 2 104 1 23 QXK_threadExit_@472-494@..\src\qxk\qxk.c
10 2 64 2 13 QXMutex_init@74-86@..\src\qxk\qxk_mutex.c
79 11 701 2 136 QXMutex_lock@89-224@..\src\qxk\qxk_mutex.c
57 9 483 1 95 QXMutex_tryLock@227-321@..\src\qxk\qxk_mutex.c
74 12 622 1 129 QXMutex_unlock@324-452@..\src\qxk\qxk_mutex.c
9 1 51 3 11 QXSemaphore_init@73-83@..\src\qxk\qxk_sema.c
57 7 389 2 84 QXSemaphore_wait@86-169@..\src\qxk\qxk_sema.c
28 3 139 1 39 QXSemaphore_tryWait@172-210@..\src\qxk\qxk_sema.c
42 7 275 1 66 QXSemaphore_signal@213-278@..\src\qxk\qxk_sema.c
21 2 113 3 26 QXThread_ctor@74-99@..\src\qxk\qxk_xthr.c
21 4 195 1 38 QXThread_delay@102-139@..\src\qxk\qxk_xthr.c
14 2 68 1 16 QXThread_delayCancel@142-157@..\src\qxk\qxk_xthr.c
58 7 493 1 85 QXThread_queueGet@160-244@..\src\qxk\qxk_xthr.c
10 1 39 3 11 QXThread_init_@247-257@..\src\qxk\qxk_xthr.c
10 1 39 3 11 QXThread_dispatch_@260-270@..\src\qxk\qxk_xthr.c
31 7 216 7 52 QXThread_start_@273-324@..\src\qxk\qxk_xthr.c
100 15 527 4 140 QXThread_post_@327-466@..\src\qxk\qxk_xthr.c
8 1 30 2 9 QXThread_postLIFO_@469-477@..\src\qxk\qxk_xthr.c
5 1 49 1 7 QXThread_block_@480-486@..\src\qxk\qxk_xthr.c
8 3 56 1 8 QXThread_unblock_@489-496@..\src\qxk\qxk_xthr.c
20 3 157 3 39 QXThread_teArm_@499-537@..\src\qxk\qxk_xthr.c
11 2 46 1 13 QXThread_teDisarm_@540-552@..\src\qxk\qxk_xthr.c
33 file analyzed.
==============================================================
NLOC Avg.NLOC AvgCCN Avg.token function_cnt file
--------------------------------------------------------------
6 0.0 0.0 0.0 0 ..\include\qassert.h
133 3.0 1.0 16.0 1 ..\include\qep.h
33 3.0 1.0 17.0 3 ..\include\qequeue.h
226 7.0 2.6 64.2 8 ..\include\qf.h
15 3.0 1.0 20.0 2 ..\include\qf_pkg.h
16 0.0 0.0 0.0 0 ..\include\qk.h
25 0.0 0.0 0.0 0 ..\include\qmpool.h
7 0.0 0.0 0.0 0 ..\include\qpc.h
361 14.0 3.0 67.0 1 ..\include\qs.h
3 0.0 0.0 0.0 0 ..\include\qstamp.c
2 0.0 0.0 0.0 0 ..\include\qstamp.h
0 0.0 0.0 0.0 0 ..\include\qs_dummy.h
19 0.0 0.0 0.0 0 ..\include\qs_pkg.h
7 0.0 0.0 0.0 0 ..\include\qv.h
93 0.0 0.0 0.0 0 ..\include\qxk.h
363 31.8 5.3 184.8 11 ..\src\qf\qep_hsm.c
346 33.3 5.6 195.1 10 ..\src\qf\qep_msm.c
2 0.0 0.0 0.0 0 ..\src\qf\qf_act.c
257 27.8 3.8 154.4 9 ..\src\qf\qf_actq.c
69 20.7 2.3 107.0 3 ..\src\qf\qf_defer.c
138 18.4 3.3 111.4 7 ..\src\qf\qf_dyn.c
103 32.0 4.3 197.0 3 ..\src\qf\qf_mem.c
114 21.0 4.4 123.6 5 ..\src\qf\qf_ps.c
96 17.6 4.6 113.0 5 ..\src\qf\qf_qact.c
152 36.2 4.8 200.8 4 ..\src\qf\qf_qeq.c
18 16.0 2.0 79.0 1 ..\src\qf\qf_qmact.c
218 26.2 4.1 155.6 8 ..\src\qf\qf_time.c
191 22.9 5.0 129.1 8 ..\src\qk\qk.c
81 18.5 5.0 109.2 4 ..\src\qv\qv.c
260 22.9 5.0 138.5 11 ..\src\qxk\qxk.c
227 55.0 8.5 467.5 4 ..\src\qxk\qxk_mutex.c
143 34.0 4.5 213.5 4 ..\src\qxk\qxk_sema.c
325 24.4 3.8 156.0 13 ..\src\qxk\qxk_xthr.c
=============================================================================================================
No thresholds exceeded (cyclomatic_complexity > 20 or length > 500 or nloc > 1000000 or parameter_count > 10)
==========================================================================================
Total nloc Avg.NLOC AvgCCN Avg.token Fun Cnt Warning cnt Fun Rt nloc Rt
------------------------------------------------------------------------------------------
4049 24.4 4.3 150.5 125 0 0.00 0.00
@endcode

538
doxygen/gs.dox
View File

@ -1,538 +0,0 @@
/*! @page gs Getting Started
The following sections describe how to get started with QP&trade;/C quickly:
- @subpage gs_get
- @subpage gs_tut
The YouTube Video <a class="extern" target="_blank" href="https://youtu.be/O7ER6_VqIH0">Getting Started with QP&trade; Frameworks</a> provides instructions on how to download, install and get started with QP quickly.
@image html gs-video.jpg
@image latex gs-video.jpg width=4.5in
@caption{[Video: Getting Started with QP&trade; Real-Time Embedded Framework](https://youtu.be/O7ER6_VqIH0)}
<br>
@note
@htmlonly
<a href="cert.html" title="QP Cert-Pack"><img src="img/cert-pack.png" style="float:right; margin:0 20px 20px 0;"></img></a>
@endhtmlonly
Information about the QP/C functionality, architecture, design, and other aspects is provided in the [Certification Package](modules.html):
- @ref srs &mdash; QP/C functionality
- @ref sas &mdash; QP/C architecture
- @ref sds &mdash; QP/C design
- @ref misra &mdash; QP/C compliance with MISRA-C
@ifnot LATEX
@nav{index,gs_get}
@endif
*/
/*##########################################################################*/
/*! @page gs_get Downloading &amp; Installing QP&trade;/C
@ifnot LATEX
@nav{gs,gs_tut}
@endif
@section gs_bundle Downloading QP&trade;/C in QP&trade;-Bundle
The most recommended way of obtaining QP&trade;/C&trade; is by downloading the @webref{#Downloads, <b>QP-bundle&trade;</b>}, which includes QP&trade;/C as well as other QP&trade; frameworks and also the @webref{products/qm, QM&trade; modeling tool} and the @webref{products/qtools, QTools&trade; collection}. The main advantage of obtaining QP&trade;/C bundled together like that is that you get all components, tools and examples ready to go.
@image html qp-bundle.png
@image latex qp-bundle.png width=1.5in
@caption{@webref{#Downloads, QP-bundle&trade; downloads}}
<br>
@note
@htmlonly
<a target="_blank" href="https://github.com/QuantumLeaps/qpc" title="QP&trade;/C on GitHub"><img style="float:right; clear:right;" src="img/logo_github.png"></a>
@endhtmlonly
If you are allergic to installers and GUIs or don't have administrator privileges you can also **download and install QP&trade;/C separately** from the <a class="extern" target="_blank" href="https://github.com/QuantumLeaps/qpc"><b>QP&trade;/C GitHub repository</b></a>, as described in the next section.
@section gs_gh Downloading QP&trade;/C from GitHub
Go to the <a class="extern" href="https://github.com/QuantumLeaps/qpc/releases" target="_blank">QP&trade;/C <strong>release</strong> page on GitHub</a>, and choose the QP&trade;/C version number you wish to download. You should select the latest QP&trade;/C version, unless you have a very specific reason to go with an older release.
@image html qpc_gh.jpg
@image latex qpc_gh.jpg width=5.0in
@caption{<a class="extern" href="https://github.com/QuantumLeaps/qpc/releases" target="_blank">QP&trade;/C downloads from GitHub</a>}
@section gs_dir QP&trade;/C Installation Folder
The following annotated directory tree lists the top-level directories provided in the standard QP&trade;/C distribution.
<ul class="tag">
<li><span class="img folder">qpc/</span>
</li>
<ul class="tag">
<li><span class="img folder">3rd_party/</span> &mdash; 3rd-Party code used in the @ref exa "QP&trade;/C Examples"
</li>
<li><span class="img folder">examples/</span> &mdash; @ref exa "QP&trade;/C Examples"
</li>
<li><span class="img folder">ports/</span> &mdash; @ref ports "QP&trade;/C Ports"
</li>
<li><span class="img folder">@ref /qp-dev/qpc/include "include/"</span> &mdash; Platform-independent QP&trade;/C API, see also @ref api
</li>
<li><span class="img folder">@ref /qp-dev/qpc/src "src/"</span> &mdash; Platform-independent QP&trade;/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&trade;/C Examples". Therefore, it is highly **recommended** to download the latest [QP/C Release](https://github.com/QuantumLeaps/qpc/releases) as opposed to cloning the repo directly.
@remark
The standard QP&trade;/C distribution contains the `examples` folder with many @ref exa "Example Projects", which are specifically designed to help you learn to use QP&trade;/C and to serve you as starting points for your own projects.
@ifnot LATEX
@nav{gs,gs_tut}
@endif
*/
/*##########################################################################*/
/*! @page gs_tut QP&trade;/C Tutorial
@ifnot LATEX
@nav{gs_get,tut_blinky}
@endif
This Tutorial describes how to use the QP/C&trade; 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&trade; 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&trade;/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.
@ifnot LATEX
@nav{gs_get,tut_blinky}
@endif
*/
/*##########################################################################*/
/*! @page tut_blinky Simple Blinky Application
@ifnot LATEX
@nav{gs_tut,tut_dpp}
@endif
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&trade; 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.
@image html blinky_ek-tm4c123gxl.gif
@image latex blinky_ek-tm4c123gxl.jpg width=2.0in
@caption{Blinky on EK-TM4C123GLX (TivaC LaunchPad)}
@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 "qpc/examples/examples" directory (e.g., `qpc/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&trade; framework;
- starting an active object; and
- transferring control to QP&trade; 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&trade; Real-Time Embedded Frameworks}.
@image html AN-getting_started.jpg
@image latex AN-getting_started.jpg width=2.0in
@caption{@webref{doc/AN_Getting_Started_with_QP.pdf, Getting Started with QP&trade; Real-Time Embedded Frameworks}}
@ifnot LATEX
@nav{gs_tut,tut_dpp}
@endif
*/
/*##########################################################################*/
/*! @page tut_dpp Dining Philosophers Problem (DPP)
@ifnot LATEX
@nav{tut_blinky,tut_game}
@endif
The Dining Philosophers Problem (DPP) example is an intermediate-level application with *multiple* active objects. It illustrates the following QP&trade; 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&trade; framework;
- starting multiple active objects; and
- transferring control to QP&trade; 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 "qpc/examples/examples" directory (e.g., `qpc/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}.
@image html AN_DPP.jpg
@image latex AN_DPP.jpg width=2.0in
@caption{@webref{doc/AN_DPP.pdf, Application Note: Dining Philosophers Problem (DPP) Example}}
@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">qpc/examples/examples/workstation/dpp-comp/</span>
@ifnot LATEX
@nav{tut_blinky,tut_game}
@endif
*/
/*##########################################################################*/
/*! @page tut_game "Fly 'n' Shoot" Game
@ifnot LATEX
@nav{tut_dpp,tut_low}
@endif
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.
@image html bd_EFM32-SLSTK3401A.jpg
@image latex bd_EFM32-SLSTK3401A.jpg width=4.5in
@caption{EFM32 Pearl-Geckob}
"Fly 'n' shoot" game and illustrates the following QP&trade; 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&trade; GUI Prototyping Toolkit})
@image html qwin_ani.gif "Fly 'n' Shoot game running on Windows"
@image latex qwin_static.jpg "Fly 'n' Shoot game running on Windows" width=6in
The "Fly 'n' Shoot" game example is described in the @webref{doc/AN_Fly-n-Shoot.pdf,Application Note: Fly 'n' Shoot Game Example}.
@image html AN-game.jpg "Application Note: Fly 'n' Shoot Game Example"
@image latex AN-game.jpg "Application Note: Fly 'n' Shoot Game Example" width=2in
<br>
@image html game-video.jpg
@image latex game-video.jpg width=5in
@caption{Fly'n'Shoot game tutorial video}
@ifnot LATEX
@nav{tut_dpp,tut_low}
@endif
*/
/*##########################################################################*/
/*! @page tut_low Low-Power Example
@ifnot LATEX
@nav{tut_game,exa}
@endif
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.
@image html exa_low-power_tick.png
@image latex exa_low-power_tick.png width=5.5in
@caption{Additional power dissipation caused by the system clock tick}
@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&trade; Real-Time Embedded Frameworks don't provide the "tickless mode". Instead, the QP&trade; frameworks support **multiple clock tick rates**, which can be turned on and off, as needed. The QP&trade; 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:
<br>
@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.
@image html bd_EK-TM4C123GXL.jpg
@image latex bd_EK-TM4C123GXL.jpg width=2.5in
@caption{EK-TM4C123GXL (TivaC LaunchPad}
@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:
<br>
@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:
@image html exa_low-power_sig.png "low-power application after pressing the SW1 button"
@image latex exa_low-power_sig.png "low-power application after pressing the SW1 button"
`[0]` 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.
`[1]` 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.
`[2]` The **Blinky1** (Blue-LED) stops toggling after 13 cycles. At this point also the **Idle** callback turns the **fast tick rate-1** off.
`[3]` The **Blinky0** (Green-LED) stops toggling after 4 cycles.
`[4]` 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.
@remark
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:
@image html exa_low-power_sm.png
@image latex exa_low-power_sm.png width=4.0in
@caption{state machines Blinky0 and Blinky1 active objects}
`[0]` 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.
`[1]` 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.
@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:
<br>
@code{.c}
#include "qpc.h"
#include "low_power.h"
#include "bsp.h"
/* 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
`[0]` 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`.
`[1]` 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.
@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.
<br>
@code{.c}
[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
`[0]` The idle callback for QK and QXK are called from the idle loop with interrupts enabled.
`[1]` 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.
`[2]` If the SYSTICK timer is active (source of the tick-0 rate)~~~
`[3]` The `QF_noTimeEvtsActiveX(0)` function is called to check whether no time events are active at the clock rate-0.
@remark
The QF_noTimeEvtsActiveX() function is designed to be called from a critical section, which is the case here.
`[4]` If both of these conditions hold, it is safe to turn the clock rate-0 off, which is done here.
`[5]` The bit indicating that SYSTICK timer is active is cleared in the `l_activeSet` bitmask.
`[6]` Simliarly, the bit corresponding to TIMER0 is checked in the `l_activeSet` bitmask.
`[7]` The `QF_noTimeEvtsActiveX(1)` function is called to check whether no time events are active at the clock rate-1.
`[8-9]` If both of these conditions hold, it is safe to turn the clock rate-1 off, which is done here.
`[10]` The bit indicating that TIMER0 timer is active is cleared in the `l_activeSet` bitmask.
`[11]` Interrupts are enabled, so the following code is no logner inside critical section
`[12]` The **Red-LED** is turned ON right before entering the low-power sleep mode
`[13]` The `__WFI()` instruction stops the CPU and enters the **low-power sleep mode**
`[14]` The **Red-LED** is turned off after waking up from the sleep mode
@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:
<br>
@code{.c}
[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
`[0]` The idle callback for QV is called from the QV event-loop with interrupts **disabled**.
`[1]` The `l_activeSet` bitmask is tested right away, because interrupts are already disabled
`[2]` The `QF_noTimeEvtsActiveX(0)` function is called to check whether no time events are active at the clock rate-0.
@remark
The QF_noTimeEvtsActiveX() function is designed to be called from a critical section, which is the case here.
`[3]` 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.
@ifnot LATEX
@nav{tut_game,exa}
@endif
*/

35
doxygen/help.dox
View File

@ -1,35 +0,0 @@
/*! @page help Using Online Help
<p>You can use this online help in various ways: either sequentially from beginning to end or just by quickly locating the interesting topic.
</p>
![Online Help Features](help_using.png)
@section help_seq Reading Online Help Sequentially
You can move from topic to topic by means of the <span class="strong underline">Next:</span> link at the bottom of each page.
@section help_random Quickly Locating a Topic of Interest
You can use the following elements:
- the @ref help_tree_view "Tree View" pane on the left-hand side of the browser;
- the **Table of Contents** box in the top-right corner of the page;
- the **Search** box in the upper-right corner of the browser window
@section help_tree_view Using the Tree View
The *Tree View* pane on the left-hand side of the browser displays the hierarchical Table of Contents, which can be either **linked-to** or **unlinked-from** the *Current Topic* displayed on the right-hand side. You can toggle between the two modes by pressing the **Link/Unlink Current Topic** icon at the top of the *Tree View* pane.
<img src="img/tree-view_linked.png" style="float:left; margin-right:10px;">
When the *Tree View* is **linked** to the Current Topic, the *Tree View* will always follow the currently viewed topic, by expanding and highlighting the pertinent section of the hierarchical Table of Contents.
<div style="clear:both;"></div>
<img src="img/tree-view_unlinked.png" style="float:left; margin-right:10px;">
When the *Tree View* is **unlinked** from the Current Topic, the *Tree View* will show only the explicitly selected section of the hierarchical Table of Contents and will **not** follow the topics activated by internal documentation links.
*/

2970
doxygen/history.dox
View File

File diff suppressed because it is too large Load Diff

BIN
doxygen/images/AN-QL.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 66 KiB

BIN
doxygen/images/AN-game.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 37 KiB

BIN
doxygen/images/AN-getting_started.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 46 KiB

BIN
doxygen/images/AN_DPP.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 42 KiB

BIN
doxygen/images/AN_Getting-Started.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 35 KiB

BIN
doxygen/images/AN_QP_Performance.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 68 KiB

BIN
doxygen/images/Arduino-UNO_button.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 82 KiB

BIN
doxygen/images/Arduino-UNO_button_schem.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 26 KiB

BIN
doxygen/images/PSiCC2_250x200.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 18 KiB

BIN
doxygen/images/SM_blinky.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 9.2 KiB

BIN
doxygen/images/SM_of_Blinky.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 9.6 KiB

BIN
doxygen/images/an-oop_in_c.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 48 KiB

BIN
doxygen/images/an-qp_performance.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 70 KiB

BIN
doxygen/images/arm-cm_qk_test-ccs.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 97 KiB

BIN
doxygen/images/bd_AT91SAM7S-EK.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 104 KiB

BIN
doxygen/images/bd_AT91SAM7S-EK_J-Link.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 46 KiB

BIN
doxygen/images/bd_Arduino-UNO.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 55 KiB

BIN
doxygen/images/bd_EFM32-SLSTK3401A.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 48 KiB

BIN
doxygen/images/bd_EK-LM3S6965.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 93 KiB

BIN
doxygen/images/bd_EK-LM3S6965_lwip.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 25 KiB

BIN
doxygen/images/bd_EK-LM3S811.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 61 KiB

BIN
doxygen/images/bd_EK-LM3S811_game.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 30 KiB

BIN
doxygen/images/bd_EK-TM4C123GXL.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 29 KiB

BIN
doxygen/images/bd_LAUNCHXL2-TMS57012.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 89 KiB

BIN
doxygen/images/bd_MSP-EXP430F5529LP.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 111 KiB

BIN
doxygen/images/bd_MSP-EXP430G2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 112 KiB

BIN
doxygen/images/bd_NUCLEO-H743ZI.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 48 KiB

BIN
doxygen/images/bd_NUCLEO-L053R8.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 82 KiB

BIN
doxygen/images/bd_NUCLEO-L152RE.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 75 KiB

BIN
doxygen/images/bd_NUCLEO-L552ZE.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 43 KiB

BIN
doxygen/images/bd_STM32F4-Disco.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 127 KiB

BIN
doxygen/images/bd_STM32F4-Disco_RS232.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 107 KiB

BIN
doxygen/images/bd_STM32F746G-Disco.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 73 KiB

BIN
doxygen/images/bd_mbed-LPC1768.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 11 KiB

BIN
doxygen/images/blinky_ek-tm4c123gxl.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 41 KiB

BIN
doxygen/images/blinky_ek-tm4c123gxl.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 21 KiB

BIN
doxygen/images/blinky_posix.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 179 KiB

BIN
doxygen/images/blinky_win32.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 10 KiB

BIN
doxygen/images/car_mud.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 136 KiB

BIN
doxygen/images/com_msp-exp430g2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 34 KiB

BIN
doxygen/images/dpp_posix.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 253 KiB

BIN
doxygen/images/dpp_win.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 77 KiB

BIN
doxygen/images/dpp_win32.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 34 KiB

BIN
doxygen/images/dpp_win32.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

BIN
doxygen/images/emWin_demo.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 62 KiB

BIN
doxygen/images/exa_low-power_sig-zoom.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 23 KiB

BIN
doxygen/images/exa_low-power_sm.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 17 KiB

BIN
doxygen/images/game-video.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 97 KiB

BIN
doxygen/images/getting-started-with-qp.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 26 KiB

BIN
doxygen/images/github-star.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 25 KiB

BIN
doxygen/images/gs-video.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 115 KiB

BIN
doxygen/images/header_logo_bg.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 12 KiB

BIN
doxygen/images/header_logo_ql.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 16 KiB

BIN
doxygen/images/logo_embos.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.5 KiB

BIN
doxygen/images/logo_freertos.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

BIN
doxygen/images/logo_pclintplus.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 32 KiB

BIN
doxygen/images/logo_ql-comp.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

BIN
doxygen/images/logo_ql-icon.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.1 KiB

BIN
doxygen/images/logo_ql.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 19 KiB

BIN
doxygen/images/logo_ql_TM.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.9 KiB

BIN
doxygen/images/logo_qp.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 15 KiB

BIN
doxygen/images/logo_qp_200x55.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 18 KiB

BIN
doxygen/images/logo_qp_60x55.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.0 KiB

BIN
doxygen/images/logo_qspy.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 59 KiB

BIN
doxygen/images/logo_threadx.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 6.6 KiB

BIN
doxygen/images/logo_uc-os2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 11 KiB

BIN
doxygen/images/logo_zephyr.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 9.9 KiB

BIN
doxygen/images/mbed-LPC1768_button.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 26 KiB

BIN
doxygen/images/oop-in-C.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

BIN
doxygen/images/psicc1.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 67 KiB

BIN
doxygen/images/psicc2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 46 KiB

BIN
doxygen/images/qk_preempt.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 15 KiB

BIN
doxygen/images/qp-bundle.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 16 KiB

BIN
doxygen/images/qp-prio.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.8 KiB

BIN
doxygen/images/qp-zephyr.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 24 KiB

BIN
doxygen/images/qp_banner.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 94 KiB

BIN
doxygen/images/qp_classes.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 26 KiB

BIN
doxygen/images/qp_components.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 47 KiB

BIN
doxygen/images/qpc_gh.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 102 KiB

BIN
doxygen/images/qutest_philo.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 79 KiB

Some files were not shown because too many files have changed in this diff Show More