Timing Comparison of the Real-Time Operating Systems for Small Microcontrollers

Home , ECos, Firmware, FreeRTOS, Memory footprint, RTEMS, RTLinux

S S 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 ﬁrst 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 conﬁguration. This paper is structured as follows: Section2 presents some performances tests presented in the specialized literature and the motivation for the target RTOS’s selection, Section3 describes the test setup. Section4 contains discussions related to the experimental results. The conclusions are drawn in Section5.

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 certiﬁcations for the development of applications in the avionics, industrial control, and medical ﬁelds [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 Figure1 (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

FigureFigure 1. The 1. The software software diagram diagram ofof thethe test soft softwareware applications applications for forscenario scenario 1. 1. Figure 1. The software diagram of the test software applications for scenario 1. FigureFigure2 presents 2 presents the the software software diagramdiagram of of the the test test software software applications applications for the for scenario the scenario 2. The 2. software applications consist of two tasks with distinct priorities and preemptive scheduling will be The softwareFigure applications 2 presents the consist software of diagram two tasks of the with test distinct software priorities applications and for preemptive the scenario scheduling2. The used. The higher priority task sets the test pin to 0 (LOW/FALSE) and it waits an event with a time- will besoftware used. applications The higher consist priority of tasktwo tasks sets thewith test distinct pin topriorities 0 (LOW and/FALSE) preemptive and itscheduling waits an will event be with used.out of The 1 ms. higher The lowest priority priority task sets task the consists test pin of to an 0 infinite(LOW/FALSE) loop that and sets it thewaits test an pin event to the with one a logic.time- a time-out of 1 ms. The lowest priority task consists of an inﬁnite loop that sets the test pin to the outBy callingof 1 ms. the The primitive lowest priorityfor the eventtask consists wait, a ofcontex an infinitet switch loop is triggered that sets theand test the pinlower to thepriority one logic. task, one logic. By calling the primitive for the event wait, a context switch is triggered and the lower Bywhich calling is in the the primitive ready state, for will the passevent to wait, the running a contex statet switch and itis willtriggered set the and test thepin lowerto 1 (HIGH/TRUE). priority task, prioritywhichWith task, this is in whichconfiguration the ready is in state, the and readywill by passusing state, to the the will test running passpin, we tostate can the and measure running it will theset state thetime andtest for pin ittask will to context 1 (HIGH/TRUE). set the switching test pin to 1 (HIGHWithfrom/TRUE). thisa higher configuration With priority this task conﬁgurationand to by a usinglower the priority and test by pin, task. using we can the measure test pin, the we time can for measure task context the switching time for task contextfrom switchingThese a higher two priority from scenarios a task higher can to bea priority lower found priority in task real to softwaretask. a lower applications. priority task. For example, a task can wait for Thesedata Thesefrom two a two scenarioscommunication scenarios can can be line be found foundand when in in real real data softwaresoftware are received, applications. applications. an event, For mailbox, For example, example, or asemaphore task a taskcan wait can is sent waitfor for datadata fromto the from atask communication a that communication waits for data. line line This and and can when when trigger datadata a aretask re received, contextceived, switchan an event, event, to executemailbox, mailbox, the or tasksemaphore or semaphore that waits is sent for is sent data. Or, a task can expect an event from another peripheral, such as a digital input, and a task context to theto task the task that that waits waits for for data. data. This This can can trigger trigger a ta tasksk context context switch switch to toexecute execute the thetask task that thatwaits waits for for switch must be triggered (with an event, mailbox, or semaphore) to handle that event. data.data. Or, aOr, task a task can can expect expect an an event event from from another another peripheral, such such as as a digital a digital input, input, and anda task a taskcontext 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.

FigureFigure 2. The 2. The software software diagram diagram ofof the test soft softwareware applications applications for forscenario scenario 2. 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 Figure3 presents the software diagram of the test software applications for the scenario 3. Figure 3 presents the software diagram of the test software applications for the scenario 3. The The softwaresoftware applications applications consist consist of ofonly only one one task. task. In this In thiscase, case,everyevery 1 ms, 1the ms, test the pin test is pinset to is 0 set to 0 (LOW(LOW/FALSE),/FALSE), and and an an event event (not (notexpected expected by any any task task)) is is triggered, triggered, whereupon whereupon the thetest testpin is pin setis to set to 1 (HIGH1 (HIGH/TRUE)./TRUE). After After these these operations, operations, the the primitive primitiv fore for waiting waiting an an event event is is called called to to receive receive andand clear the event.clear the In thisevent. scenario, In this scenario, with the with help the of help the of test the pin, testthe pin, execution the execution time time for for the the primitive primitive for for event event triggering can be measured. triggeringevent cantriggering be measured. can be measured.

Figure 3. The software diagram of the test software applications for scenario 3. FigureFigure 3. The 3. The software software diagram diagram of of thethe test software applications applications for for scenario scenario 3. 3.

FigureFigure4 presents 4 presents the the software software diagram diagram of of the the test test software software applications applications for the for scenario the scenario 4. The 4. software applications consist of only one task. In this scenario, we want to measure the execution The softwaresoftware applicationsapplications consist consist of of only only one one task. task. In Inthis this scenario, scenario, we wewant want to measure to measure the execution the execution time for the primitive used to receive an existing event. The software applications are similar with time forthe thethird primitive scenario, usedwith todifferences receive anthat existing the test event.pin is set The to software 0 (LOW/FALSE) applications before are the similar call for withthe the thirdthe scenario, third scenario, with di ﬀwitherences differences that the that test the pin test is pi setn tois set 0 (LOW to 0 (LOW/FALSE)/FALSE) before before the callthe call for thefor the waiting waiting primitive and is set to 1 (HIGH/TRUE) after this 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. FigureFigure 4. The 4. The software software diagram diagram of of thethe test software applications applications for for scenario scenario 4. 4. Test software applications with the same configuration were developed when semaphores or TestTest software software applications applications with with the the same same configurationconfiguration were were developed developed when when semaphores semaphores or or mailboxes are used as synchronization mechanisms, using the waiting and signalling primitives mailboxes are used as synchronization mechanisms, using the waiting and signalling primitives specific specific to each mechanism. We developed a software application for each of the chosen RTOSs on to each mechanism. We developed a software application for each of the chosen RTOSs on two MCUs: two MCUs: STM32F407IG ARM Cortex™-M4 MCU and STM32L053R8 ARM Cortex™-M0+ MCU. STM32F407IGWe used the ARM following Cortex versions™-M4 MCUof RTOSs: and STM32L053R8uC-OS/II V2.92.11, ARM uC-OS/III Cortex V3.0™-M05.00,+ FreeRTMCU.OS We 9.0.0, used the followingFreeRTOS versions 10.2.0, of rt-thread RTOSs: V2.1.1, uC-OS and/II V2.92.11, Keil RTX uC-OSV4.82.0./ IIIFor V3.05.00, all RTOSs, FreeRTOS the most code 9.0.0, is FreeRTOSin C because 10.2.0, rt-threadthe purpose V2.1.1, of and these Keil RTOSs RTX V4.82.0.is to provide For better all RTOSs, portability. the most Using code the issame in C compiler, because they the purposecan be of thesecompared RTOSs is under to provide the same better conditions, portability. with Usingno opti themized same code. compiler, For each they synchronization can be compared mechanism, under the a software application has been developed for each MCU, and from these software applications, the samea conditions, software application with no optimized has been developed code. For for each each synchronization MCU, and from mechanism,these software a softwareapplications, application the scenarios are activated with conditional compilation. has been developedThe tests were for eachperformed MCU, andon two from MCUs: these softwareSTM32F407IG applications, ARM Cortex™-M4 the scenarios MCU are activatedand with conditionalThe tests compilation. were performed on two MCUs: STM32F407IG ARM Cortex™-M4 MCU and STM32L053R8 ARM Cortex™-M0+ MCU. The following development kits were used for these The tests were performed on two MCUs: STM32F407IG ARM Cortex™-M4 MCU and MCUs: KEIL MCBSTM32F400 and STM32 NUCLEO-L053R8. These two architectures are not similar STM32L053R8although both ARM are Cortexbased ™on-M0 a 32-bit+ MCU. RISC Theprocessor. following ARM development Cortex M0 + used kits werea Von usedNeumann for these MCUs:architecture KEIL MCBSTM32F400 with instruction and pipelining STM32 NUCLEO-L053R8.of two stages. The TheseARM twoCortex architectures M4 used a are Harvard 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 AppendixA for FreeRTOS when semaphores are used, AppendixB for uC /OS-II RTOS when events are used, AppendixC for rt-thread when mailboxes are used, and AppendixD 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

Figure5, Figure6, and Figure7 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 x FOR used, PEER andREVIEW by FreeRTOS0 and Keil RTX when mailboxes are used. It can8 of be 19 seen Symmetry 2020, 12, x FOR PEER REVIEW 8 of 19 that thereSymmetry are 2020 small, 12, x diFORfferences PEER REVIEW between STM32F407IG ARM Cortex ™ -M4 and STM32L053R88 of 19 ARM Cortex ™ -M0+ MCUs regarding latencies obtained by RTOS systems (comparison between RTOSs CortexCortex™ -M0 ™ +-M0+MCUs MCUs regarding regarding latencies latencies obtained obtained by by RTOS RTOS systemssystems (comparison between between RTOSs RTOSs on Cortexon the same™ -M0+ MCU). MCUs In theregarding first case, latencies no jitter obtained appears byin theRTOS latency systems measurement (comparison (the between task switching RTOSs the sameon the MCU). same MCU). In the In first the case,first case, no jitter no jitter appears appears in in the the latency latency measurement measurement (the (the task task switching switching is onis periodicallythe same MCU). triggered In the firstat every case, no1 msjitter and appe thears inpresence the latency of jitter measurement could be (the observed task switching on the periodicallyis periodically triggered triggered at every at 1every ms and 1 ms the and presence the presence of jitter couldof jitter be could observed be observed on the oscilloscope). on the isoscilloscope). periodically triggered at every 1 ms and the presence of jitter could be observed on the oscilloscope). oscilloscope).

Figure 5. The time for task switching from the lowest priority task to the higher priority task triggered FigureFigure 5. The 5. The time time for for task task switching switching from from thethe lowest priori priorityty task task to tothe the higher higher priority priority task tasktriggered triggered Figureby an event 5. The (scenario time for task1). switching from the lowest priority task to the higher priority task triggered by anby event an event (scenario (scenario 1). 1). 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 time for task switching from the lowest priority task to the higher priority task triggered FigureFigureby 6.a seThe m6. aphoreThe time time for (scenario for task task switching 1).switching from from thethe lowest priori priorityty task task to tothe the higher higher priority priority task tasktriggered triggered by a semaphore (scenario 1). by a semaphoreby a semaphore (scenario (scenario 1). 1).

Figure 7. The time for task switching from the lowest priority task to the higher priority task triggered Figure 7. The time for task switching from the lowest priority task to the higher priority task triggered FigureFigureby 7.a mailboxThe 7. The time time(scenario for for task task 1). switching switching from from thethe lowest priori priorityty task task to tothe the higher higher priority priority task tasktriggered triggered by a mailbox (scenario 1). by a mailboxby a mailbox (scenario (scenario 1). 1). 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 latencyeach RTOS. measurement Furthermore, is performed each RTOS using has a the GPIO same pin, latency and the generated time for portby the handling access ofis 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 Symmetry 2020, 12, x FOR PEER REVIEW 9 of 19 GPIOSymmetry port that 2020 is, 12 connected, x FOR PEER toREVIEW the peripheral bus of the MCU. Usually, embedded systems must9 of 19 react to externalGPIO port events that thatis connected are received to the peripheral via peripherals bus of the (GPIO, MCU. ADC, Usually, UART, embedded CAN, systems etc.) and must the react reaction GPIO port that is connected to the peripheral bus of the MCU. Usually, embedded systems must react can beto sentexternal further events through that are peripherals received via(GPIO, peripher DAC,als (GPIO, UART, ADC, CAN, UART, etc.). CAN, For etc.) this and reason, the reaction we consider to external events that are received via peripherals (GPIO, ADC, UART, CAN, etc.) and the reaction that thecan usebe sent of a further GPIO pinthrough to measure peripherals latency (GPIO, can DAC, bring UART, us closer CAN, to etc.). the real For functioningthis reason, we of consider the real-time can be sent further through peripherals (GPIO, DAC, UART, CAN, etc.). For this reason, we consider systemthat that the wasuse of developed a GPIO pin based to measure on an latency RTOS. 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 system that was developed based on an RTOS. Thetime resultssystem that for thewas second developed scenario based areon an presented RTOS. in Figure8, Figure9, and Figure 10. As can be The results for the second scenario are presented in Figures 8, 9, and 10. As can be seen from the seen fromThe the results figures, for in the this second case, scenario jitter is presentare presented during in Figures task switching. 8, 9, and 10. The As jitter can be results seen from from the the fact figures, in this case, jitter is present during task switching. The jitter results from the fact that the that thefigures, second in this task case, sets jitter the testis pres pinent to during 1 (HIGH task/TRUE) switching. in an The infinite jitter results loop and from it isthe preempted fact that the by the second task sets the test pin to 1 (HIGH/TRUE) in an infinite loop and it is preempted by the higher highersecond priority task tasksets the while test itpin sets to the1 (HIGH/TRUE) pin. The preemption in an infinite moments loop and can it is influencepreempted the by timethe higher when the priority task while it sets the pin. The preemption moments can influence the time when the task is task ispriority resumed task and while sets it sets the testthe pin. pin The to 1 preemptio (HIGH/TRUE).n moments In addition, can influence there the is antime influence when the generated task is by resumed and sets the test pin to 1 (HIGH/TRUE). In addition, there is an influence generated by the resumed and sets the test pin to 1 (HIGH/TRUE). In addition, there is an influence generated by the the interruptinterrupt serviceservice routine routine for for the the clock clock tick. tick. From From the figures, the figures, we can we see can that see the that smallest the smallestlatency and latency interrupt service routine for the clock tick. From the figures, we can see that the smallest latency and and thethe smallest jitter jitter is is obtained obtained by byuC/OS-II uC/OS-II and andthe highest the highest latency latency 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 casecase of of eventsevents and mailboxes mailboxes and and by by FreeRTOS9 FreeRTOS9 in the in case the caseof semaphores. of semaphores. case of events and mailboxes and by FreeRTOS9 in the case of semaphores. In Figures 11, 12, and 13 the results for the third scenario are presented. In this case, the time is In FigureIn Figures 11, Figure 11, 12, 12and, and 13 the Figure results 13 forthe the results third forscenario the third are presented. scenario areIn this presented. case, the Intime this is case, measured when an event is triggered, a semaphore is issued, or a message is sent. For events and the timemeasured is measured when an when event an is event triggered, is triggered, a semaphore a semaphore is issued, is or issued, a message or a messageis sent. For is sent.events For and events semaphores, the lowest latency is obtained for rt-thread and for mailboxes, the lowest latency is and semaphores,semaphores, the the lowest lowest latency latency is isobtained obtained for for rt-thread rt-thread and and for formailboxes, mailboxes, the lowest the lowest latency latency is is obtained for uC/OS-II. For events and semaphores, the highest latency is obtained for FreeRTOS10, obtainedobtained for uCfor /uC/OS-II.OS-II. For For events events and and semaphores, semaphores, the the highest highest latency latency is obtained is obtained for FreeRTOS10, for FreeRTOS10, and for mailboxes, Keil RTX obtains the lowest latency. and forand mailboxes, for mailboxes, Keil Keil RTX RTX obtains obtains the the lowest lowest latency.latency.

Figure 8. Time for task switching from the lowest priority task to the higher priority task triggered by FigureFigure 8. Time 8. Time for for task task switching switching from from the the lowestlowest priority task task to to the the higher higher priority priority task tasktriggered triggered by by an event (the values from the top are the jitters) (scenario 2). an eventan event (the (the values values from from the the top top are are the the jitters) jitters) (scenario(scenario 2). 2).

Figure 9. Time for task switching from the lowest priority task to the higher priority task triggered by FigureFigure 9. Time 9. Time for taskfor task switching switching from from the the lowest lowest prioritypriority task to to the the higher higher priority priority task task triggered triggered by by a a semaphore event (the values from the top are the jitters (scenario 2). semaphorea semaphore event event (the values(the values from from the the top top are are the the jitters jitters (scenario (scenario 2).2).

Symmetry 2020, 12, 592 10 of 19

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

FigureFigure 10. The 10. timeThe time for task for switchingtask switching from from the lowest the lowest priority priority task totask the to higher the higher priority priority task triggeredtask by a mailboxtriggered (theby a valuesmailbox from (the values the top from are the the top jitters) are the (scenario jitters) (scenario 2). 2).

FigureFigure 11. The 11. The execution execution time time for for the the primitive primitive that signal signal an an event event that that is not is not waited waited by the by other the other task task (unblocking(unblocking send) send) (scenario (scenario 3). 3).

FigureFigure 12. The 12. The execution execution time time for for the the primitive primitive that signal signal aa semaphore semaphore that that is not isnot waited waited by the by other theother task (unblockingtask (unblocking send) send) (scenario (scenario 3). 3).

Symmetry 2020, 12, 592 11 of 19

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

Symmetry 2020,, 12,, xx FORFOR PEERPEER REVIEWREVIEW 11 of 19

FigureFigure 13. The 13. The execution execution time time for for the the primitive primitive that that send send a mailboxa mailbox that that is isnot not waitedwaited byby the other task task (unblocking send) (scenario 3). (unblockingFigure 13. send) The (scenarioexecution 3).time for the primitive that send aa mailboxmailbox thatthat isis notnot waitedwaited byby thethe otherother task (unblocking send) (scenario 3). FigureFigures 14, Figure 14, 15, 15and, and 16 present Figure the 16 resultspresent for the the resultsfourth scenario. for the fourth In this scenario.case, it is measured In this case, the it is time when an event, semaphore or mailbox is received. The results are similar to the previous measuredFigures the time 14, when15, and an 16 event,present semaphore the results for or the mailbox fourth isscenario. received. In this The case, results it is measured are similar the to the scenario, in the sense that for events and semaphores, the highest latency is obtained for FreeRTOS10 previoustime scenario,when an event, in the semaphore sense that or for mailbox events is and received. semaphores, The results the highestare similar latency to the is previous obtained for scenario,and for the in mailboxesthe sense that Keil for RTX events obtains and the semaphor lowest es,latency. the highest latency is obtained for FreeRTOS10 FreeRTOS10scenario, andin the for sense the that mailboxes for events Keil and RTX semaphor obtainses, the the lowesthighest latency.latency is obtained for FreeRTOS10 and for the mailboxes Keil RTX obtains the lowest latency.

Figure 14. The execution time for the primitive used to receive an existing event (unblocking wait) (scenario 4). FigureFigure 14. The14. The execution execution time time for for the the primitive primitive used to to receive receive an an existing existing event event (unblocking (unblocking wait) wait) (scenario(scenario 4). 4).

Figure 15. The execution time for the primitive used to receive an existing semaphore (unblocking wait) (scenario 4). FigureFigure 15. The15. The execution execution time time for for the the primitive primitive used to to receive receive an an existing existing semaphore semaphore (unblocking (unblocking wait) (scenario 4). wait)wait) (scenario (scenario 4). 4).

Symmetry 2020, 12, 592 12 of 19

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

FigureFigure 16. The 16. The execution execution time time for for the the primitive primitive used to to receive receive an an existing existing mailbox mailbox (unblocking (unblocking wait) wait) (scenario(scenario 4). 4).

The measurementThe measurement error error is theis the same same for for all all casescases be becausecause the the same same oscilloscope oscilloscope is used. is used. All RTOSs All RTOSs use supervisoruse supervisor call call (SVC) (SVC) interrupt interrupt to to perform perform task switching, switching, but but there there are are differences differences in how in howthe the directivesdirectives for communication for communication mechanisms mechanisms are are executed, executed, and and how how the the queues queues of of di ffdifferenterent events 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,dependent on the scenarios hardware for platform measurement used and ofas thelong energy as the MCU consumption and other components can be made, enter but the this is dependentlow power on the consumption hardware mode. platform On usedthe same and hardware as long as platform, the MCU energy and otherconsumption components is directly enter the low powerproportional consumption to the execution mode. time On that the is same measur hardwareed in the scenarios platform, proposed energy in consumption this article. is directly proportionalAnalyzing to the executionthe results for time the that four is scenarios, measured we in can the say scenarios that the proposedbest RTOS inperformers this article. are uC/ AnalyzingOS-II, Keil RTX, the resultsand rt-thread. for the FreeRTOS, four scenarios, which is we the can most say used that RTOS the bestin embedded RTOS performers projects, does are uC/ OS-II,not Keil have RTX, the andbest rt-thread.latency performances FreeRTOS, but which the perf is theormances most usedare close RTOS to the in embeddedother RTOSs projects, tested in does not haveour case. the best The latencydifferences performances appear in the but way the of performances implementation are of close the toaccess the otherto internal RTOSs queues tested for in our case.events, The di ffsemaphores,erences appear and mailboxes. 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,provided when must a RTOS be considered. is selected Us toually, design there and are develop preferred applications mature RTOSs with real-timethat have capabilities,proven their other elementsfunctionality such as licensingand efficiency mode, in developing memory footprint, other applications predictability, with real-time certifications, capabilities. and support provided must be considered. Usually, there are preferred mature RTOSs that have proven their functionality and e5.ffi Conclusionsciency 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, ThisFreeRTOS paper 9.0.0, presented FreeRTOS an 10.2.0, analysis RT-Thread, and comparison and Keil RTX) in terms that are of timingwidely used performances to design and for task synchronizationdevelop applications throughout on small events, MCUs. semaphore, We measured and the mailboxes time for task for switching six RTOSs triggered (uC-OS by/ anII, event, uC/OS-III, FreeRTOSsemaphore, 9.0.0, FreeRTOSand mailbox 10.2.0, and RT-Thread,we compared and the Keil time RTX) achieved that are by widely the chosen usedto RTOSs design on and ARM 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 STM32L053R8RTX, and rt-thread. ARM Cortex The ™lower-M0 +performancesbased MCUs. (close In to addition, the others we RTOSs) measured are theachieved latencies by the for the directivesFreeRTOS used although to send/ itreceive is the most an event, used RTOS semaphore, in embedded and mailbox. projects. FromIt should the be experimental mentioned that results, the we can concludetests were that performed the best for performances small MCUs, are and achieved for this reason, for uC /noOS-II, variants Keil of RTX, Linux and based rt-thread. RTOSs Thehave lower performancesbeen tested. (close Although to the the others timing RTOSs) is the most are import achievedant parameter by the FreeRTOS in a hard or although a soft real-time it is the system, most used RTOSwe in embeddedmust consider projects. that we It need should to beinclude mentioned other criteria that the in tests selecting were performedan RTOS, such for smallas licensing, MCUs, and for thismemory reason, footprint, no variants predictability, of Linux certifications, based RTOSs and have support been provided. tested. Although The results the presented timing isin thethis most importantpaper parametermay represent in an a hard indication or a soft for selecting real-time an system, RTOS in we terms must of response consider time that to we the need occurrence 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

ConﬂictsConflicts ofof Interest:Interest: The author declare no no conflict conﬂict of of interest. interest. Th Thee funders funders had had no no role role in in the the design design of of the the study; instudy; the collection, in the collection, analyses, analyses, or interpretation or interpretation of data; of data in the; in writingthe writing of theof the manuscript, manuscript, or or in in the the decision decision to to publish thepublish results. the results.

AppendixAppendix A This appendixappendix contains the code for two tasks of thethe testtest softwaresoftware application for FreeRTOS RTOS whenRTOS semaphoreswhen 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 AppendixAppendix B B This appendix contains the code for two tasks of the test software application uC/OS-II RTOS This appendix appendix contains contains the the code code for for two two tasks tasks of the of thetest testsoftware software application application uC/OS-II uC /RTOSOS-II RTOS when events are used. whenwhen events are are used. 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 20202020,, 1212,, xx FORFOR PEERPEER REVIEWREVIEW 1515 ofof 1919

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 } }

AppendixAppendix C ThisThis appendix contains contains the the code code for for two two tasks tasks of the of thetest testsoftware software application application rt-thread rt-thread RTOS RTOS whenwhen mailboxesmailboxes are are used. 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

AppendixAppendix D ThisThis appendix contains contains the the code code for for two two tasks tasks of the of thetest testsoftware software application application for Keil for RTX Keil RTOS RTX RTOS whenwhen semaphoressemaphores are are used. 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 } }

ReferencesReferences 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 [Systems.CrossRef In] Proceedings of the 2017 IEEE Real-Time Systems Symposium (RTSS), Paris, France, 5–8 3. Cinque,December M.; 2017; De pp. Tommasi, 369–371. G. Work-in-Progress: Real-Time Containers for Large-Scale Mixed-Criticality 4. Systems.Nuratch, S. In A Proceedings universal microcontroller of the 2017 IEEE circuit Real-Time and firmware Systems Symposiumdesign and impl (RTSS),ementation Paris, France, for IoT-based 5–8 December 2017;realtime pp. measurement 369–371. and control applications. In Proceedings of the 2017 International Electrical 4. Nuratch,Engineering S. Congress A universal (iEECON), microcontroller Pattaya, Thailand, circuit and8–10 firmware March 2017; design pp. 1–4. and implementation for IoT-based 5. realtimeZikria, Y.B.; measurement Kim, S.W.; Hahm, and O.; control Afzal, applications. M.K.; Aalsalem, In M.Y. Proceedings Internet of Things of the (IoT) 2017 Operating International Systems Electrical EngineeringManagement: CongressOpportunities, (iEECON), Challenges, Pattaya, and Thailand,Solution. Sensors 8–10 March 2019, 19 2017;, 1793. pp. 1–4. 5.6. Zikria,Buttazzo, Y.B.; G.C. Kim, Hard S.W.; Real-Time Hahm, O.;Computing Afzal, M.K.;Systems: Aalsalem, Predicta M.Y.ble Scheduling Internet ofAlgorithms Things (IoT) and OperatingApplications Systems; Management:Springer: Berlin/Heide Opportunities,lberg, Germany, Challenges, 2011. and Solution. Sensors 2019, 19, 1793. [CrossRef][PubMed] 6.7. Buttazzo,de Oliveira, G.C. D.B.;Hard de Real-TimeOliveira, R.S. Computing Timing Systems:analysis of Predictable the PREEMPT_RT Scheduling Linux Algorithms kernel. and Softw. Applications Pract. Exp.; Springer: Berlin2016, 46/Heidelberg,, 789–819. 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. ComputingBelesioti, M.; Machinery, Makri, R.; NewFehling-Kaschek, York, NY, USA, M.; Carli, 15–17 M.; November Kostopoulos, 2019; pp.A.; Chochliouros, 37–42. I.P.; Neri, A.; 9. Delgado,Frosali, F. R.;A New Park, Security J.; Choi, Approach B.W. Open in Telecom Embedded Infrastructures: Real-time ControllersThe RESISTO for Co Industrialncept. In Proceedings Distributed of Control Systems.the 2019 15thElectronics International2019, 8Conference, 223. [CrossRef on Distribute] d Computing in Sensor Systems (DCOSS), Santorini 10. Belesioti,Island, Greece, M.; Makri, 29–31 R.;May Fehling-Kaschek, 2019; pp. 212–218. M.; Carli, M.; Kostopoulos, A.; Chochliouros, I.P.; Neri, A.; Frosali, F. 11. AZhang, New SecurityK.; Wu, J.; Approach Liu, C.; Ali, in Telecom S.S.; Ren, Infrastructures: J. Behavior Modeling The RESISTO on ARINC653 Concept. to In Support Proceedings the Temporal of the 2019 15th InternationalVerification of ConferenceConformed Application on Distributed Design. Computing IEEE Access in Sensor2019, 7, Systems23852–23863. (DCOSS), Santorini Island, Greece, 12. 29–31Alexander, May 2019;B.; Titarenko, pp. 212–218. L.; Mazurkiewicz, M. Foundations of Embedded Systems; Springer: 11. Zhang,Berlin/Heidelberg, K.; Wu, J.; Germany, Liu, C.; 2019. Ali, S.S.; Ren, J. Behavior Modeling on ARINC653 to Support the Temporal 13. VerificationUngurean, I.; of Gaitan, Conformed N.C.; Gaitan, Application V.G. A Design. MiddlewareIEEE AccessBased 2019Architecture, 7, 23852–23863. for the Industrial [CrossRef Internet] of 12. Alexander,Things. KSII B.; Trans. Titarenko, Internet L.; Inf. Mazurkiewicz, Syst. 2016, 10, 2874–2891. 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& Processing Proceedings Environments. of the 2018 International2017. Available Conference online: https://m on Development.eet.com/media/1246048/2017-embedded- and Application Systems (DAS), Suceava,market-study.pdf Romanian, (accessed 24–26 on May 14 February 2018; pp. 2020). 63–66. 15.17. Labrosse,Real-Time J.J.OperatingMicroC/ OSSystems II; The (RTOS) Real Time Market Kernel; 2019: CMP Highlights Books: Lawrence,Recent Trends, KS, USA,Market 2002. Growth, Top 16. EmbeddedManufacturers Markets Analysis, Study, IntegratingBusiness IoT andOpportunities Advanced Technologyand Demand. Designs, ApplicationAvailable Developmentonline: & Processinghttps://www.marketwatch.com/press-release/real-t Environments. 2017. Available online:ime-operating-systems-rt https://m.eet.com/mediaos-market-2019-highlights-/1246048/2017-embedded-market -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 Certiﬁcation? 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/).