SS symmetry

Article
Timing Comparison of the Real-Time Operating
Systems for Small Microcontrollers
Ioan Ungurean 1,2
1 Faculty of Electrical Engineering and Computer Science; Stefan cel Mare University of Suceava,
720229 Suceava, Romania; [email protected]
2 MANSiD Integrated Center, Stefan cel Mare University, 720229 Suceava, Romania




Received: 9 March 2020; Accepted: 1 April 2020; Published: 8 April 2020


Abstract: In automatic systems used in the control and monitoring of industrial processes, fieldbuses
with specific real-time requirements are used. Often, the sensors are connected to these fieldbuses
through embedded systems, which also have real-time features specific to the industrial environment
in which it operates. The embedded operating systems are very important in the design and
development of embedded systems. A distinct class of these operating systems is real-time operating
systems (RTOSs) that can be used to develop embedded systems, which have hard and/or soft
real-time requirements on small microcontrollers (MCUs). RTOSs offer the basic support for
developing embedded systems with applicability in a wide range of fields such as data acquisition,
internet of things, data compression, pattern recognition, diversity, similarity, symmetry, and so
on. The RTOSs provide basic services for multitasking applications with deterministic behavior on
MCUs. The services provided by the RTOSs are task management and inter-task synchronization and
communication. The selection of the RTOS is very important in the development of the embedded
system with real-time requirements and it must be based on the latency in the handling of the critical
operations triggered by internal or external events, predictability/determinism in the execution of the
RTOS primitives, license costs, and memory footprint. In this paper, we measured and compared
the timing performance for synchronization throughout an event, semaphore, and mailbox for the
following RTOSs: FreeRTOS 9.0.0, FreeRTOS 10.2.0, rt-thread, Keil RTX, uC/OS-II, and uC/OS-III.
For the experimental tests, we developed test applications for two MCUs: ARM Cortex™-M4 and
ARM Cortex™-M0+ based MCUs.

Keywords: real time systems; real time operating systems; task synchronization; microcontrollers

1. Introduction
In the automation systems designed and developed to monitor and control industrial processes,
it is very important that they comply with the real-time requirements of the industrial installations.
Typically, these systems contain industrial networks (fieldbuses) to which embedded devices are
connected. These devices can acquire data from the sensors and receive/send data through the
fieldbuses. The embedded systems used in the automation systems must have hard and/or soft
real-time features and they must react in the imposed deadline to the data/events received throughout
the fieldbuses or data acquired from the sensors connected to the embedded devices [1].
Usually, the design and development of the embedded systems, from the software point of
view, is based on an embedded operating system. The real time operating systems (RTOSs) are a
particular category of embedded operating systems that were designed to provide support in the
design and develop of embedded systems with real-time capabilities. These operating systems have
been developed especially for small microcontrollers (MCUs) on 8, 16, or 32 bits that are used to
design and develop embedded systems [2]. Examples of RTOSs include FreeRTOS, RT-Thread, eCOS,

Symmetry 2020, 12, 592; doi:10.3390/sym12040592 www.mdpi.com/journal/symmetry

Symmetry 2020, 12, 592 2 of 19

LynxOS, QNX, VxWorks, OSEK (Open Systems and their Interfaces for the Electronics in Motor
Vehicles), uC-OS/II, uC-OS/III, KEIL RTX, etc. [2]. These operating systems are designed to provide a
deterministic and predictable time in the handling of the internal or external events [3,4]. In addition,
RTOSs are widely used in the design and development of applications based on the Internet of Things
(IoT) and Industrial Internet of Things (IIoT) concepts [5].
RTOSs are part of a category of operating systems designed for embedded systems, especially for
systems with a small memory for code and data. Usually, these RTOSs are designed for MCUs that
do not use virtual memory [6]. Linux and Windows that use have real time characteristics but there
are variants for real time systems for these systems. For example, RTLinux is a patch for Linux with
real time capabilities where real time tasks do not use virtual memory and have direct access to the
hardware [7]. Windows Embedded Industry is the Windows based operating system for embedded
systems with real time capabilities. We will consider small MCUs, the MCUs that do not have virtual
memory and cannot use operating systems based on Linux, Windows, or Android (for example, these
operating systems can be used on ARM Cortex Ax MCUs). With these MCUs, specialized applications
with real-time capabilities can be developed.
This paper aims to make a comparison of RTOSs that are used on small MCUs, such as those
based on ARM Cortex Mx architectures. These MCUs use RTOSs with a small memory footprint and
without a memory management system such as virtual memory. Applications based RTOS for small
MCUs are used in domains such as automotive [8], industrial automation [9], telecommunications [10],
avionics [11], military systems [12], Internet of things, Industrial Internet of things [13], and so on.
An area of applicability is that of a symmetry concept by developing embedded systems for data
acquisition, data compression, pattern recognition, diversity, and sustainability. Usually, the software
applications for these domains are a combination of soft and hard real-time tasks [6].
Several features, services, and capabilities are used to compare RTOSs. The most important ones
are the maximum time for deactivation of the interrupts and the worst-case execution time (WCET)
for tasks and RTOS services such as the routines of service of the interruptions, the time of executing
the receipts, etc. [14,15]. Other features used in the comparison are modularity, scalability, memory
footprint, latency, response time, and jitter [6,14]. An RTOS provides the basic services for developing
multitasking software applications. The fundamental service provided by an RTOS is task management.
Each task has associated a priority and the task with the highest priority from the ready state will
enter in running state. There are two types of scheduling: preemptive and non-preemptive. At the
pre-emptive scheduling, a task from the running state can be preempted by a higher priority task
that enters in the ready state, while at the non-preemptive scheduling, the task from the running
state must voluntarily release the processor. Most RTOSs use pre-emptive scheduling because it
allows for achieving a shorter response time for critical operations. In addition, most RTOSs include
synchronization and inter-task communication services such as semaphores, events, mailboxes, and
message queues [6].
RTOSs can be compared from several perspectives, some of them are: the time for synchronization
and inter-task communication or the response time of the task with the highest priority after the
expected event occurs. In [14], we presented a first comparative test for the time of task context
switching where task switching is triggered by an event, semaphore, or mailbox. In this paper, we
measured, compared, and analyzed the timing performances for the following RTOSs: FreeRTOS
9.0.0, FreeRTOS 10.2.0, rt-thread, Keil RTX, uC/OS-II, and uC/OS-III. All of these RTOSs support
preemptive scheduling.
For testing, we used two MCUs: ARM Cortex™-M4 and ARM Cortex™-M0+ based MCUs.
The paper extends the experimental tests presented in [14]. In [14], there are measured and compared
timing performances for task context switching from a lower priority task to a higher priority task
triggered by an event, semaphore, and mailbox. In this paper, the tests are completed by measuring the
timing performances for the task context switching from a higher priority task to a lower priority task
Symmetry 2020, 12, 592 3 of 19

and the timing performance for the primitives (non-blocking) used to wait and send/signal an event,
semaphore, and mailbox. Furthermore, we use the newest compiler provided by the KEIL MDK-ARM.
The main contribution of this paper is that the experimental tests are performed in actual MCUs,
and not just simulations using software tools as found in related works. A test pin (an output GPIO
(general-purpose input/output) selected according to the MCU and board used) is used to signal the
beginning and the end of the operation for which we want to measure the time and the time is measured
with an oscilloscope on this test pin. This paper aims to compare the timing for synchronization of the
tasks for the most used RTOSs on small microcontrollers. To achieve this goal, RTOSs are executed on
the same hardware configuration.
This paper is structured as follows: Section 2 presents some performances tests presented in the
specialized literature and the motivation for the target RTOS’s selection, Section 3 describes the test
setup. Section 4 contains discussions related to the experimental results. The conclusions are drawn in
Section 5.

2. Related Works
Interesting studies related to the market for embedded systems are published by EETimes.com
and Embedded.com every year. Unfortunately, the last study was published in 2017 and it has not
updated [16]. In the last market study, they conclude that 68% of the ongoing embedded projects use
and embedded operating system, and of these, 41% use an open-source embedded operating system.
If we exclude the embedded system based on Linux or Windows, the most used RTOS are FreeRTOS
(20% of the ongoing embedded projects that use an operating systems), in house solution (19%), Texas
Instruments RTOS (5%), Texas Instruments DSP/BIOS (5%), Micrium uC-OS/III (5%), Keil RTX (4%),
Micrium uC-OS/II (4%), and Wind River VxWorks (4%). From embedded operating systems based on
Windows or Linux, the most used are Embedded Linux (22%), Debian (13%), Microsoft (Windows
Embedded 7/Standard) (8%), Microsoft (Windows 7 Compact or earlier) (5%), and Angstrom (3%).
There are also other studies for the RTOS market such as the one published by MarketWatch
Company in 2019 that presents the recent trends, size, growth, top manufacturers, and forecast to 2024
related to RTOS systems [17].
In [18], the authors present a Benchmark of Real Time Operating Systems. They focused ion
FreeRTOS, RTEMS, uC/OS-III, and Linux and they measured the overhead for semaphore and message
queue services in different scenarios on an MPCore Cortex A−7 900 MHz MCU. In this case, the best
performances (low overhead) are achieved by uC/OS-III and the weaker performances by Linux.
A comparison between a multicore RTOS and VxWorks is presented in [19]. The evaluation of
performances is performed in a simulator. The paper highlight the performances gain for a multicore
RTOS is. In [20], a performance evaluation of the RTOS for robotics is presented. Benchmarks and
comparisons of the RTOSs that use CMSIS-RTOS layer are presented in [21]. The tests are performed
for the RTX, X RT Kernel, FOSS Free and open-source software), and ChibiOS. The authors conclude
that the use of the CMSIS(Cortex Microcontroller Software Interface Standard)-RTOS layer do not
generate overhead for the RTOSs. In [21], the authors present an evaluation of the performances of
real time systems for vision based navigation. The tests are performed on a Rasberry Pi 2 model B
device on PREEMPT_RT and Xenomai kernels. The authors conclude that the best performances are
achieved by the Xenomai kernel. In [22], a comparison related performances of the FreeRTOS and
uC/OS-III is presented. The experimental tests are performed on Renesas RX63N MCU for the memory
footprint, latency, and service performances. In almost all of the tests, the uC/OS-III outperforms the
performances of the FreeRTOS. All of these comparisons are performed using simulators or different
software tools. In this paper, we wanted to compare the most used RTOS for small MCUs in actual and
modern MCUs using a GPIO output pin as a test pin to measure the time for different operations. By
this method, we can measure the real-time of the operations without other influences and as close as
possible to the real cases. RTOSs will be executed on the same hardware platform for a more accurate
comparison of performance.
Symmetry 2020, 12, 592 4 of 19

In this paper, we focused on four RTOSs for small MCUs: FreeRTOS, Micrium uC-OS/II and
Micrium uC-OS/III, Keil RTX, and rt-thread. FreeRTOS [23] is an open-source RTOS widely used in the
embedded systems project. Micro-Controller Operating Systems (uC-OS) is a commercial RTOS [24].
Keil RTX is a royalty-free RTOS included in the KEIL MDK-ARM tools [25]. rt-thread is an open source
RTOS [26].
We chose these RTOSs because they are at the top in the study [14], to which we added rt-thread
because we used it in previous projects. In addition, the targets of these RTOSs are small MCUs such
as those based on ARM Cortex M0, M3, and M4 architectures. Focusing on small microcontrollers,
no Linux or Windows-based operating systems were used because they target systems that are more
complex and, with small exceptions, cannot be executed on small MCUs. For example, Linux can be
executed on Arm Cortex M4 microcontrollers, but this variant is not used in practice for developing
dedicated devices with real-time capabilities. For the selected RTOSs, there are many examples of
real-time applications developed, and uC/OS-II and uC/OS-III have certifications for the development
of applications in the avionics, industrial control, and medical fields [27]. In [28], the authors propose
a system in the manufacturing IoT environment that includes aggregation nodes based on an Arm
Cortex M4 MCU and rt-thread RTOS. An evolution and an analysis of the real-time behaviors of the
FreeRTOS is presented in [29]. In [30], the authors present an implementation and performances of
a low-level control of omnidirectional mobile robot based on Keil RTX RTOS and an ARM Cortex
M4 MCU. In [31], an Electromagnetic transmitter for EM-MWD System is presented. The device is
developed with TMS320F2S12 MCU (digital signal processors based on Armv8.1-M architecture) and
uC/OS-III RTOS.
All of these examples highlight the fact that the selected RTOSs are used in the development of
real applications with real-time capabilities and present additional arguments for their selection, in
addition to the study presented in [14].

3. Experimental Setup
In [14], we presented some experimental results related to the time for context switching between
a low priority task to a higher priority task for the uC-OS/II, FreeRTOS 9.0.0, rt-thread, and Keil RTX
triggered by an event, semaphore and mailbox on two MCUs: STM32F407IG ARM Cortex™-M4
MCU, and STM32L053R8 ARM Cortex™-M0+ MCU. In this paper, we complete the experimental
tests with the time for the context switching between a high priority task to a lower priority task
(blocking wait in the high priority task) and the time for the primitives used to send and receive an
event, semaphore, and mailbox. Furthermore, we perform the experimental tests on two additional
RTOSs: FreeRTOS10.2.0 and uC-OS/III.
In the current section, we will describe and explain the experimental software applications when
the event is used as a synchronization mechanism between two tasks. For the events, we tested the
following scenarios: scenario 1—signal an event causing a context switch, scenario 2—wait for an
event causing context switching, scenario 3—signal an event without context switching (unblocking
signal), and scenario 4—wait for an available event (unblocking wait). In these scenarios, a test pin
(an output GPIO selected according to the MCU and board used) will be used to signal the beginning
and the end of the operation for which we want to measure the time. The time will be measured
with an oscilloscope on the test pin. For each scenario, we have a software application. This software
application is uploaded to the MCU flash in order to be executed.
The software diagram of the test software applications for the scenario 1 is shown in Figure 1 (it is
similar with the test software application used in [14]). The software applications consist of two tasks
with distinct priorities and the RTOSs are configured to use preemptive scheduling. In the test software
applications, the task with the lower priority, at a period of 1 ms, sets the test pin to 0 (LOW/FALSE)
and signals an event. The higher priority task waits, in an infinite loop, the event with infinite time-out
and when it receives the event, it sets the test pin to 1 (HIGH/TRUE). Thus, with an oscilloscope on the
Symmetry 2020, 12, 592 5 of 19

test pin, it is possible to determine the time for the task context switching triggered by the task with a
lower priority by sending the event waited by a task with the higher priority.
Symmetry 2020, 12, x FOR PEER REVIEW 5 of 19

Symmetry 2020, 12, x FOR PEER REVIEW 5 of 19

Figure
Figure 1. The
1. The softwarediagram
software diagramof
of the
the test
test software
softwareapplications
applicationsforfor
scenario 1. 1.
scenario
Figure 1. The software diagram of the test software applications for scenario 1.
Figure 2 presents the software diagram of the test software applications for the scenario 2. The
Figure 2 presents the software diagram of the test software applications for the scenario 2.
software
Figureapplications
2 presentsconsist
the of twodiagram
software tasks with of distinct
the priorities
testdistinct and preemptive
softwarepriorities
applications scheduling will be
The software applications consist of two tasks with andforpreemptive
the scenarioscheduling
2. The
used.
softwareThe higher
applicationspriority task sets the test pin to 0 (LOW/FALSE) and it waits an event with a time-
will be used.
out ofThe
The
1 ms.
higher consist
The lowest
priority of task
priority
two tasks
task
sets the
consists
withtestdistinct
pin topriorities
0loop and preemptive
(LOW/FALSE) and it scheduling
waits an will
event be with
used. higher priority task sets the test pinoftoan0 infinite
(LOW/FALSE) that sets
and it the
waitstestanpin to the
event onea logic.
with time-
a time-out of 1 ms.
By calling The lowestfor thepriority taska consists of anisinfinite loopandthat sets the test pintask,to the
out of 1 ms.theTheprimitive
lowest priority event wait,
task consists context
of switch
an infinite looptriggered
that sets the the pin
test lower priority
to the one logic.
one logic.
which Byincalling
is the
theprimitive
ready primitive
state, for thetherunning
event wait, a context switch testisthe
triggered and the lower
By calling the forwill
the pass
eventtowait, a context state and
switch it
iswill set
triggered theand pin to 1 (HIGH/TRUE).
lower priority task,
priority
Withtask,
this which is
configuration in the
and ready
by state,
using the will
test pass
pin, to
we the
can running
measure state
the time and
for
which is in the ready state, will pass to the running state and it will set the test pin to 1 (HIGH/TRUE). it will
task set
context the test pin to 1
switching
from
(HIGH/TRUE). a higher priority
With this configuration task to
With this configuration a lower
and by using the priority
and testby task.
pin, using
we can the test pin,
measure thewe time can
formeasure
task context theswitching
time for task
context
from These
switching
a highertwopriority
scenarios
from a task can
higherto be foundpriority
apriority
lower in
taskrealtosoftware
a lowerapplications.
task. priority task. For example, a task can wait for
data These
These from
twoatwocommunication
scenarios
scenarios cancan line
be be and when
found
found ininrealdata
real are received,
software
software an event,
applications.
applications. Formailbox,
For or asemaphore
example,
example, a task
task is sent
can
can wait wait
for for
data from a communication line and when data are received, an event, mailbox, or semaphorefor
to thefrom
data taskathat waits for data.
communication This
line and can
when trigger
data aare
taskreceived,
context switch
an event,to execute
mailbox, the
or task that waits
semaphore is sent
is sent
data.
theOr, a task can expectdata.
an event from another peripheral, such as atodigital input, and athat
task context
to thetotask task
thatthat
waitswaits
forfordata. This Thiscancantrigger
trigger aa task
taskcontext
contextswitch
switch execute
to execute the the
task waits
task that for for
waits
switch must be triggered (with an event, mailbox, or semaphore)as toahandle that event.
data. data.
Or, aOr,
taska task
cancan expect
expect anan event
event fromanother
from another peripheral,
peripheral,such such as digital
a digital input, andand
input, a task context
a task context
switch must be triggered (with an event, mailbox, or semaphore) to handle that event.
switch must be triggered (with an event, mailbox, or semaphore) to handle that event.

Figure 2. The software diagram of the test software applications for scenario 2.
Figure 2. The software diagram of the test software applications for scenario 2.
Figure 2. The software diagram of the test software applications for scenario 2.
Symmetry 2020, 12, 592 6 of 19
Symmetry 2020, 12, x FOR PEER REVIEW 6 of 19
Symmetry 2020, 12, x FOR PEER REVIEW 6 of 19

Figure 3 presents the

Figure software diagram
diagram ofthethe test software applications for the scenario 3.
Figure 33 presents
presents the
the software
software diagram of of the test
test software
software applications
applications for
for the
the scenario
scenario 3.3. The
The
The software
software applications
applications consist
consist of of only
only oneone task.
task. In In
this this
case, case,
everyevery
1 ms, 1 ms,
the the
test
software applications consist of only one task. In this case, every 1 ms, the test pin is set to 0 pintest
is pin
set is
to set
0 to
(LOW/FALSE),
0 (LOW/FALSE),
(LOW/FALSE), andand
andanan event
event
an (not
event(not expected
expected by
(notexpected by any
by anytask)
any task)is
task) isistriggered,
triggered,
triggered, whereupon
whereupon
whereupon the test
the the pin
pin is
test test set
setisto
pin
is toset to
1 (HIGH/TRUE).
1 (HIGH/TRUE).
1 (HIGH/TRUE). After
AfterAfter these
thesethese operations,
operations, the
thethe
operations, primitive
primitive
primitive for
forfor waiting
waiting
waiting an event
ananevent is called
eventisiscalled to receive
calledtotoreceive
receiveandand
and clear
clear
clear the
the event. event.
In this
the In
In this
this scenario,
scenario,
event. with thewith
scenario, help
with the
ofhelp
the the of
help the
test
of test
thepin, pin,
testthe the
the execution
pin,execution timetime
execution for for
time thethe
for primitive
primitive
the primitiveforfor
forevent
event triggering
event can
triggering can be measured.
can be measured.
triggering be measured.

Figure 3. The software diagram of the test software applications for scenario 3.
Figure 3. The
Figure software
3. The diagram
software diagramof
ofthe
the test software
softwareapplications
applicationsforfor scenario
scenario 3. 3.

Figure 44 presents the software

software diagram
Figure 4 presents
Figure the
presents thesoftware diagramof
diagram the
ofof
thethetest software
testtest applications
software
software for
for the
applications
applications scenario
the for 4.
4. The
the scenario
scenario The 4.
software applications
software applications consist
applications consist of only one task. In this scenario, we want to measure the execution
The software consistofofonlyonlyone
onetask.
task.In In
this scenario,
this scenario,we we
want to measure
want to measurethe execution
the execution
time for
timethe the
the primitive
forprimitive
primitive used
used to
to receive
receive an
an existing
existing event.
event.The The software
Thesoftware applications
applications are
softwareapplications are similar
similar with
with
time for
the used to receive an existing event. are similar with the
the third scenario, with differences that the test pin is set to 0 (LOW/FALSE) before the call for the
third scenario, with differences that the test pin is set to 0 (LOW/FALSE) before the call for the
third waiting
scenario, with differences that the test pin is set to 0 (LOW/FALSE) before the call for the waiting
waiting primitive
primitive and
and is
is set
set to
to 11 (HIGH/TRUE)
(HIGH/TRUE) after after this
this call.
call.
primitive and is set to 1 (HIGH/TRUE) after this call.

Figure 4. The software diagram of the test software applications for scenario 4.
Figure
Figure 4. The
4. The software
software diagramof
diagram ofthe
the test
test software
softwareapplications
applicationsforfor
scenario 4. 4.
scenario
Test software applications with the same configuration were developed when semaphores or
Test software applications with the same configuration were developed when semaphores or
Test software used
mailboxes applications with the same configuration were developed when semaphores or
mailboxes are
are used as as synchronization
synchronization mechanisms,
mechanisms, usingusing the
the waiting
waiting andand signalling
signalling primitives
primitives
mailboxes are
specific used as synchronization mechanisms, using the waiting and signalling primitives specific
specific to
to each
each mechanism.
mechanism. We We developed
developed aa software
software application
application for
for each
each ofof the
the chosen
chosen RTOSs
RTOSs on on
to each
twomechanism. We developed a software application for each
two MCUs: STM32F407IG ARM Cortex™-M4 MCU and STM32L053R8 ARM Cortex™-M0+ MCU.
MCUs: STM32F407IG ARM Cortex™-M4 MCU and of
STM32L053R8 the chosen
ARM RTOSs
Cortex™-M0+ on two
MCU.
MCUs:
We
We used
used the
STM32F407IG ARM
the following versions
Cortex™-M4
following of
of RTOSs:
versionsMCU uC-OS/II
uC-OS/II V2.92.11,
and STM32L053R8
RTOSs: ARM
V2.92.11, uC-OS/III V3.05.00,
V3.05.00, FreeRTOS
Cortex™-M0+
uC-OS/III MCU. We9.0.0,
FreeRTOS used the
9.0.0,
FreeRTOS
following 10.2.0,
versions of rt-thread
RTOSs: V2.1.1,
uC-OS/II and Keil RTX
V2.92.11, V4.82.0.
uC-OS/III For all RTOSs,
V3.05.00, the most
FreeRTOS code is
9.0.0,
FreeRTOS 10.2.0, rt-thread V2.1.1, and Keil RTX V4.82.0. For all RTOSs, the most code is in C because in C because
FreeRTOS 10.2.0,
the
rt-thread purpose
V2.1.1, of
the purpose of
andthese RTOSs
KeilRTOSs
these is to
RTX V4.82.0. provide better
For better
is to provide portability.
all RTOSs, Using
the most
portability. Using the
code same
the is compiler,
in Ccompiler,
same they
becausethey can
the purposebe
can be of
compared under the
the same conditions, with no
no optimized code. For
For each synchronization mechanism,
these compared
RTOSs is under
to provide same conditions,
better withUsing
portability. optimized
the samecode. eachthey
compiler, synchronization
can be comparedmechanism,
under the
a software
software application has
has been
been developed for each MCU,
MCU, andand from these
these software applications, the
same aconditions, application
with no optimized developed
code. Forfor each
each synchronizationfrommechanism, software applications,
a software the
application
scenarios
scenarios are
are activated
activated with
with conditional
conditional compilation.
compilation.
has been developed
The for each MCU, and from these software applications,Cortex™-M4
the scenarios are activated
The tests
tests were
were performed
performed on on two
two MCUs:
MCUs: STM32F407IG
STM32F407IG ARM ARM Cortex™-M4 MCU MCU and and
with conditional
STM32L053R8 compilation.
STM32L053R8 ARM Cortex™-M0+ MCU. The following development kits were used for
ARM Cortex™-M0+ MCU. The following development kits were used for these
these
The
MCUs: tests were performed onSTM32 two MCUs: STM32F407IG ARM Cortex™-M4 MCU and
MCUs: KEIL
KEIL MCBSTM32F400
MCBSTM32F400 and and STM32 NUCLEO-L053R8.
NUCLEO-L053R8. These These two
two architectures
architectures areare not
not similar
similar
STM32L053R8
although ARM
both are Cortex™-M0+
based on a MCU.
32-bit RISC The following
processor. ARM development
Cortex M0
although both are based on a 32-bit RISC processor. ARM Cortex M0 + used a Von Neumann + kits
used were
a Von used
Neumannfor these
MCUs: architecture
KEIL with
MCBSTM32F400instruction
and pipelining
STM32 of two stages.
NUCLEO-L053R8. The ARM
These Cortex
two
architecture with instruction pipelining of two stages. The ARM Cortex M4 used a Harvard M4 used
architectures a Harvard
are not similar
although both are based on a 32-bit RISC processor. ARM Cortex M0 + used a Von Neumann
architecture with instruction pipelining of two stages. The ARM Cortex M4 used a Harvard architecture
with Instruction pipelining of three stages. For the STM32F407IG ARM Cortex™-M4 MCU, the system
Symmetry 2020, 12, 592 7 of 19

clock was setup at 168 MHz (the source is a high-speed external clock of 25MHz with PLL activated)
and for the STM32L053R8 ARM Cortex™-M0+ MCU, the system clock was setup at 32 MHz (the source
is high-speed internal clock with PLL activated). The purpose is to compare the performances of the
RTOSs on the same MCU, not on different MCUs. We used two MCUs to see whether performance
differences between RTOSs are the same on different MCUs. On the two chosen microcontroller
architectures, a wide range of devices with hard/soft real-time capabilities can be designed and
developed based on real-time operating systems.
RTOSs were configured with fully preemptive scheduling, without round-robin (a single task
on a priority level) and with the internal tick clock of 1 ms. For all software applications, we used
the latest compiler (V5.06 update 6 build 750) included in the KEIL MDK-ARM Pro 5.29 tools with
compiler optimization level 3 (O3).
The configurations for compiler are the same for all software applications and we used the same
functions to handle the test GPIO pin. For the STM32L053R8 ARM Cortex™-M0+ MCU we used the
PC port, pin 13 as test pin, and for STM32F407IG ARM Cortex™-M4 MCU we used the GPIOH port,
pin 3 as test pin.
For this reason, the differences related to the time performances are due only to the way of
implementation of each RTOS. Regarding the measured values, the measurements errors are generated
by the oscilloscope (we used the PicoScope 2205MSO—that provides a vertical resolution up to 12 bits
and a time base accuracy of ±100 ppm).
For each chosen MCU, there are developed three software applications for each RTOS, one for
mailboxes, one for semaphores, and one for events. These software applications consist of 2 tasks
and, with conditional compilation, one of the 4 scenarios defined in this section is activated. Some
examples for the code for the tasks are shown in Appendix A for FreeRTOS when semaphores are used,
Appendix B for uC/OS-II RTOS when events are used, Appendix C for rt-thread when mailboxes are
used, and Appendix D for Keil RTX when events are used. With the help of the RTOS_TEST macro, one
of the 4 scenarios is activated. In addition, from these examples, you can see that the same functions
are used to handle the test pin. It can be observed that the operations are executed periodically, at
every 1 ms, to capture any jitter that may occur. The used oscilloscope is capable to detect and to
measure this jitter. The jitter is very important in determining the worst-case execution time (WCET),
which is very important for hard real-time systems.

4. Experimental Results and Discussions

In this section, the results obtained for the tests described in the previous section are presented.
The tests were performed on two MCUs: STM32F407IG ARM Cortex™-M4 MCU and STM32L053R8
ARM Cortex™-M0+ MCU.
For the measurements, we used the PicoScope 2205MSO oscilloscope. The operations are
periodically triggered at every 1 ms and the presence of jitter can be detected on the oscilloscope (the
jitter is determined by the oscilloscope, not by software). The test pin was connected to the analog part
of the oscilloscope, we used a threshold of 3 V was used to detect the start of the operation (to detect
the transition from 0 V to 3.3 V), and we used a timebase of 5 µs/div.
All operations are performed periodically and the oscilloscope can easily detect the present of
jitter. The jitter of 1 ms clock tick is not present because each operation is triggered at the end of
the clock tick interrupt and is much shorter by 1 ms. All measurements were performed in a series.
The uncertainty budget of the time measurement is generated by the errors generated by the PicoScope
2205MSO oscilloscope that provides a vertical resolution up to 12 bits and a time base accuracy of
±100 ppm. For a timebase of 5 us, the uncertainty budget of the time measurement is of ± 0.5 ns.
Symmetry 2020, 12, 592 8 of 19

Figure 5, Figure 6, and Figure 7 present the results obtained for the first scenario when a task
context switch is triggered by an event, semaphore, and mailbox. From these figures, it can be observed
that the smallest latency is obtained by Keil RTX when events are used, by rt-thread and Keil RTX
whenSymmetry
semaphores
2020, 12,are used,
x FOR PEERand by FreeRTOS0 and Keil RTX when mailboxes are used. It can
REVIEW 8 ofbe
19 seen
Symmetry 2020, 12, x FOR PEER REVIEW 8 of 19
Symmetry
that there are2020, 12, x differences
small FOR PEER REVIEW between STM32F407IG ARM Cortex ™ -M4 and STM32L053R8 8 of 19ARM

CortexCortex
™ -M0+™ -M0+MCUs MCUs regarding
regarding latencies
latencies obtained byRTOS
obtained RTOS systems (comparison
(comparison between RTOSs
Cortex ™ -M0+ MCUs regarding latencies obtainedby
by RTOSsystems betweenRTOSs
systems (comparison between RTOSs on
Cortex ™ -M0+
on the same MCU).MCUs regarding
In the latencies
first case, no jitterobtained
appearsby RTOS
in the systems
latency (comparison
measurement (thebetween RTOSs
task switching
the same
on theMCU). In the In
same MCU). first
thecase, no jitter
first case, appears
no jitter in in
appears thethe
latency
latencymeasurement
measurement (the (thetask
task switching is
switching
on the same MCU).
is periodically In the first
triggered case, no
at every jitterand
1 ms appears
the in the latency
presence measurement
of jitter could be(the task switching
observed on the
is periodically
periodically triggered triggered
at every at every 1 ms and the presence of jitter could be observed on the
is periodically
oscilloscope). triggered at 1every
ms and the and
1 ms presence of jitter could
the presence be could
of jitter observed on the oscilloscope).
be observed on the
oscilloscope).
oscilloscope).

Figure 5. The
5. The time
timetime for
forfor task
task switching fromthe
switching the lowest priority task to thethe
higher priority task triggered
Figure
Figure 5. The task switchingfrom
from the lowest prioritytask
lowest priority task
toto higher
the higher priority
priority task task triggered
triggered
Figure
by an 5. The(scenario
event time for task
1). switching from the lowest priority task to the higher priority task triggered
by anby
event (scenario
an event 1). 1).
(scenario
by an event (scenario 1).

Figure 6. The time for task switching from the lowest priority task to the higher priority task triggered
Figure 6. The
The timetime
forfor task
task switching fromthe
switching the lowest priority task to thethe
higher priority task triggered
Figure
by6.
Figure 6. The
a semaphoretime for task
(scenario switchingfrom
1). from the lowest prioritytask
lowest priority task
toto higher
the higher priority
priority task task triggered
triggered
by a semaphore
by a semaphore (scenario
(scenario 1). 1).
by a semaphore (scenario 1).

Figure 7. The time for task switching from the lowest priority task to the higher priority task triggered
Figure
The7. The time
time for
forfor task
task switching fromthe
switching the lowest priority task to thethe
higher priority task triggered
Figure
by7.
Figure 7. The
a mailbox time
(scenariotask
1). switchingfrom
from the lowest prioritytask
lowest priority task
toto higher
the higher priority
priority task task triggered
triggered
by a mailbox (scenario 1).
by a mailbox (scenario
by a mailbox 1). 1).
(scenario
The latency measurement is performed using a GPIO pin, and the time for port handling is the
The latency measurement is performed using a GPIO pin, and the time for port handling is the
sameThe
for latency measurement
each RTOS. is performed
Furthermore, each RTOSusing
hasathe
GPIOsamepin,latency
and the time for port
generated by thehandling is the
access of the
same for each RTOS. Furthermore, each RTOS has the same latency generated by the access of the
same for each RTOS. Furthermore, each RTOS has the same latency generated by the access of the
Symmetry 2020, 12, 592 9 of 19

The latency measurement is performed using a GPIO pin, and the time for port handling is the
same for each RTOS. Furthermore, each RTOS has the same latency generated by the access of the
GPIOSymmetry
port that
Symmetry
2020, 12, x FOR PEER REVIEW
2020,is12,
connected
x FOR PEER to the peripheral bus of the MCU. Usually, embedded systems must
REVIEW
9 of 19
9 of 19 react
to external events that are received via peripherals (GPIO, ADC,
GPIO port that is connected to the peripheral bus of the MCU. Usually, embedded systems must react UART, CAN, etc.) and the reaction
GPIO port that is connected to the peripheral bus of the MCU. Usually, embedded systems must react
can be sent further through peripherals (GPIO, DAC, UART, CAN,
to external events that are received via peripherals (GPIO, ADC, UART, CAN, etc.) and the reaction etc.). For this reason, we consider
to external events that are received via peripherals (GPIO, ADC, UART, CAN, etc.) and the reaction
that the
canuse of afurther
be sent GPIO pin through to measure
peripherals latency(GPIO,canDAC,bringUART,
us closer
CAN, to etc.).
the real
For functioning
this reason, we of consider
the real-time
can be sent further through peripherals (GPIO, DAC, UART, CAN, etc.). For this reason, we consider
systemthatthat
the was
use of developed
a GPIO pin based on
to measure an RTOS.
latency can bring us closer to the real functioning of the real-
that the use of a GPIO pin to measure latency can bring us closer to the real functioning of the real-
time results
The system thatfor thewasseconddeveloped based are
scenario on an RTOS. in Figure 8, Figure 9, and Figure 10. As can be
presented
time system that was developed based on an RTOS.
seen fromTheThe results
theresults
figures, for in the second
this case, scenario
jitter is are presented
present during in Figures 8, 9, and 10.
task switching. The Asjitter
can be seen from
results fromthe the fact
for the second scenario are presented in Figures 8, 9, and 10. As can be seen from the
figures,
that the secondin this
task case,
sets jitter
the is
test present
pin to during
1 task
(HIGH/TRUE) switching.in anThe jitter
infinite results
loop from
and it the
is fact
preemptedthat the by the
figures, in this case, jitter is present during task switching. The jitter results from the fact that the
second task sets the test pin to 1 (HIGH/TRUE) in an infinite loop and it is preempted by the higher
highersecond tasktask
priority sets thewhile testitpinsetsto the
1 (HIGH/TRUE)
pin. The preemption in an infinite loop andcan
moments it isinfluence
preemptedthe by time
the higher
when the
priority task while it sets the pin. The preemption moments can influence the time when the task is
priority
task is resumed taskandwhile sets it sets the pin.
the test pin The
to 1 preemption
(HIGH/TRUE). moments can influence
In addition, there the
is antime when the
influence task is by
generated
resumed and sets the test pin to 1 (HIGH/TRUE). In addition, there is an influence generated by the
resumed and sets routine
the interrupt the test pin to 1 (HIGH/TRUE). In addition, there is can
an influence generated by the
interrupt service
service routine for forthethe clock
clock tick.tick.
From From the figures,
the figures, we canwe see thatseethethat the smallest
smallest latency and latency
interrupt service routine for the clock tick. From the figures, we can see that the smallest latency and
and the
the smallest jitterisisobtained
smallest jitter obtained byby uC/OS-II
uC/OS-II andand the highest
the highest latencylatency is obtained
is obtained by the rt-thread
by the rt-thread in the in
the smallest jitter is obtained by uC/OS-II and the highest latency is obtained by the rt-thread in the
the case of events and mailboxes and by FreeRTOS9
case of events and mailboxes and by FreeRTOS9 in the case of semaphores. in the case of semaphores.
case of events and mailboxes and by FreeRTOS9 in the case of semaphores.
In Figure 11, Figure
In Figures 11, 12, 12, andand 13 theFigure
results 13forthethe
results
third for the third
scenario scenario are
are presented.
In Figures 11, 12, and 13 the results for the third scenario are presented. In this case, the time is
presented.
In this case, the In time this
is case,
measured
the time is when an
measured when event an isevent
triggered,
is a semaphore
triggered, a is issued,isor
semaphore a message
issued, or a is sent. For
message is eventsFor
sent. and events
measured when an event is triggered, a semaphore is issued, or a message is sent. For events and
semaphores, the
and semaphores, the lowest
lowest latency
latency is isobtained
obtained forforrt-thread
rt-thread andand
for for
mailboxes,
mailboxes, the lowest
the latency
lowest is
latency is
semaphores, the lowest latency is obtained for rt-thread and for mailboxes, the lowest latency is
obtained
obtained for uC/OS-II.
for uC/OS-II. For
ForFor events
events and semaphores, the highest latency is obtained for FreeRTOS10,
obtained for uC/OS-II. eventsand andsemaphores,
semaphores, the thehighest
highestlatency
latency is obtained
is obtained for FreeRTOS10,
for FreeRTOS10,
and for mailboxes, Keil RTX obtains the lowest latency.
andmailboxes,
and for for mailboxes, KeilKeil RTX RTX obtains
obtains the thelowest
lowestlatency.
latency.

Figure 8. Time
8. Time for for
tasktask switchingfrom
switching from thelowest
lowest priority
prioritytask
taskto the higher priority tasktask
triggered by by
Figure
Figure 8. Time for task switching fromthe the lowest priority task toto the
the higher
higher priority
priority triggered
task triggered by
an event
an event (the (the values
values fromfrom the
the top
top arethe
are thejitters)
jitters) (scenario
(scenario 2).
2).
an event (the values from the top are the jitters) (scenario 2).

Figure 9. Time for task switching from the lowest priority task to the higher priority task triggered by
Figure
Figure 9. Time
9. Time for task
for task switching
switching from
from thelowest
the lowestpriority
priority task
task to
tothe
thehigher
higherpriority
prioritytask triggered
task by by a
triggered
a semaphore event (the values from the top are the jitters (scenario 2).
a semaphore event (the values from the top are the jitters (scenario
semaphore event (the values from the top are the jitters (scenario 2). 2).
Symmetry 2020, 12, 592 10 of 19

Symmetry 2020,
Symmetry 2020, 12,
12, xx FOR
FOR PEER
PEER REVIEW
REVIEW 10 of
10 of 19
19

Figure 10. The

Figure 10. time for task
The time for switching fromfrom
task switching the lowest priority
the lowest task to
priority thetohigher
task priority
the higher task triggered
priority task
by a mailbox
triggered(the
by a values
mailboxfrom the topfrom
(the values are the
thetop
jitters) (scenario
are the 2).
jitters) (scenario 2).

Figure 11. The

Figure execution
11. The time
execution timeforforthe
theprimitive
primitive that signalan
that signal anevent
event that
that is not
is not waited
waited byother
by the the other
task task
(unblocking
(unblocking send)send) (scenario
(scenario 3).3).

FigureFigure 12. The

12. The execution
execution time
time forforthe
theprimitive
primitive that
that signal
signalaasemaphore
semaphorethat is not
that waited
is not by the
waited byother
the other
task (unblocking send) (scenario 3).
task (unblocking send) (scenario 3).
Symmetry 2020, 12, 592 11 of 19
Symmetry 2020, 12, x FOR PEER REVIEW 11 of 19
Symmetry 2020,
Symmetry 2020, 12,
12, xx FOR
FOR PEER
PEER REVIEW
REVIEW 11 of
11 of 19
19

Figure
Figure 13. The
13. The execution
execution timetime
for for
thethe primitive
primitive that
that send
send a mailboxthat
a mailbox thatisisnot
notwaited
waited by
by the
the other
other task
task (unblocking
Figure 13.
(unblocking 13.
send) send)
The (scenario(scenario
execution 3).
time for3).
for the
the primitive
primitive that
that send
send aa mailbox
mailbox that
that is
is not
not waited
waited by
by the
the other
other
Figure The execution time
task (unblocking
task (unblocking send)
send) (scenario
(scenario 3).
3).
FigureFigures 14, 15, 15,
14, Figure andand
16 present
Figurethe16 results
presentforthe
theresults
fourth scenario. In this scenario.
for the fourth case, it is measured the it is
In this case,
time Figures
when an 14, event,
15, andsemaphore
16 present or
the mailbox
results is the
for received.
fourth The results
scenario. In are
this similar
case, it to measured
is the previous
the
measuredFigures
the time 14, when
15, andan16 event,
presentsemaphore
the results fororthe
mailbox
fourth is received.
scenario. Thecase,
In this results are similar
it is measured theto the
scenario,
time whenin the sense that
an event,
event, for events
semaphore orand semaphores,
mailbox the highest
is received.
received. latencyare
The results
results is obtained
similar to forthe
to FreeRTOS10
previous
time when an semaphore or mailbox is The are similar
previous scenario, in the sense that for events and semaphores, the highest latency is obtained for the previous
and for the
scenario, mailboxes
in the
the sense Keilfor
sense that RTX obtains
events andthe lowest latency.
semaphores, the highest
highest latency
latency is
is obtained
obtained for
for FreeRTOS10
FreeRTOS10
scenario,
FreeRTOS10 in
and for the that for events
mailboxes and
Keil semaphores,
RTX obtains the the lowest latency.
and for
and for the
the mailboxes
mailboxes Keil
Keil RTX
RTX obtains
obtains the
the lowest
lowest latency.
latency.

Figure 14. The execution time for the primitive used to receive an existing event (unblocking wait)
(scenario
Figure
Figure 14.4).
14. The execution
The time
execution for
time forthe
theprimitive usedto
primitive used
used toreceive
to receivean
receive anan existing
existing event
event (unblocking
(unblocking wait)wait)
Figure 14. The execution time for the primitive existing event (unblocking wait)
(scenario
(scenario 4). 4).
(scenario 4).

Figure 15. The execution time for the primitive used to receive an existing semaphore (unblocking
wait) (scenario
Figure 15. The 4).
The execution
execution time for
for the
the primitive
primitive used
used to
to receive
receive an existing semaphore
semaphore (unblocking
(unblocking
Figure
Figure 15.
15. The time
execution time for the primitive used to receiveananexisting
existing semaphore (unblocking
wait) (scenario 4).
wait) (scenario 4).
wait) (scenario 4).
Symmetry 2020, 12, 592 12 of 19

Symmetry 2020, 12, x FOR PEER REVIEW 12 of 19

Figure 16. The

Figure execution
16. The time
execution forforthe
time theprimitive
primitive used toreceive
used to receiveanan existing
existing mailbox
mailbox (unblocking
(unblocking wait) wait)
(scenario
(scenario 4). 4).

The measurement
The measurement errorerror is the
is the samefor
same forall
allcases
cases because
becausethethesame
same oscilloscope
oscilloscope is used. All RTOSs
is used. All RTOSs
use supervisor call (SVC) interrupt to perform task switching, but there are differenceshow
use supervisor call (SVC) interrupt to perform task switching, but there are differences in the the
in how
directives for communication mechanisms are executed, and how the queues of different events
directives for communication mechanisms are executed, and how the queues of different events (event,
(event, semaphore, and mailbox) are accessed internally.
semaphore, and mailbox) are accessed internally.
Furthermore, scenarios for measurement of the energy consumption can be made, but this is
Furthermore, scenarios for measurement of the energy consumption can be made, but this is
dependent on the hardware platform used and as long as the MCU and other components enter the
dependent on the
low power hardware mode.
consumption platform On used
the sameand hardware
as long asplatform,
the MCU and other
energy components
consumption enter the
is directly
low power consumption
proportional mode.time
to the execution Onthattheissame hardware
measured platform,
in the scenarios energy in
proposed consumption
this article. is directly
proportional to the execution
Analyzing time
the results for thethat
fourisscenarios,
measured weincan
thesay
scenarios
that the proposed
best RTOS in this article.
performers are uC/
OS-II, Keil RTX,
Analyzing and rt-thread.
the results for theFreeRTOS, which iswe
four scenarios, thecan
most
sayused
thatRTOS in embedded
the best projects, does
RTOS performers are uC/
OS-II,not have
Keil the and
RTX, best rt-thread.
latency performances
FreeRTOS,but the performances
which are close
is the most used RTOSto the other RTOSsprojects,
in embedded tested in does
our case.
not have Thelatency
the best differences appear in the
performances butway the of implementation
performances are of the to
close access to internal
the other RTOSs queues
testedforin our
events, semaphores, and mailboxes.
case. The differences appear in the way of implementation of the access to internal queues for events,
Also, when a RTOS is selected to design and develop applications with real-time capabilities,
semaphores, and mailboxes.
other elements such as licensing mode, memory footprint, predictability, certifications, and support
Also, when
provided musta RTOS is selectedUsually,
be considered. to design andare
there develop applications
preferred mature RTOSs with real-time
that havecapabilities,
proven theirother
elements such as licensing mode, memory footprint, predictability, certifications,
functionality and efficiency in developing other applications with real-time capabilities. and support provided
must be considered. Usually, there are preferred mature RTOSs that have proven their functionality
5. Conclusions
and efficiency in developing other applications with real-time capabilities.
This paper presented an analysis and comparison in terms of timing performances for task
5. Conclusions
synchronization throughout events, semaphore, and mailboxes for six RTOSs (uC-OS/II, uC/OS-III,
FreeRTOS
This paper9.0.0, FreeRTOS
presented an 10.2.0, RT-Thread,
analysis and Keil RTX)
and comparison that are
in terms widely used
of timing to design and
performances for task
develop applications on small MCUs. We measured the time for task switching
synchronization throughout events, semaphore, and mailboxes for six RTOSs (uC-OS/II, uC/OS-III, triggered by an event,
semaphore, and mailbox and we compared the time achieved by the chosen RTOSs on ARM
FreeRTOS 9.0.0, FreeRTOS 10.2.0, RT-Thread, and Keil RTX) that are widely used to design and develop
Cortex™-M4 and STM32L053R8 ARM Cortex™-M0+ based MCUs. In addition, we measured the
applications on small MCUs. We measured the time for task switching triggered by an event, semaphore,
latencies for the directives used to send/receive an event, semaphore, and mailbox. From the
and mailbox and we compared the time achieved by the chosen RTOSs on ARM Cortex™-M4 and
experimental results, we can conclude that the best performances are achieved for uC/ OS-II, Keil
STM32L053R8 ARM Cortex™-M0+
RTX, and rt-thread. based MCUs.
The lower performances In to
(close addition,
the othersweRTOSs)
measured are the latencies
achieved by thefor the
directives usedalthough
FreeRTOS to send/receive an event,
it is the most semaphore,
used RTOS and mailbox.
in embedded projects. From thebe
It should experimental
mentioned that results,
the we
can conclude
tests werethat the bestfor
performed performances
small MCUs,are andachieved for uC/no
for this reason, OS-II, KeilofRTX,
variants Linuxand rt-thread.
based RTOSs The havelower
been tested.
performances Although
(close to thethe timingRTOSs)
others is the most
areimportant
achievedparameter in a hard or
by the FreeRTOS a soft real-time
although it is thesystem,
most used
we must consider that we need to include other criteria in selecting an RTOS,
RTOS in embedded projects. It should be mentioned that the tests were performed for small MCUs, and such as licensing,
memory
for this reason, footprint, predictability,
no variants of Linuxcertifications,
based RTOSs and support
have beenprovided. The results
tested. Although presented
the timing is in the
thismost
paper may represent an indication for selecting an RTOS in terms of response time to the occurrence
important parameter in a hard or a soft real-time system, we must consider that we need to include
of a critical event (periodic or aperiodic), and which is the most efficient synchronization mechanism
other criteria in selecting an RTOS, such as licensing, memory footprint, predictability, certifications,
for the selected RTOS.
and support provided. The results presented in this paper may represent an indication for selecting an
RTOS in terms of response time to the occurrence of a critical event (periodic or aperiodic), and which
is the most efficient synchronization mechanism for the selected RTOS.
Symmetry 2020, 12, 592 13 of 19
Symmetry 2020, 12, x FOR PEER REVIEW 13 of 19

Conflicts of
Conflicts of Interest:
Interest: The
The author
author declare
declare no
no conflict
conflict of
of interest.
interest. The
Thefunders
fundershadhadno
norole
roleininthe
thedesign
designofofthe
the study;
in the collection,
study; analyses,
in the collection, or interpretation
analyses, of data;
or interpretation in the
of data; in writing of the
the writing manuscript,
of the oror
manuscript, inin
the
thedecision
decisiontotopublish
the results.
publish the results.

Appendix A
Appendix A
This appendix
appendix contains the code
contains the code for two tasks of the
the test
test software
software application
application for FreeRTOS
FreeRTOS RTOS
RTOSsemaphores
when when semaphores are used.
are used.

void Task1 (void *argument)

{
/* Attempt to create a semaphore. */
xSemaphore = xSemaphoreCreateBinary();
while (1)
{
#if (RTOS_TEST == TEST1)
xSemaphoreTake(xSemaphore, 10000);
PIN_On(0);
#elif (RTOS_TEST == TEST2)
vTaskDelay(1); // delay 1 ticks = 1ms
PIN_Off(0);
xSemaphoreTake(xSemaphore, 1);
PIN_Off(0);
#elif (RTOS_TEST == TEST3)
xSemaphoreGive( xSemaphore );
vTaskDelay(1); // delay 1 ticks = 1ms
PIN_Off(0);
xSemaphoreTake(xSemaphore, 10000);
PIN_On(0);
#elif (RTOS_TEST == TEST4)
vTaskDelay(1); // delay 1 ticks = 1ms
PIN_Off(0);
xSemaphoreGive( xSemaphore );
PIN_On(0);
xSemaphoreTake(xSemaphore, 10000);

#else
osDelay(1);
#endif
}
}
void Task2 (void *argument)
{
while (1)
{
#if (RTOS_TEST == TEST1)
Symmetry 2020, 12, 592 14 of 19
Symmetry 2020, 12, x FOR PEER REVIEW 14 of 19
Symmetry 2020, 12, x FOR PEER REVIEW 14 of 19

vTaskDelay(1); // delay 1 ticks = 1ms

vTaskDelay(1); // delay 1 ticks = 1ms
PIN_Off(0);
PIN_Off(0);
xSemaphoreGive( xSemaphore );
xSemaphoreGive( xSemaphore );
#elif (RTOS_TEST == TEST2)
#elif (RTOS_TEST == TEST2)
PIN_On(0);
PIN_On(0);
#elif (RTOS_TEST == TEST3)
#elif (RTOS_TEST == TEST3)
vTaskDelay(1); // delay 1 ticks = 1ms
vTaskDelay(1); // delay 1 ticks = 1ms
#elif (RTOS_TEST == TEST4)
#elif (RTOS_TEST == TEST4)
vTaskDelay(1); // delay 1 ticks = 1ms
vTaskDelay(1); // delay 1 ticks = 1ms
#else
#else
vTaskDelay(1); // delay 1 ticks = 1ms
vTaskDelay(1); // delay 1 ticks = 1ms
#endif
#endif
}
}
}
}

Appendix B
Appendix B
Appendix B
This appendix
This appendix contains
contains the code
code for
for two
two tasks
tasks of
of the test
test software
software application
application uC/OS-II
uC/OS-II RTOS
RTOS
This appendix containsthe the code for two tasksthe
of the test software application uC/OS-II RTOS
when events
when events are
events are used.
when areused.
used.
void Task1 (void *argument)
void Task1 (void *argument)
{
{
OS_ERR err;
OS_ERR err;
while (1)
while (1)
{
{
#if (RTOS_TEST == TEST1)
#if (RTOS_TEST == TEST1)
// wait until bit 0 is 0
// wait until bit 0 is 0
OSFlagPend(flg_grp, 0x01, OS_FLAG_WAIT_CLR_ALL, 0, &err);
OSFlagPend(flg_grp, 0x01, OS_FLAG_WAIT_CLR_ALL, 0, &err);
PIN_On(0);
PIN_On(0);
OSFlagPost(flg_grp, 0x01, OS_FLAG_SET, &err); // set bit 0
OSFlagPost(flg_grp, 0x01, OS_FLAG_SET, &err); // set bit 0
#elif (RTOS_TEST == TEST2)
#elif (RTOS_TEST == TEST2)
PIN_Off(0);
PIN_Off(0);
// wait until bit 0 is 0
// wait until bit 0 is 0
OSFlagPend(flg_grp, 0x01, OS_FLAG_WAIT_CLR_ALL, 2u, &err);
OSFlagPend(flg_grp, 0x01, OS_FLAG_WAIT_CLR_ALL, 2u, &err);
#elif (RTOS_TEST == TEST3)
#elif (RTOS_TEST == TEST3)
OSFlagPost(flg_grp, 0x01, OS_FLAG_CLR, &err); //reset bit 0
OSFlagPost(flg_grp, 0x01, OS_FLAG_CLR, &err); //reset bit 0
OSTimeDlyHMSM(0,0,0,1); // wait 1ms
OSTimeDlyHMSM(0,0,0,1); // wait 1ms
PIN_Off(0);
PIN_Off(0);
// wait until bit 0 is 0
// wait until bit 0 is 0
OSFlagPend(flg_grp, 0x01, OS_FLAG_WAIT_CLR_ALL, 0, &err);
OSFlagPend(flg_grp, 0x01, OS_FLAG_WAIT_CLR_ALL, 0, &err);
PIN_On(0);
PIN_On(0);
OSFlagPost(flg_grp, 0x01, OS_FLAG_SET, &err); // set bit 0
OSFlagPost(flg_grp, 0x01, OS_FLAG_SET, &err); // set bit 0
#elif (RTOS_TEST == TEST4)
#elif (RTOS_TEST == TEST4)
OSTimeDlyHMSM(0,0,0,1); // wait 1ms
OSTimeDlyHMSM(0,0,0,1); // wait 1ms
PIN_Off(0);
PIN_Off(0);
Symmetry 2020, 12, 592 15 of 19
Symmetry 2020,
Symmetry 2020, 12,
12, xx FOR
FOR PEER
PEER REVIEW
REVIEW 15 of
15 of 19
19

OSFlagPost(flg_grp, 0x01, OS_FLAG_CLR, &err); //reset bit 0

PIN_On(0);
// wait until bit 0 is 0
OSFlagPend(flg_grp, 0x01, OS_FLAG_WAIT_CLR_ALL, 0, &err);
OSFlagPost(flg_grp, 0x01, OS_FLAG_SET, &err); // set bit 0
#else
osDelay(1);
#endif
}
}
void Task2 (void *argument)
{
OS_ERR err;

while (1)
{
#if (RTOS_TEST == TEST1)
OSTimeDlyHMSM(0,0,0,1); // wait 1ms
PIN_Off(0);
OSFlagPost(flg_grp, 0x01, OS_FLAG_CLR, &err); //reset bit 0

#elif (RTOS_TEST == TEST2)

PIN_On(0);
#elif (RTOS_TEST == TEST3)
OSTimeDlyHMSM(0,0,0,1); // wait 1ms
#elif (RTOS_TEST == TEST4)
OSTimeDlyHMSM(0,0,0,1); // wait 1ms
#else
OSTimeDlyHMSM(0,0,0,1); // wait 1ms
#endif
}
}

Appendix C
Appendix C
This appendix
This appendixcontains
containsthe code
the forfor
code two tasks
two of the
tasks test test
of the software application
software rt-thread
application RTOS RTOS
rt-thread
when mailboxes are used.
when mailboxes are used.

void Task1 (void *argument)

{
rt_uint32_t e;
while (1)
{
#if (RTOS_TEST == TEST1)
rt_mb_recv(mailboxTest, &e, RT_WAITING_FOREVER);
Symmetry 2020, 12, 592 16 of 19
Symmetry 2020, 12, x FOR PEER REVIEW 16 of 19

PIN_On(0);
#elif (RTOS_TEST == TEST2)
rt_thread_delay(1);//wait 1ms
PIN_Off(0);
rt_mb_recv(mailboxTest, &e, 1u);
PIN_Off(0);
#elif (RTOS_TEST == TEST3)
rt_mb_send(mailboxTest,0);
rt_thread_delay(1);//wait 1ms
PIN_Off(0);
rt_mb_recv(mailboxTest, &e, RT_WAITING_FOREVER);
PIN_On(0);
#elif (RTOS_TEST == TEST4)
rt_thread_delay(1);//wait 1ms
PIN_Off(0);
rt_mb_send(mailboxTest,0);
PIN_On(0);
rt_mb_recv(mailboxTest, &e, RT_WAITING_FOREVER);
#else
osDelay(1);
#endif
}
}

void Task2 (void *argument)

{
while (1)
{
#if (RTOS_TEST == TEST1)
rt_thread_delay(1);//wait 1ms
PIN_Off(0);
rt_mb_send(mailboxTest,0);
#elif (RTOS_TEST == TEST2)
PIN_On(0);
#elif (RTOS_TEST == TEST3)
rt_thread_delay(1);//wait 1ms
#elif (RTOS_TEST == TEST4)
rt_thread_delay(1);//wait 1ms
#else
rt_thread_delay(1);//wait 1ms
#endif
}
}
Symmetry 2020, 12, 592 17 of 19
Symmetry 2020, 12, x FOR PEER REVIEW 17 of 19

Appendix
Appendix D
D
This
This appendix containsthe
appendix contains thecode
codeforfor two
two tasks
tasks of the
of the testtest software
software application
application forRTX
for Keil KeilRTOS
RTX RTOS
when
whensemaphores are used.
semaphores are used.

void Task1(void *argument)

{
semaphore = osSemaphoreCreate(osSemaphore(semaphore), 0);
while (1)
{
#if (RTOS_TEST == TEST1)
osSemaphoreWait(semaphore, osWaitForever);
PIN_On(0);
#elif (RTOS_TEST == TEST2)
osDelay(1);
PIN_Off(0);
osSemaphoreWait(semaphore, 1U);
PIN_Off(0);
#elif (RTOS_TEST == TEST3)
osSemaphoreRelease(semaphore);
osDelay(1);
PIN_Off(0);
osSemaphoreWait(semaphore, osWaitForever);
PIN_On(0);
#elif (RTOS_TEST == TEST4)
osDelay(1);
PIN_Off(0);
osSemaphoreRelease(semaphore);
PIN_On(0);
osSemaphoreWait(semaphore, osWaitForever);
#else
osDelay(1);
#endif
}
}
void Task2 (void *argument)
{
while (1)
{
#if (RTOS_TEST == TEST1)
osDelay(1); // wait 1ms
PIN_Off(0);
osSemaphoreRelease (semaphore);
#elif (RTOS_TEST == TEST2)
PIN_On(0);
Symmetry 2020, 12, 592 18 of 19
Symmetry 2020, 12, x FOR PEER REVIEW 18 of 19

#elif (RTOS_TEST == TEST3)

osDelay(1);
#elif (RTOS_TEST == TEST4)
osDelay(1);
#else
osDelay(1);
#endif
}
}

References
References
1. Richard, Z. The Industrial Information Technology Handbook, 1st ed.; CRC Press: Boca Raton, FL, USA, 2018;
1. Richard, Z. The Industrial Information Technology Handbook, 1st ed.; CRC Press: Boca Raton, FL, USA,
1936p.
2018; 1936p.
2. Anh, T.N.B.; Tan, S. Real-Time Operating Systems for Small Microcontrollers. IEEEMicro 2009, 29, 30–45.
2. Anh, T.N.B.; Tan, S. Real-Time Operating Systems for Small Microcontrollers. IEEEMicro 2009, 29, 30–45.
3. Cinque, M.; De Tommasi, G. Work-in-Progress: Real-Time Containers for Large-Scale Mixed-Criticality
[CrossRef]
Systems. In Proceedings of the 2017 IEEE Real-Time Systems Symposium (RTSS), Paris, France, 5–8
3. Cinque,
DecemberM.; 2017;Depp.
Tommasi,
369–371. G. Work-in-Progress: Real-Time Containers for Large-Scale Mixed-Criticality
4. Systems. In Proceedings of the 2017 IEEEcircuit
Nuratch, S. A universal microcontroller Real-Time Systems Symposium
and firmware (RTSS), Paris, France,
design and implementation 5–8 December
for IoT-based
2017; pp. measurement
realtime 369–371. and control applications. In Proceedings of the 2017 International Electrical
4. Nuratch,
Engineering S. Congress
A universal microcontroller
(iEECON), circuit and
Pattaya, Thailand, 8–10firmware
March 2017; design and implementation for IoT-based
pp. 1–4.
5. Zikria, Y.B.;
realtime Kim, S.W.; Hahm,
measurement and O.; Afzal,applications.
control M.K.; Aalsalem,InM.Y. Internet of Things
Proceedings of the (IoT)
2017Operating Systems
International Electrical
Management:Congress
Engineering Opportunities, Challenges,
(iEECON), andThailand,
Pattaya, Solution. Sensors 2019, 19,
8–10 March 1793.
2017; pp. 1–4.
5.6. Buttazzo,
Zikria, G.C.
Y.B.; Kim,HardS.W.;Real-Time
Hahm, O.; Computing Systems:
Afzal, M.K.; Predictable
Aalsalem, M.Y.Scheduling
Internet ofAlgorithms and Operating
Things (IoT) Applications;Systems
Springer: Berlin/Heidelberg, Germany, 2011.
Management: Opportunities, Challenges, and Solution. Sensors 2019, 19, 1793. [CrossRef] [PubMed]
6.7. de Oliveira,
Buttazzo, G.C.D.B.; de Real-Time
Hard Oliveira, R.S. Timing Systems:
Computing analysis of the PREEMPT_RT
Predictable SchedulingLinux kernel.
Algorithms and Softw. Pract. Exp.
Applications; Springer:
2016, 46, 789–819.
Berlin/Heidelberg, Germany, 2011.
8. Zhang, X.; Lu, F.; Cui, M. A review of OSEK/VDX application verification methods. In Proceedings of the
7. De Oliveira, D.B.; de Oliveira, R.S. Timing analysis of the PREEMPT_RT Linux kernel. Softw. Pract. Exp.
5th International Conference on Communication and Information Processing (ICCIP’19). Association for
2016, 46, 789–819. [CrossRef]
Computing Machinery, New York, NY, USA, 15–17 November 2019; pp. 37–42.
8. Zhang, X.; Lu, F.; Cui, M. A review of OSEK/VDX application verification methods. In Proceedings of the
9. Delgado, R.; Park, J.; Choi, B.W. Open Embedded Real-time Controllers for Industrial Distributed Control
5th International Conference on Communication and Information Processing (ICCIP’19). Association for
Systems. Electronics 2019, 8, 223.
10. Computing
Belesioti, M.;Machinery,
Makri, R.; New York, NY, USA,
Fehling-Kaschek, 15–17 M.;
M.; Carli, November 2019; pp.
Kostopoulos, 37–42.
A.; Chochliouros, I.P.; Neri, A.;
9. Delgado,
Frosali, F. R.;
A New Park, J.; Choi,
Security B.W. Open
Approach Embedded
in Telecom Real-time Controllers
Infrastructures: The RESISTOfor Industrial
Concept. DistributedofControl
In Proceedings
Systems. Electronics
the 2019 15th 2019, 8,
International 223. [CrossRef]
Conference on Distributed Computing in Sensor Systems (DCOSS), Santorini
10. Belesioti, M.; Makri,
Island, Greece, 29–31 R.;
May Fehling-Kaschek,
2019; pp. 212–218. M.; Carli, M.; Kostopoulos, A.; Chochliouros, I.P.; Neri, A.; Frosali, F.
11. A New Security
Zhang, K.; Wu, J.; Approach in Telecom
Liu, C.; Ali, Infrastructures:
S.S.; Ren, The RESISTO
J. Behavior Modeling Concept.toInSupport
on ARINC653 Proceedings of the 2019 15th
the Temporal
Verification of Conference
International Conformed Application
on Distributed Design. IEEE Access
Computing 2019, 7, Systems
in Sensor 23852–23863.
(DCOSS), Santorini Island, Greece,
12. Alexander,
29–31 May 2019; B.; Titarenko,
pp. 212–218.L.; Mazurkiewicz, M. Foundations of Embedded Systems; Springer:
11. Zhang, K.; Wu, J.;Germany,
Berlin/Heidelberg, Liu, C.; 2019.
Ali, S.S.; Ren, J. Behavior Modeling on ARINC653 to Support the Temporal
13. Ungurean, I.; Gaitan,
Verification of Conformed N.C.; Gaitan, V.G. A
Application Middleware
Design. Based 2019,
IEEE Access Architecture for the Industrial
7, 23852–23863. [CrossRef] Internet of
12. Things. KSII Trans. Internet Inf. Syst. 2016, 10, 2874–2891.
Alexander, B.; Titarenko, L.; Mazurkiewicz, M. Foundations of Embedded Systems; Springer: Berlin/Heidelberg,
14. Ungurean, I.; Gaitan, N.C. Performance analysis of tasks synchronization for real time operating systems.
Germany, 2019.
In Proceedings of the 2018 International Conference on Development and Application Systems (DAS),
13. Ungurean, I.; Gaitan, N.C.; Gaitan, V.G. A Middleware Based Architecture for the Industrial Internet of
Suceava, Romanian, 24–26 May 2018; pp. 63–66.
Things. KSII Trans. Internet Inf. Syst. 2016, 10, 2874–2891.
15. Labrosse, J.J. MicroC/OS II; The Real Time Kernel; CMP Books: Lawrence, KS, USA, 2002.
14. Ungurean, I.; Gaitan, N.C. Performance analysis of tasks synchronization for real time operating systems.
16. Embedded Markets Study, Integrating IoT and Advanced Technology Designs, Application Development
In Proceedings of the 2018 International Conference on Development and Application Systems (DAS),
& Processing Environments. 2017. Available online: https://m.eet.com/media/1246048/2017-embedded-
Suceava, Romanian,
market-study.pdf 24–26on
(accessed May 2018; pp.2020).
14 February 63–66.
15.
17. Labrosse, J.J. MicroC/OS II; The
Real-Time Operating Systems (RTOS) Market Real Time Kernel; CMP
2019: Books: Lawrence,
Highlights KS, USA,
Recent Trends, Market2002.
Growth, Top
16. Embedded
Manufacturers Markets Study,
Analysis, Integrating
Business IoT and Advanced
Opportunities Technology
and Designs,
Demand. Application
Available Development
online: &
Processing Environments. 2017. Available online: https://m.eet.com/media/1246048/2017-embedded-market
https://www.marketwatch.com/press-release/real-time-operating-systems-rtos-market-2019-highlights-
-study.pdf (accessed on 14 February 2020).
Symmetry 2020, 12, 592 19 of 19

17. Real-Time Operating Systems (RTOS) Market 2019: Highlights Recent Trends, Market
Growth, Top Manufacturers Analysis, Business Opportunities and Demand. Available online:
https://www.marketwatch.com/press-release/real-time-operating-systems-rtos-market-2019-highlights-re
cent-trendsmarket-growthtop-manufacturers-analysisbusiness-opportunities-and-demand-2019--09-09
(accessed on 14 February 2020).
18. Guillaume, C.; Dagenais, M. Benchmarking Real Time Operating Systems. 2019. Available online: https:
//amdls.dorsal.polymtl.ca/system/files/RTOS%20%20Benchmarking.pdf (accessed on 14 February 2020).
19. Lee, J.; Kim, S.C.; Woo, D.; Ma, Y.; Mah, P. Performance comparison of MRTOS and VxWorks in MultiBench
benchmark suite. In Proceedings of the 2017 19th International Conference on Advanced Communication
Technology (ICACT), Bongpyeong, Korea, 19–22 February 2017; pp. 871–873.
20. Pinto, M.L.; de Oliveira, A.S.; Wehrmeister, M.A. Real-Time Systems Evaluation for Robotics Using the
Hart-ROS Benchmark. In Proceedings of the 2019 19th International Conference on Advanced Robotics
(ICAR), Belo Horizonte, Brazil, 2–6 December 2019; pp. 290–295.
21. Renaux, D.P.B.; Pöttker, F. Performance evaluation of CMSIS-RTOS: Benchmarks and comparison. Int. J.
Embed. Syst. 2016, 8, 452–463. [CrossRef]
22. Boltov, Y.; Skarga-Bandurova, I.; Kotsiuba, I.; Hrushka, M.; Krivoulya, G.; Siriak, R. Performance Evaluation
of Real-Time System for Vision-Based Navigation of Small Autonomous Mobile Robots. In Proceedings
of the 2019 10th International Conference on Dependable Systems, Services and Technologies (DESSERT),
Leeds, UK, 5–7 June 2019; pp. 218–222.
23. Why RTOS and What Is RTOS? Available online: https://www.freertos.org/about-RTOS.html (accessed on
14 February 2020).
24. Real-Time Kernels: µC/OS-II and µC/OS-III. Available online: https://www.micrium.com/rtos/kernels/
(accessed on 14 February 2020).
25. RTX v5 Implementation. Available online: http://arm-software.github.io/CMSIS_5/RTOS2/html/rtx5_impl.ht
ml (accessed on 14 February 2020).
26. RT-Thread, RTOS. Available online: https://www.rt-thread.org/ (accessed on 14 February 2020).
27. Why Certification? Micrium. Available online: https://www.micrium.com/certification/why-safety-critical-
certification/ (accessed on 14 February 2020).
28. Wang, M.; Zhang, Z.; Li, K.; Zhang, Z.; Sheng, Y.; Liu, S. Research on key technologies of fault diagnosis and
early warning for high-end equipment based on intelligent manufacturing and Internet of Things. Int. J. Adv.
Manuf. Technol. 2019, 1–10. [CrossRef]
29. Guan, F.; Peng, L.; Perneel, L.; Timmerman, M. Open source FreeRTOS as a case study in real-time operating
system evolution. J. Syst. Softw. 2016, 118, 19–35. [CrossRef]
30. Musyafani, M.I.; Ardilla, F.; Bachtiar, M.M. Architecture design of low level control omni directional robot
with RTOS-RTX arm cortex-M4. In Proceedings of the 2016 International Electronics Symposium (IES),
Denpasar, Indonesia, 29–30 September 2016; pp. 191–196.
31. Liu, K.; Li, X.; Wang, T.; Zhang, Y.; Li, L. New Electromagnetic Transmitter for EM-MWD System Based on
Embedded RTOS: Uc-OS III. In Proceedings of the 2019 IEEE 4th International Conference on Signal and
Image Processing (ICSIP), Wuxi, China, 19–21 July 2019; pp. 299–303.

© 2020 by the author. Licensee MDPI, Basel, Switzerland. This article is an open access
article distributed under the terms and conditions of the Creative Commons Attribution
(CC BY) license (http://creativecommons.org/licenses/by/4.0/).