Mastering Embedded Concurrency: FreeRTOS Task Scheduling and Semaphore Design

Mastering Embedded Concurrency: FreeRTOS Task Scheduling and Semaphore Design

Every embedded engineer begins their journey with the ubiquitous Super-Loop pattern:

void loop() {
    read_sensors();
    update_motor_pwm();
    transmit_telemetry();
    delay(100);
}

This pattern works well for elementary hobby prototypes. But in commercial firmware—such as an automated braking controller, agricultural drone, or biometric terminal—a blocking sensor read or network transmission stalls critical control loops, causing catastrophic failure.

To build deterministic, fault-tolerant hardware systems, we must transition to a Real-Time Operating System (RTOS).

1. Preemptive Fixed-Priority Scheduling

Unlike desktop operating systems (Linux/Windows) that optimize for fair throughput, an RTOS like FreeRTOS optimizes for strict temporal determinism:

• Each task is assigned a numerical priority (e.g., 0 lowest to configMAX_PRIORITIES - 1 highest).
• The scheduler guarantees that the highest priority task ready to run will always execute immediately.
• If a higher-priority task transitions from Blocked to Ready (e.g., an interrupt signals new telemetry), the running lower-priority task is preempted on the next CPU tick.

Context Switching on ARM Cortex-M

On ARM Cortex-M microcontrollers (STM32, ESP32, nRF52), FreeRTOS uses two specialized hardware exception handlers:

1. SysTick Timer: Generates periodic timer interrupts (typically every 1ms).
2. PendSV (Pipelined Service Call): Low-priority exception used to swap register frames ($R0-R3, R12, LR, PC, xPSR$) to task stacks without disturbing urgent peripheral interrupts.

2. Synchronization Primitives: Mutexes vs. Semaphores

A frequent source of embedded firmware bugs is treating Semaphores and Mutexes as interchangeable:

3. The Classic Priority Inversion Catastrophe

Consider three tasks:

• High Priority (Task H): Flight navigation guidance (Priority 3)
• Medium Priority (Task M): Communications processing (Priority 2)
• Low Priority (Task L): Data logger reading an I2C sensor (Priority 1)

1. Task L acquires the I2C mutex.
2. Task H preempts Task L and attempts to acquire the I2C mutex. Since it is locked, Task H enters the Blocked state.
3. Task M wakes up. Because Task M has priority 2 (higher than Task L's priority 1), Task M preempts Task L.
4. Catastrophe: Task L cannot finish its work to release the mutex. Task M is running, while Task H (the most critical task) is starved! This exact bug caused the Mars Pathfinder spacecraft to reboot continuously on Mars in 1997.

The Solution: Priority Inheritance

FreeRTOS Mutexes implement Priority Inheritance: when Task H blocks on a mutex held by Task L, Task L's priority is temporarily boosted to match Task H. Task M cannot preempt Task L, allowing Task L to quickly release the mutex.

sequenceDiagram
    autonumber
    participant High as High-Priority Task (Flight Control)
    participant Med as Medium-Priority Task (Telemetry Logging)
    participant Low as Low-Priority Task (Sensor Poll)
    participant Mutex as Mutex (SPI Bus Semaphore)

    Note over Low,Mutex: Normal Unprotected Inversion Bug
    Low->>Mutex: 1. xSemaphoreTake(SPI_Mutex) [ACQUIRED]
    Note over Low: Low-priority task begins slow SPI reading
    High-->>Low: 2. High-priority task wakes up (Preempts Low)
    High->>Mutex: 3. Wants SPI_Mutex -> BLOCKED!
    Med-->>Low: 4. Med task wakes up (Preempts Low!)
    Note over Med: Med runs indefinitely starving Low task!<br/>High-priority task remains starved!

    Note over High,Low: FreeRTOS Priority Inheritance Protocol Fix
    Low->>Mutex: 5. xSemaphoreTake(SPI_Mutex) [ACQUIRED]
    High->>Mutex: 6. High task attempts to take Mutex -> Blocks
    Note over Low,Mutex: Priority Inheritance triggers:<br/>Low task priority temporarily ELEVATED to High!
    Med-->>Low: 7. Med task tries to preempt -> DENIED! (Low is now High)
    Low->>Mutex: 8. Low finishes critical section -> xSemaphoreGive()
    Note over Low: Low task priority drops back to normal priority
    Mutex-->>High: 9. High-priority task instantly acquires Mutex!

4. Practical FreeRTOS Producer-Consumer Pattern

#include "FreeRTOS.h"
#include "task.h"
#include "queue.h"

#define QUEUE_LENGTH 16
#define ITEM_SIZE sizeof(SensorData_t)

typedef struct {
    uint32_t timestamp;
    float temperature;
    float humidity;
} SensorData_t;

QueueHandle_t sensorQueue;

// High-Priority Consumer: Telemetry Dispatch
void TelemetryTask(void *pvParameters) {
    SensorData_t receivedData;
    for (;;) {
        // Block indefinitely until an item arrives in the queue
        if (xQueueReceive(sensorQueue, &receivedData, portMAX_DELAY) == pdPASS) {
            transmit_over_radio(&receivedData);
        }
    }
}

// Medium-Priority Producer: Periodic Sensor Reader
void SensorReadTask(void *pvParameters) {
    TickType_t xLastWakeTime = xTaskGetTickCount();
    const TickType_t xFrequency = pdMS_TO_TICKS(50); // Exact 20 Hz loop

    SensorData_t currentReading;
    for (;;) {
        currentReading.timestamp = xTaskGetTickCount();
        currentReading.temperature = read_sensor_temp();
        currentReading.humidity = read_sensor_humidity();

        // Non-blocking push to queue
        xQueueSend(sensorQueue, ¤tReading, 0);

        // Sleep until exact next 50ms period (no drift)
        vTaskDelayUntil(&xLastWakeTime, xFrequency);
    }
}

The Kone Lab Engineering Standard

At Kone Lab, our students construct autonomous robotics and edge telemetry devices utilizing FreeRTOS and bare-metal ARM firmware in our Embedded Systems & Circuit Prototyping Track.