Is an RTOS Necessary?

Click the aboveblue text to follow us

In the field of embedded systems, the choice of operating system has a significant impact on system performance, reliability, and functionality.

A Real-Time Operating System (RTOS) is designed specifically for handling time-critical applications, ensuring that tasks are completed within strict deadlines.

This article will explore the necessity of RTOS in embedded systems, how to quantify real-time performance, and illustrate these concepts with code examples.

1

Is RTOS Necessary?

Scenarios for RTOS Usage

The necessity of RTOS depends on the specific requirements of the embedded system.

When a system must meet real-time constraints, meaning tasks have strict deadlines, RTOS becomes crucial.

For example, in automotive control units, medical devices, or aerospace applications, missing a deadline can lead to catastrophic consequences. RTOS ensures that tasks are completed within the specified time through its predictability and determinism.

RTOS provides the following core advantages:

• Predictability and Determinism: RTOS ensures tasks are executed within a predictable timeframe, which is a fundamental requirement for real-time applications.
• Task Management: Supports the creation of multiple tasks and schedules them based on priority, ensuring high-priority tasks are executed first.
• Resource Allocation: Effectively manages resources such as CPU time, memory, and I/O devices to optimize system performance.
• Inter-task Communication: Implements safe and efficient communication between tasks through mechanisms like queues, semaphores, and mutexes.

Applicability of Non-RTOS Solutions

For simpler embedded systems where timing requirements are not strict, bare-metal programming or interrupt-based scheduling may be more appropriate. For instance, a simple temperature monitoring system may only need to poll sensor data without complex task management.

Advantages of Non-RTOS Solutions include:

• Low Resource Usage: No operating system overhead, suitable for resource-constrained microcontrollers.
• Simplicity: Clear code structure, easy to develop and debug.
• Low Cost: No need to purchase commercial RTOS licenses.

However, as system complexity increases, bare-metal solutions may lead to task interference, debugging difficulties, and higher maintenance costs.

In an industrial control project, I once attempted to manage multiple sensors and actuators using bare-metal programming, but the coupling between tasks led to data loss issues. Ultimately, we switched to FreeRTOS, significantly improving system reliability and development efficiency.

The decision to use RTOS should be based on the following factors:

In a medical device project, we needed to ensure that the heart rate monitoring system responded to sensor data within 5ms. Initially, we tried an interrupt-driven bare-metal solution, but as features increased, the code became difficult to maintain. After introducing FreeRTOS, we easily achieved real-time response and modular design through task prioritization and semaphore mechanisms.

This indicates that for complex and time-critical systems, RTOS is often the better choice.

2

Quantifying Real-Time Performance

Key Metrics

Quantifying real-time performance is essential for evaluating whether an RTOS meets system requirements.

The following are the main metrics:

• Latency: The time from an event occurring to the task starting execution. Hard real-time systems require extremely low latency (e.g., in microseconds).
• Jitter: Variation in latency. Excessive jitter can lead to inconsistent system behavior, especially in multimedia or control systems.
• Throughput: The amount of tasks completed in a unit of time, reflecting the system’s processing capability.
• Determinism: The ability to complete tasks within a predictable time frame, which is a core feature of RTOS.

These metrics collectively determine whether the system can meet real-time requirements. For example, in hard real-time systems, any latency or jitter can lead to system failure, while soft real-time systems allow for some degree of flexibility.

Measurement Methods

Quantifying real-time performance requires the use of specialized tools and methods:

• Hardware Tools: Logic analyzers and oscilloscopes can accurately measure the time from event trigger to task response.
• Software Tools: RTOS typically provides performance analysis features, such as FreeRTOS’s vTaskGetRunTimeStats function, which records task execution time and context switch frequency.
• Benchmarking: Using standard test suites (like the Embedded Microprocessor Benchmark Consortium) to evaluate RTOS performance, although these tests are more focused on CPU performance.

In practical projects, I often use a logic analyzer to record timestamps from external interrupts to task execution and calculate average latency and jitter through multiple tests.

For example, in an automotive electronics project, we verified that the system responded to sensor input within 10ms, ensuring compliance with hard real-time requirements.

Real-time performance is influenced by various factors:

In an aerospace project, we found excessive task jitter affecting control precision. Analysis revealed that frequent interrupt handling caused task delays. We optimized interrupt priorities and used FreeRTOS’s priority inheritance mechanism, ultimately controlling jitter within acceptable limits.

3

Example Scenario

To demonstrate how RTOS handles time constraints, we designed a simple example based on FreeRTOS running on an STM32 microcontroller.

The system includes two tasks:

• Task 1: Toggles the LED connected to PB4 every 500ms.
• Task 2: Toggles the LED connected to PB5 every 250ms.

Non-blocking delays are implemented using the osDelay function, ensuring the scheduler can run other tasks while waiting.

Here is the complete code:

#include "main.h"
#include "cmsis_os.h"
osThreadId_t task1Handle;
osThreadId_t task2Handle;
void task1(void *argument) {    for(;;) {        HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_4);  // Toggle LED connected to PB4        osDelay(500);  // Delay 500ms    }}
void task2(void *argument) {    for(;;) {        HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_5);  // Toggle LED connected to PB5        osDelay(250);  // Delay 250ms    }}
int main(void) {    HAL_Init();    SystemClock_Config();    MX_GPIO_Init();
    osKernelInitialize();
    task1Handle = osThreadNew(task1, NULL, NULL);    task2Handle = osThreadNew(task2, NULL, NULL);
    osKernelStart();
    while(1) {        // Main loop, although in RTOS, tasks will run    }}

Code Analysis

• Task Creation: The osThreadNew function creates tasks, allocating default priority and stack size.
• Non-blocking Delay: osDelay puts the task in a waiting state, allowing the scheduler to switch to other tasks.
• Hardware Interaction: HAL_GPIO_TogglePin controls the LED through the STM32 HAL library.

In practical tests, I used an oscilloscope to verify the LED toggle periods, confirming that Task 1 and Task 2 ran at intervals of 500ms and 250ms respectively, with jitter less than 1ms, meeting real-time requirements.

Extended Applications

In more complex scenarios, the following features can be introduced:

• Dynamic Priority Adjustment: Adjusting task priorities based on system status.
• Event Triggering: Responding to external events using semaphores or queues.
• Priority Inheritance: Avoiding priority inversion to ensure high-priority tasks are not blocked.

RTOS is crucial for embedded systems requiring real-time performance, providing tools to manage tasks with strict time constraints. Quantifying real-time performance involves measuring latency, jitter, throughput, and determinism to ensure the system meets design requirements.

Clickto read the original article for more exciting content~