Short notes

RTOS Basics Short Notes

A medical pulse-oximeter firmware running on STM32 cannot afford to process sensor data and update the display in one giant while(1) loop — missed timing means a wrong reading. FreeRTOS solves this by giving each job its own task: a high-priority task at 1 ms period reads the MAX30100 sensor over I2C, while a lower-priority display task refreshes the SSD1306 OLED every 100 ms. The scheduler, triggered by SysTick every 1 ms, decides which task runs — the developer just assigns priorities and stack sizes.

ECE, EI

How it works

FreeRTOS uses a preemptive, priority-based scheduler by default. Each task has its own stack, typically 128–512 words depending on local variable usage. xTaskCreate() registers a task; vTaskDelay(pdMS_TO_TICKS(100)) puts it to sleep for 100 ms, allowing lower-priority tasks to run. Semaphores coordinate access to shared resources: a binary semaphore protects a shared SPI bus from being accessed by two tasks simultaneously. Queues pass data between tasks safely — a sensor task sends a uint16_t ADC value into a queue, and a processing task blocks waiting to receive it, without polling.

Key points to remember

A real-time system must meet deadlines — hard real-time means a missed deadline causes system failure, soft real-time means degraded performance. FreeRTOS tick period is typically 1 ms, set by configTICK_RATE_HZ = 1000 in FreeRTOSConfig.h. Task priorities range from 0 (idle) to configMAX_PRIORITIES-1; higher number means higher priority. Stack overflow detection is enabled via configCHECK_FOR_STACK_OVERFLOW. Context switching on Cortex-M uses the PendSV interrupt at the lowest priority, which prevents it from interrupting critical hardware ISRs.

Exam tip

Anna University and VTU both regularly ask you to compare RTOS and bare-metal (super-loop) approaches — know the specific advantages of RTOS around determinism, modularity, and blocking delays versus busy-wait loops.

More Embedded Systems notes