What's changed: Initial version
3.1The role of an RTOS and task state transitions
Covers what an RTOS (real-time operating system) is designed to prioritize over a general-purpose OS, the kernel's role in task management, scheduling, and interrupt handling, the three-state transition of a task between running, ready, and waiting (including dormant), and how to judge whether an embedded project should adopt an RTOS or can rely on bare-metal (no-RTOS) design.
While a general-purpose OS optimizes for average throughput, an RTOS (Real-Time OS) is designed above all to answer one question: "can deadlines be met even in the worst-case execution scenario?" For an embedded designer, what matters is not raw speed but whether task switching is predictable (deterministic). This section covers the role of the kernel—the core of an RTOS—and the states a task moves through, alongside real adoption decisions.
3.1.1The role of the kernel
- The kernel is the core of an RTOS. It provides task management (creation/deletion/state transitions), scheduling (deciding which task receives the CPU next), interrupt handling, inter-task synchronization and communication (semaphores, message queues, etc.), and time management (timers, delays).
- The biggest difference from a general-purpose kernel is that an RTOS kernel guarantees known upper bounds on interrupt latency (time from interrupt to task wake-up) and context-switch time. This is what makes it possible to design a system that guarantees "a response within X microseconds, even in the worst case."
3.1.2Task state transitions
- Running is the state in which a task currently holds the CPU and is executing instructions. On a single core, only one task can be in this state at a time.
- Ready is the state in which a task is capable of running as soon as the CPU is allocated to it, but is waiting because a higher-priority task (or a same-priority task ahead in turn) currently holds the CPU.
- Waiting (blocked; in a broader sense including dormant) is the state in which a task has voluntarily released the CPU while waiting for some event—acquiring a semaphore, receiving a message, a timer expiring, and so on. Dormant refers to the state before creation or after termination, when a task is not a scheduling candidate at all.
- Key point of the transitions: a running task moves to waiting voluntarily (waiting for an event), whereas a running task drops to ready only when forcibly preempted (a higher-priority task becomes runnable)—this is preemption. A waiting task returns to ready once its event occurs, but does not move to running until the scheduler actually selects it.
Most-tested: "the essence of an RTOS is predictability (determinism), not raw speed," "the ready-to-running transition is the scheduler's choice, while the running-to-ready transition is a forced preemption," and "the waiting-to-ready transition is automatic, but ready-to-running is not." Be precise about the direction of each arrow in the three-state model (running/ready/waiting) and which transitions are voluntary versus forced.
3.1.3Deciding whether to adopt an RTOS
| Consideration | Favors adopting an RTOS | Favors bare-metal (no RTOS) |
|---|---|---|
| Processing complexity | Multiple independent periodic tasks and communication stacks coexist | A single simple polling loop suffices |
| Memory resources | Can afford the RTOS footprint (several KB or more) | Must run in a few hundred bytes of memory |
| Timing requirements | Needs priority control and deadline guarantees across multiple tasks | A single function suffices with interrupt + main loop only |
| Development scale/maintainability | Team development, a long-lived product with ongoing feature additions | A disposable device built once with few future changes |
Suppose a firmware developer is assigned to design an industrial sensor terminal with three requirements that must run concurrently: (1) read the temperature sensor every 100 ms, (2) transmit the collected data over BLE every 500 ms, and (3) detect a button press instantly and blink an LED. If this were implemented bare-metal (a single main loop plus interrupts), and (1)'s sensor read happened to take tens of milliseconds, the timing of (2)'s BLE transmission could slip, or (3)'s button response could be delayed. Cramming all the processing into one polling loop creates coupling where lengthening just one task's execution time throws off the timing of everything else. Introducing an RTOS lets you separate (1), (2), and (3) into independent tasks, and by giving the button-detection task in (3) the highest priority, you can guarantee button responsiveness regardless of what the other tasks are doing. Tasks (1) and (2) each enter the waiting state for their respective period, and when the period elapses the scheduler moves them back to ready, promoting them to running according to priority. On the other hand, if the requirement were as simple as "just blink an LED every second," adopting an RTOS would not be worth the added memory and development cost—a simple polling loop (bare-metal) would be the right call. The presence of multiple independent periodic tasks, each with a different deadline constraint that interact with one another, is the archetypal condition that justifies adopting an RTOS.
Trap: "Using an RTOS improves overall throughput compared to a general-purpose OS" is wrong—an RTOS prioritizes deadline guarantees in the worst case (predictability), not average performance, and a general-purpose OS can sometimes achieve higher average throughput. Also wrong: "a task in the ready state immediately becomes running"—ready means waiting for CPU allocation, and the task does not transition to running until the scheduler actually selects it.
3.1.4Section summary
- An RTOS prioritizes worst-case predictability (deadline guarantees), not average performance
- A task transitions among running/ready/waiting; running-to-waiting is voluntary, while running-to-ready is a forced preemption
- RTOS adoption is favored when multiple independent periodic tasks interact with differing deadline constraints; bare-metal suffices for simple single-function processing
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. A developer is assigned to design an industrial terminal running (1) a 100 ms-period sensor read, (2) a 500 ms-period BLE transmission, and (3) instant button-press detection concurrently. What problem is most likely to arise if this is implemented bare-metal (a single polling loop)?
Q2. What is the most essential reason an RTOS kernel is better suited to embedded real-time control than a general-purpose OS kernel?
Q3. A task is in the **==waiting==** state, blocked on a semaphore, while a higher-priority task is running. The instant the semaphore is released, which state transition is correct for this task?