RTOS Explained: Real-Time Operating Systems for IoT

An RTOS Adds Managed Multitasking to Bare Metal

Bare-metal firmware runs one thing at a time — a main loop, with interrupts occasionally breaking in. This works for simple devices. But a modern IoT device might need to: read sensors every 100ms, process Bluetooth packets as they arrive, run a control loop at 1kHz, publish MQTT data every 30 seconds, and handle user button presses — all "simultaneously."

An RTOS (Real-Time Operating System) solves this. It's a small kernel (10-50KB) that runs on the microcontroller alongside your application code. It manages multiple tasks, schedules which task runs when, and provides mechanisms for tasks to communicate safely.

The "real-time" part means the RTOS guarantees timing behavior. A high-priority task will always get CPU within a bounded time after it becomes ready — no surprise delays from other tasks hogging the CPU.

Tasks and the Scheduler

A task (also called a thread in some RTOS) is an independent function with its own stack and execution state. The RTOS scheduler decides which task runs based on priority and availability.

Task states in FreeRTOS:

• Running — Currently executing on the CPU (only one task runs at a time on single-core MCU)
• Ready — Ready to run, waiting for CPU time
• Blocked — Waiting for something: a delay (vTaskDelay), a queue item, a semaphore, a mutex
• Suspended — Explicitly suspended by the application

Preemptive priority scheduling — The scheduler runs the highest-priority ready task. If a higher-priority task becomes ready while a lower-priority task runs, the scheduler immediately switches (preempts) to the higher-priority task. This is how RTOS guarantees real-time response.

// FreeRTOS task creation example
void SensorTask(void* pvParameters) {
    while(1) {
        float temp = ReadTemperature();
        // Post to queue for processing task
        xQueueSend(xSensorQueue, &temp, 0);
        vTaskDelay(pdMS_TO_TICKS(100));  // Wait 100ms
    }
}

void NetworkTask(void* pvParameters) {
    float temp;
    while(1) {
        // Block waiting for sensor data
        if (xQueueReceive(xSensorQueue, &temp, portMAX_DELAY)) {
            PublishMQTT(temp);
        }
    }
}

// In main():
xTaskCreate(SensorTask, "Sensor", 256, NULL, 2, NULL); // Priority 2
xTaskCreate(NetworkTask, "Network", 512, NULL, 1, NULL); // Priority 1
vTaskStartScheduler();

Inter-Task Communication: Queues, Semaphores, Mutexes

Tasks can't just use global variables to communicate — concurrent access causes race conditions. RTOS provides safe primitives:

Queues — Thread-safe FIFO buffers for passing data between tasks. Producer task pushes; consumer task pops. The FreeRTOS example above uses a queue to pass sensor readings from SensorTask to NetworkTask. Queues are the workhorse of RTOS IPC.

Semaphores — Signaling mechanism. Binary semaphore: 0 or 1. ISR gives the semaphore when an event occurs; a task blocks waiting to take it. Counting semaphore: counts multiple events, used for resource pools.

// Binary semaphore — ISR signals task
SemaphoreHandle_t xButtonSemaphore;

void EXTI15_10_IRQHandler(void) {    // ISR
    if (button_interrupt_pending) {
        BaseType_t xHigherPriorityTaskWoken = pdFALSE;
        xSemaphoreGiveFromISR(xButtonSemaphore, &xHigherPriorityTaskWoken);
        portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
    }
}

void ButtonHandlerTask(void* pvParameters) {
    while(1) {
        // Block until ISR signals
        if (xSemaphoreTake(xButtonSemaphore, portMAX_DELAY) == pdTRUE) {
            HandleButtonPress();
        }
    }
}

Mutex — Mutual exclusion. Prevents two tasks from accessing a shared resource simultaneously. Different from binary semaphore: mutexes have ownership (only the task that took it can give it) and priority inheritance (prevents priority inversion).

MutexHandle_t xUARTMutex;

void TaskA(void* pvParameters) {
    while(1) {
        xSemaphoreTake(xUARTMutex, portMAX_DELAY);  // Lock UART
        printf("Task A: sensor value = %d\r\n", ReadSensor());
        xSemaphoreGive(xUARTMutex);                   // Unlock
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

FreeRTOS: The World's Most Deployed RTOS

FreeRTOS is used in hundreds of millions of devices. Key reasons for its dominance:

• MIT license — free for commercial use
• Tiny footprint — core kernel fits in ~10KB flash
• Extensive documentation and community
• Amazon acquired it in 2017 — now AWS FreeRTOS for cloud-connected devices
• Supported on virtually every ARM Cortex-M MCU plus many others

FreeRTOS configuration is done in FreeRTOSConfig.h — you enable/disable features at compile time. Heap management is pluggable: heap_1.c (no free), heap_2.c (simple), heap_4.c (best-fit, most common), heap_5.c (multiple memory regions).

FreeRTOS vs Zephyr: Choosing Your RTOS

RTOS in IoT Applications

A typical IoT device firmware with FreeRTOS might have these tasks:

• SensorTask (high priority) — Reads sensors at fixed intervals, posts to queue
• ControlTask (high priority) — Runs control algorithm (PID loop, state machine) based on sensor data
• NetworkTask (medium priority) — Handles WiFi/MQTT: publish telemetry, receive commands
• StorageTask (low priority) — Writes data to SD card or flash when network is unavailable
• UITask (low priority) — Updates display or LED status indicators

The RTOS scheduler ensures SensorTask and ControlTask always run on time, while NetworkTask (which blocks on I/O) and lower-priority tasks fill the remaining CPU time.

When to Use an RTOS vs Bare Metal