Introduction

Here, I will try to compare several embedded Real-Time Operating Systems (RTOS). But which RTOS should be used for this comparison? I selected systems, which I have used before, but as well systems, which were totally new for me. At the same time, you the reader should get the chance to make the comparision on your own desk, too. In case of a commercial RTOS, I used the trial version if available.

At Wikipedia I found a list of real-time operating systems. Therefore, it should be no problem to find some systems for my test, I thought. But before I started with my test, permission was requested from the commercial manufacturer of the RTOSes, whether I could use their software for the comparison. Unfortunately, two of them did not want to have their systems being part of the comparison. Therefore, µC/OS and FreeRTOS do not participate in the test.

The following RTOSes were considered:

For the speed test an AT91SAM7X-EK and STM3210E-EVAL eval board was used, and CrossWorks for ARM (v2.0.5) was the chosen compiler. In case of Nut/OS, I had problems to get it work with CrossWorks, here YAGARTO (20091018) was used. But I think this should be no big issue, both compilers are based on GCC.

Latency

What is the latency of a RTOS and how can it be measured? Around this question to answer, we will first take a look at Wikipedia for the background information about a Real-time operation system. Here is, what we find:

"An RTOS will typically use specialized scheduling algorithms in order to provide the real-time developer with the tools necessary to produce deterministic behavior in the final system.

Key factors in an RTOS are therefore a minimal interrupt latency and a minimal thread switching latency.

In typical designs, a task has three states: 1) running, 2) ready, 3) blocked. Most tasks are blocked, most of the time. Only one task per CPU is running. In simpler systems, the ready list is usually short, two or three tasks at most.

The real key is designing the scheduler. Usually the data structure of the ready list in the scheduler is designed to minimize the worst-case length of time spent in the scheduler's critical section, during which preemption is inhibited, and, in some cases, all interrupts are disabled." [Source Wikipedia]

Here, I will compare the latency of a RTOS with the context switch time, which is needed to switch from one task to another task. The switch from one task to the next can be triggered by several synchronisation mechanisms like:

• Semaphores
• Mutexes
• Event Flags
• Messages / Mailboxes

For the test, the Semaphore functionality will be used.

How to measure the context switch time? I will not invent the wheel again, and use the following methode from SEGGERs web page:

Measurement with port pins and oscilloscope

The context switching time is the time between switching the LED on and off. If the LED is switched on with an active high signal, the context switching time is the time between rising and falling edge of the signal. If the LED is switched on with an active low signal, the signal polarity is reversed.

The real context switching time is shorter, because the signal also contains the overhead of switching the LED on and off. The time of this overhead is also displayed on the oscilloscope as a small peak right before the task switching time display and has to be subtracted from the displayed context switching time. The picture below shows a simplified oscilloscope signal with an active-low LED signal (low means LED is illuminated). There are switching points to determine:

• A = LED is switched on for overhead measurement
• B = LED is switched off for overhead measurement
• C = LED is switched on right before context switch in low-prio task
• D = LED is switched off right after context switch in high-prio task

The time needed to switch the LED on and off in subroutines is marked as time t_AB. The time needed for a complete context switch including the time needed to switch the LED on and off in subroutines is marked as time t_CD.

The context switching time t_CS is calculated as follows: t_CS = t_CD - t_AB

The result of ChibiOS/RT Test1 (ARM Flash Release) looks like:

Here, the following values were measured, t_AB = 0.415us, t_CD = 5.035us. The context switching time is now t_CS = t_CD - t_AB = 5.035us - 0.415us = 4.62us.

Latency results, ARM7

I hope that here is no typo occurred. All programs which were used here for the test will be available in the download section. In case you find a problem, send me a note and I will check it again.

For the test an AT91SAM7X-EK (AT91SAM7X256) board running at 48MHz is used.
All times in µs:

Latency results, Cortex-M3

For the test a STM3210E-EVAL (STM32F103ZE) board running at 72MHz is used.
All times in µs:

Latency only?

In my opinion, latency is not the only issue that needs to concidered. The following aspects should be taken into account as well:

• Is the source code needed for your project?
• How fast is the support?
• Are there other components needed for your projects, which may be available from the same manufacturer, like a File System or TCP/IP Stack?
• Is a commercial RTOS a must, or can an OpenSource version be used?

And the winner is

Who is the winner of this comparison? By the given results of my tests plus the additional mentioned aspects, each user has to decide by his own which RTOS is the best choice for his project.

Acknowledgement

Special thanks go to the two commercial manufacturers Rowley and SEGGER for their permissions to have their systems participating in my test and to publish the results on this webpage.

Download

rtos-speed-arm7-20100314 (3.75 MB)

rtos-speed-m3-20100315 (690 KB)