Fundamentals of Real-Time Operating Systems (RTOS)

Fundamentals of Real-Time Operating Systems (RTOS)

Real-Time Operating System (RTOS) is an operating system (OS) designed to provide real-time application processes with data, typically without buffering delays.

The key factors in an RTOS are minimal interrupt latency and minimal thread switching latency. The value of an RTOS lies in its response speed or predictability, rather than the amount of work it can perform in a given period.

The general rule for embedded devices is to use an RTOS when the application process requires executing multiple simple operations.

Real-time operating systems have the following goals:

Low latency.
Determinism: It is necessary to know how long it takes to process tasks to ensure deadlines are met.
Structured software: With an RTOS, components can be added directly to the application process in a structured manner.
Scalability: An RTOS must be able to scale from simple application processes to complex ones with stacks, driver processes, documentation systems, etc.
Offloading development: An RTOS manages many aspects of the system, such as power management, interrupt table management, memory management, exception handling, etc.

Threads

Typical threads in an RTOS-based application process:

Interrupt Service Routine (ISR): A thread initiated by a hardware interrupt. The ISR runs until completion. All ISRs share the same stack.
Task: A thread that can block while waiting for an event to occur. Traditionally, tasks are long-lived threads (as opposed to ISRs that run until completion). Each task has its own stack to allow it to be long-lived.
Idle: The lowest priority thread that runs only when no other threads are ready to execute. Typically, idle is just a special task with the lowest possible priority.

Scheduling Process

The core of every RTOS has a scheduling process. The scheduling process is responsible for managing the execution of threads in the system. There are two main management methods for the scheduling process: preemptive scheduling and time-slice scheduling.

Preemptive scheduling is the most common type of RTOS scheduling process. Both TI-RTOS and FreeRTOS have preemptive scheduling processes. With preemptive scheduling, the running thread will continue until:

Completion (e.g., ISR completes).
A higher-priority thread becomes ready (in which case, the higher-priority thread preempts the lower-priority thread).
The thread gives up the processor while waiting for resources (e.g., a task calls sleep()).

Time-slice scheduling guarantees that each thread has a slot to execute. This type of scheduling is usually detrimental to real-time applications. If necessary, the TI-RTOS kernel supports time-slice scheduling using tasks.

Other Key Terms

Thread safety: A piece of code is thread-safe if it operates on shared data structures in a way that ensures correct access (reading and writing) by multiple threads simultaneously.

Blocked: A task is blocked if it is waiting for resources and is not consuming any CPU. For example, if a task calls Task_sleep() or Semaphore_pend() (with a non-zero timeout and semaphore unavailable), the task will be blocked, allowing another thread to run.

Bare metal: A common name for application processes that do not use an RTOS.

Bare Metal vs. Real-Time Operating Systems

A typical bare metal application process can usually be divided into three key parts:

Initialization: Initializing hardware and software components in main().
Super loop state machine: The code that manages the application process. These operations are based on interrupts (e.g., receiving an SPI data packet or timer expiration) or polling results.
ISR: Code executed by interrupts from peripherals (e.g., UART), timers, or other device-specific items (e.g., exceptions or multicore communication).

Bare metal application processes have their place. They are typically small, fast, and relatively easy to understand through simple application processes. Once more complex logic is needed, RTOS shines.

Components of a Real-Time Operating System

Scheduling process: A preemptive scheduling process that ensures the highest priority thread is running.
Communication mechanisms: Semaphores, message queues, queues, etc.
Critical section mechanisms: Mutexes, gates, locks, etc.
Timing services: Clocks, timers, etc.
Power management: For low-power devices, power management is often part of the RTOS because it knows the state of the device.
Memory management: Variable-size heaps, fixed-size heaps, etc.
Peripheral drivers: UART, SPI, I2C, etc.
Protocol stacks: Bluetooth, wireless networks, etc.
File systems: FatFs, etc.
Device management: Exception handling, booting, etc.

POSIX

POSIX (Portable Operating System Interface): A portable operating system interface.

The SimpleLink SDK provides POSIX support on top of TI-RTOS and FreeRTOS. This allows application processes to be independent of the underlying RTOS.

POSIX API is a small layer of code above the underlying real-time operating system. When creating a POSIX thread, a base TI-RTOS (or FreeRTOS) task will be created. Similarly, when creating a POSIX thread semaphore, a TI-RTOS (or FreeRTOS) semaphore will be created.

A great feature of POSIX support is the ability to quickly get POSIX-based code working from the network.

POSIX is not a real-time operating system. It is a compatibility layer for operating systems that allows application processes to be easily ported between operating systems.

RTOS Thread Communication

All RTOS provide standard communication mechanisms such as semaphores, mutexes, message queues, linked lists, etc.

Semaphores

Semaphores allow for resource management. Tasks can block on sem_wait() until resources become available (via sem_post()). A common use case is Hwi receiving data and posting a semaphore for a task to process it.

This is desirable as it minimizes the duration of interrupts. Most RTOS support binary and counting semaphores.

Message Queues

Message queues are very useful for sending data between threads. Message queues can be configured to send/receive user-defined messages of any size. Here, a task is sending a message to another task:

Message queues are very useful when you want to centralize specific functionality into a single task. All other threads can send messages to the centralized task for processing. Message queues handle messages in a thread-safe manner.

The message queues in the POSIX support layer are built on top of Mailboxes in TI-RTOS and queues in FreeRTOS.

Execution

A preemptive scheduling process is running. Assume the following threads are created in main():

ISRX: Interrupt service routine

MidA: Created in main() with priority 4

MidB: Created in main() with priority 4

High: Created in main() with priority 8

Once the kernel’s scheduling process starts (in this case, by calling BIOS_start() in main()), all tasks are ready to run, with High running first because it has the highest priority.

1.ISRX asserts, as it will preempt all tasks.High is now in a preemptive state.

2.ISRX completes, and High will start running again until it blocks onTask_sleep() (or some blocking<code class="language-plaintext">API). Now,MidA can run.

3.MidA runs until it encounters a blocking call (like Semaphore_pend()). Now,MidB can run.

4.MidB runs until High unblocks (assuming Task_sleep() has expired).MidB is now preempted.

5.High will run untilISRX asserts and preempts High. Note: Now two tasks are preempted.

6.MidA is ready (assumingISRX has released its blocked semaphore).MidA will not run because a higher-priority thread is running.

7.ISRX completes, soHigh runs again and then blocks again, soMidB runs until it blocks. NowMidA can run because no higher-priority tasks are running. Note:MidA must wait untilMidB completes because whenMidA is ready,MidB is running.

8.MidA blocks, and now no threads are running or ready to run, so Idle runs.

9.MidB unblocks and runs.

「Recommended RTOS Knowledge👇」

Microcontroller -> RTOS -> Linux -> Abandon

What Exactly Does Learning RTOS Do for Embedded Systems?

For More Optocoupler Knowledge, Please Click👇 Follow Public Account Search

「Recommended Reading 👇 Click the image to jump」

Understanding Output Voltage Ripple and Noise: Sources and Suppression

One-click three consecutive actions to encourage the author👉 Share↓ Like↓ Read↓