Embedded Real-Time
Operating Systems

Chapter 1: Real-Time vs Logical Time

Not all systems care about wall-clock time. When you sort a list, it doesn't matter if it takes 1ms or 100ms — the result is the same. That's logical time: only the ORDER of operations matters, not their exact timing.

But when your car's ABS system detects a wheel lock, it must release the brake within 5ms. If it responds in 6ms, the tire has already skidded. That's real-time: the wall clock is part of the correctness requirement. A correct answer delivered too late is a wrong answer.

Real-time systems are classified by what happens when a deadline is missed:

Hard real-time: Deadline miss = system failure. Examples: pacemaker pulse, airbag deployment, flight control surface actuation. Miss the deadline and someone may die.

Firm real-time: Late results have zero value but don't cause catastrophe. Examples: video frame rendering (a late frame is dropped, not displayed late), radar track updates. Missing one is tolerable; missing many degrades the system.

Soft real-time: Late results have diminished but nonzero value. Performance degrades gracefully. Examples: audio streaming (occasional buffer underrun = click), UI responsiveness (sluggish but still usable).

A deadline (D) is the latest time by which a task must complete after it is released. Often D = T (deadline equals period), meaning the task must finish before its next release. But D can be shorter than T (e.g., "compute within 5ms of every 20ms sensor reading").

If this inequality is ever violated for a hard real-time task, the system has failed — regardless of how many previous deadlines were met.

Chapter 2: Task Model & Priorities

In an RTOS, each job becomes a task — an independent thread of execution with its own stack, priority, and timing parameters. Think of tasks like musicians in an orchestra: each plays their own part at their own tempo, and the conductor (scheduler) decides who plays when.

Every periodic task is characterized by three numbers:

• Period (T) — How often the task runs. T=10ms means it activates every 10ms.
• Execution time (C) — How long the task takes to complete (worst case, WCET).
• Deadline (D) — Latest time after release by which it must finish. Often D=T.

The question is: how do we assign priorities? If two tasks are both ready to run, which one goes first?

Let's work through a concrete example. Three tasks:

Task A has the shortest period (10ms), so it gets highest priority. When A is ready, it preempts B and C immediately. B preempts C but yields to A. C only runs when neither A nor B needs the CPU.

Notice that utilization U = C/T for each task represents the fraction of CPU time that task consumes. Task A uses 3/10 = 30% of the CPU. Task B uses 5/25 = 20%. Task C uses 10/50 = 20%. Total = 70%. The CPU is idle 30% of the time.

If U > 1 (total utilization exceeds 100%), the system is DEFINITELY unschedulable — there's simply not enough CPU time. But U ≤ 1 doesn't guarantee schedulability either. That's what Chapter 3 addresses.

Chapter 3: Rate Monotonic Analysis

We know how to assign priorities (shortest period = highest priority). But how do we PROVE the system will meet all deadlines? That's schedulability analysis — the mathematical guarantee that no task will ever miss its deadline.

In 1973, Liu and Layland proved a landmark result: for n periodic tasks with D=T, Rate Monotonic scheduling guarantees all deadlines are met if:

This is the Liu & Layland bound. The right side is a sufficient (but not necessary) condition. If your utilization is below this bound, you're guaranteed schedulable. If it's above, you MIGHT still be schedulable but you need more detailed analysis.

Worked example: Our three tasks from Chapter 2: A(T=10, C=3), B(T=25, C=5), C(T=50, C=10).

The bound for n=3 is 0.780. Since 0.70 ≤ 0.780, the system is guaranteed schedulable under RM. No deadline will ever be missed.

Now consider: what if Task C takes 15ms instead of 10ms?

Now U = 0.80 > 0.780 (the n=3 bound). We CANNOT guarantee schedulability with this simple test. But note: it might still be schedulable — the bound is sufficient, not necessary. We'd need response time analysis (exact test) to be sure.

Chapter 4: Scheduling Algorithms

Rate Monotonic is one scheduling algorithm. There are several others, each with different tradeoffs. Let's compare the four major approaches.

Table-Driven (Static/Cyclic) Scheduling: The entire schedule is precomputed offline. A table says exactly which task runs at which time slot. Think of it like a train timetable — completely deterministic, zero runtime decisions. Used in safety-critical avionics (DO-178C) because the schedule can be formally verified before deployment.

Priority Preemptive Scheduling: Each task has a fixed priority. The highest-priority READY task always runs. If a higher-priority task becomes ready while a lower-priority task is running, it is immediately preempted (interrupted and suspended). Rate Monotonic is a specific priority assignment within this category.

Round-Robin: All tasks at the same priority level get equal time slices (quanta). After a task's quantum expires, it goes to the back of the queue. Fair but provides no timing guarantees for individual tasks. Often used as the policy WITHIN a priority level (same-priority tasks round-robin among themselves).

Earliest Deadline First (EDF): Dynamic priority — the task whose deadline is closest always runs next. Provably optimal: if ANY algorithm can schedule a task set, EDF can too. Achieves 100% utilization (U ≤ 1 is both necessary and sufficient). But it's harder to implement and analyze, and when overloaded it fails unpredictably (no task is guaranteed).

Table-driven in practice: The system designer computes a major frame (LCM of all periods) and a minor frame (GCD of all periods). Within each minor frame, specific tasks are assigned specific time slots. No runtime scheduler needed — just a timer interrupt that walks through the table.

c
// Table-driven schedule for tasks A(T=10), B(T=20), C(T=40)
// Major frame = LCM(10,20,40) = 40ms, Minor frame = GCD = 10ms
const schedule_table[] = {
    { TaskA, TaskB, TaskC },  // slot 0-10ms: A+B+C all run
    { TaskA },                // slot 10-20ms: only A
    { TaskA, TaskB },         // slot 20-30ms: A+B
    { TaskA },                // slot 30-40ms: only A
};  // then repeat from slot 0

Chapter 5: FreeRTOS Basics

FreeRTOS is the world's most deployed RTOS kernel — running on billions of microcontrollers from tiny Cortex-M0s to powerful ESP32s. It's open source, tiny (~9KB kernel), and provides the essential primitives: tasks, queues, semaphores, timers.

Creating a task in FreeRTOS requires specifying: a function to execute, a name (for debugging), stack size (in words, not bytes!), parameters, priority, and a handle for later reference.

c
void vSensorTask(void *pvParameters) {
    for(;;) {
        readTemperature();
        vTaskDelay(pdMS_TO_TICKS(10));  // sleep 10ms
    }
}

void vDisplayTask(void *pvParameters) {
    for(;;) {
        updateLCD();
        vTaskDelay(pdMS_TO_TICKS(100)); // sleep 100ms
    }
}

int main(void) {
    xTaskCreate(vSensorTask, "Sensor", 128, NULL, 3, NULL);
    xTaskCreate(vDisplayTask, "Display", 256, NULL, 1, NULL);
    vTaskStartScheduler();  // never returns
    return 0;
}

FreeRTOS tasks exist in one of four states:

The idle task is created automatically by FreeRTOS at priority 0 (lowest). It runs whenever no other task is ready. Its job: free memory from deleted tasks and (optionally) put the CPU into low-power sleep mode.

The tick interrupt fires every 1ms (configurable via configTICK_RATE_HZ). Each tick, the scheduler checks: has any blocked task's delay expired? Is there a higher-priority task now ready? If so, a context switch occurs.

c
// Complete 3-task LED blinker using FreeRTOS
#include "FreeRTOS.h"
#include "task.h"

void vRedLED(void *p) {
    for(;;) { togglePin(RED_PIN); vTaskDelay(pdMS_TO_TICKS(250)); }
}
void vGreenLED(void *p) {
    for(;;) { togglePin(GREEN_PIN); vTaskDelay(pdMS_TO_TICKS(500)); }
}
void vBlueLED(void *p) {
    for(;;) { togglePin(BLUE_PIN); vTaskDelay(pdMS_TO_TICKS(1000)); }
}

int main() {
    xTaskCreate(vRedLED,   "Red",   64, NULL, 3, NULL);
    xTaskCreate(vGreenLED, "Green", 64, NULL, 2, NULL);
    xTaskCreate(vBlueLED,  "Blue",  64, NULL, 1, NULL);
    vTaskStartScheduler();
}

Chapter 6: Synchronization — Semaphores & Mutexes

Tasks don't exist in isolation. They share resources: a UART peripheral, a global data buffer, an I2C bus. When two tasks access the same resource simultaneously, you get race conditions — corrupted data, garbled transmissions, undefined behavior.

Three synchronization primitives solve this:

Binary Semaphore: A flag with two states (available/taken). Used for signaling between tasks — "the data is ready, you can process it now." One task gives (signals), another takes (waits). Think of it like a baton pass in a relay race.

Counting Semaphore: A counter from 0 to N. Used to manage a pool of N identical resources. Example: 3 DMA channels available. Each take() decrements. Each give() increments. When count hits 0, tasks block until a resource is freed.

Mutex (Mutual Exclusion): Like a binary semaphore BUT with ownership — only the task that locked it can unlock it. Also supports priority inheritance (critical for avoiding priority inversion). Use mutexes for protecting shared data, semaphores for signaling.

The fix is priority inheritance: when H blocks on a mutex held by L, L temporarily inherits H's priority. Now M cannot preempt L. L finishes quickly, releases the mutex, drops back to its original priority, and H runs immediately.

c
// Mutex protecting shared temperature variable
SemaphoreHandle_t xTempMutex;
float shared_temperature = 0.0;

void vSensorTask(void *p) {
    for(;;) {
        float reading = readADC();
        if(xSemaphoreTake(xTempMutex, pdMS_TO_TICKS(10))) {
            shared_temperature = reading;  // protected write
            xSemaphoreGive(xTempMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

void vDisplayTask(void *p) {
    for(;;) {
        if(xSemaphoreTake(xTempMutex, pdMS_TO_TICKS(10))) {
            displayTemperature(shared_temperature); // protected read
            xSemaphoreGive(xTempMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

int main() {
    xTempMutex = xSemaphoreCreateMutex();  // has priority inheritance!
    xTaskCreate(vSensorTask,  "Sensor",  128, NULL, 3, NULL);
    xTaskCreate(vDisplayTask, "Display", 256, NULL, 1, NULL);
    vTaskStartScheduler();
}

Deadlock is another hazard: Task A holds Mutex 1 and waits for Mutex 2. Task B holds Mutex 2 and waits for Mutex 1. Both are blocked forever. Prevention: always acquire mutexes in the same global order, or use timeout on xSemaphoreTake().

Chapter 7: Multi-Task System (Showcase)

Let's build a complete RTOS application: a real-time control system with four tasks sharing data through queues and mutexes. This is the pattern you'll see in every professional embedded system — from drones to medical devices.

Our system has four tasks:

Utilization check: U = 0.3/1 + 2/10 + 15/100 + 50/1000 = 0.30 + 0.20 + 0.15 + 0.05 = 0.70. For n=4, bound = 0.757. Since 0.70 ≤ 0.757, we're schedulable.

Data flows through the system via queues and mutexes:

c
// Complete 4-task RTOS system with queues and mutexes
QueueHandle_t sensorQueue;
SemaphoreHandle_t motorMutex;
float motor_cmd = 0.0;

void vPIDTask(void *p) {
    float sensor_val;
    for(;;) {
        if(xQueueReceive(sensorQueue, &sensor_val, 0)) {
            float output = computePID(sensor_val);
            xSemaphoreTake(motorMutex, portMAX_DELAY);
            motor_cmd = output;
            xSemaphoreGive(motorMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(1));
    }
}

void vSensorTask(void *p) {
    for(;;) {
        float reading = readEncoder();
        xQueueSend(sensorQueue, &reading, 0);
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

void vDisplayTask(void *p) {
    for(;;) {
        xSemaphoreTake(motorMutex, portMAX_DELAY);
        lcd_printf("CMD: %.2f", motor_cmd);
        xSemaphoreGive(motorMutex);
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void vCommsTask(void *p) {
    for(;;) {
        xSemaphoreTake(motorMutex, portMAX_DELAY);
        uart_send("TELEM:%.2f\n", motor_cmd);
        xSemaphoreGive(motorMutex);
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

int main() {
    sensorQueue = xQueueCreate(10, sizeof(float));
    motorMutex  = xSemaphoreCreateMutex();
    xTaskCreate(vPIDTask,     "PID",     128, NULL, 4, NULL);
    xTaskCreate(vSensorTask,  "Sensor",  128, NULL, 3, NULL);
    xTaskCreate(vDisplayTask, "Display", 256, NULL, 2, NULL);
    xTaskCreate(vCommsTask,   "Comms",   256, NULL, 1, NULL);
    vTaskStartScheduler();
}

Chapter 8: Performance Analysis

Your RTOS design looks good on paper. Utilization is under the bound. Priorities are assigned. But real hardware has overheads that paper analysis ignores. Understanding these overheads is the difference between a system that works in the lab and one that works in production.

Context Switch Time: When the scheduler moves from Task A to Task B, it must save A's registers (R0-R15, PSP, FPU state), load B's registers, and update internal data structures. On a Cortex-M4 at 168MHz, this takes ~1-5μs. Seems tiny, but if your PID task runs at 10kHz (100μs period), a 5μs switch is 5% overhead PER switch.

Tick Interrupt Overhead: The system tick (typically 1kHz) fires every 1ms to check timeouts and do scheduling. Each tick ISR takes ~0.5-2μs. At 1kHz, that's 0.05-0.2% CPU — negligible for most systems, but it adds up with many software timers.

Stack Usage: Every task needs its own stack. Too small = stack overflow (silent memory corruption, the hardest bug to find). Too large = wasted RAM. A typical Cortex-M4 task needs 128-512 words (512-2048 bytes) depending on call depth and local variables.

c
// Stack usage monitoring
void vMonitorTask(void *p) {
    for(;;) {
        UBaseType_t hwm = uxTaskGetStackHighWaterMark(NULL);
        // hwm = minimum free stack words ever seen
        // If hwm < 20, you're dangerously close to overflow!
        printf("Stack free: %u words\n", hwm);
        vTaskDelay(pdMS_TO_TICKS(5000));
    }
}

// CPU utilization measurement (FreeRTOS runtime stats)
void vStatsTask(void *p) {
    char buf[512];
    for(;;) {
        vTaskGetRunTimeStats(buf);  // fills buf with per-task CPU%
        printf("%s\n", buf);
        vTaskDelay(pdMS_TO_TICKS(10000));
    }
}

Common RTOS failure modes:

Trace tools like Segger SystemView and Percepio Tracealyzer capture every context switch, ISR, and API call with sub-microsecond timestamps. They render as interactive timelines — invaluable for finding timing bugs that printf debugging can't reveal.

Chapter 9: Mastery & Connections

You now have the complete toolkit for designing real-time embedded systems: task modeling, schedulability analysis, algorithm selection, implementation with FreeRTOS, synchronization, and performance validation. Let's consolidate.

RMA Bounds Reference:

Scheduling Algorithm Decision Matrix:

FreeRTOS API Quick Reference:

Design Challenge: A quadcopter flight controller needs these tasks:

For n=5, the bound is 0.743. U = 0.86 > 0.743. The simple test FAILS! But U < 1.0, so exact response-time analysis might still show schedulability (since the bound is only sufficient, not necessary). This is where you'd compute R_i for each task iteratively — or you'd optimize WCETs, increase CPU clock, or split the GPS task into shorter chunks.

Connections:

• Control theory — the PID controller running inside your RTOS tasks
• Embedded C — the language all this code is written in
• State machines — how individual tasks are structured internally
• Digital signal processing — sensor filtering within real-time constraints