Skip to content

10. Real time and RTOS

Time: 2 to 3 weeks · Board: STM32 Nucleo · Prerequisites: Module 9

Why this matters

"Real time" does not mean fast. It means a deadline is part of correctness: the motor current must be sampled every 50 microseconds, the brake signal must be acted on within 10 milliseconds, every time, or the system has failed. An RTOS is one tool for meeting deadlines when a system has many things to do at once. It is also the easiest way to create bugs you have never seen before: deadlocks, priority inversion, and stack overflows that only appear on Tuesdays. This module teaches when you need an RTOS, when you do not, and how to use one without hurting yourself.

You will be able to

  • Define hard and soft real time, jitter, latency, and worst-case execution time, and say which your project needs.
  • Choose between a superloop, an event-driven design, an RTOS, and Linux for a given product, with reasons.
  • Use tasks, queues, semaphores, mutexes, and software timers in FreeRTOS, and explain what each costs.
  • Explain and reproduce priority inversion and deadlock, then fix them.
  • Get started with Zephyr and know why the industry is moving toward it.

Learn

  • Article Operating Systems for Embedded Software by Michael Barr ~45 min
    What an RTOS does, how a scheduler works, and the primitives, from first principles.
  • Video Introduction to RTOS by Shawn Hymel, DigiKey 12 parts, ~4 h
    The gentlest complete FreeRTOS course: tasks, memory, queues, mutexes, semaphores, timers, interrupts, deadlock, priority inversion, multicore. Uses an ESP32 but every concept applies; do the exercises on your Nucleo instead.
  • Book Mastering the FreeRTOS Real Time Kernel by Richard Barry ~8 h, free
    The official book, kept current on GitHub. Read chapters on tasks, queues, and resource management closely.
  • Article Mutexes and Semaphores Demystified by Michael Barr ~30 min
    They are not interchangeable. The clearest explanation of why.
  • Video Modern Embedded Systems Programming Course by Miro Samek RTOS lessons (around 22 to 30), ~5 h
    Samek writes a minimal RTOS from scratch on video: context switch, scheduler, blocking. After this, no RTOS is a black box. Then his lessons on the superloop vs RTOS vs active objects debate.
  • Course Embedded System Engineering lectures by Phil Koopman, CMU Real-time scheduling lectures, ~2 h
    Rate monotonic scheduling, blocking, and the math that tells you whether your deadlines are met.
  • Docs Zephyr Project: Introduction and Getting Started ~3 h with setup
    Zephyr is a Linux Foundation RTOS with a device tree, a build system, and drivers for hundreds of boards, and it is what many new products are built on. Build blinky and hello_world for your Nucleo.
  • Course nRF Connect SDK Fundamentals by Nordic Developer Academy ~8 h, free
    The best structured Zephyr course, built around Nordic's chips. Lessons 1 to 4 (build system, device tree, GPIO, threads) transfer to any Zephyr board.

Which one?

Approach Use when Watch out for
Superloop (poll everything, ISRs set flags) Few tasks, simple timing, tiny MCU. Most small products. Grows into spaghetti; one slow function delays everything.
Event-driven (queues of events, run-to-completion handlers, state machines) Many independent behaviors, deterministic timing, safety-relevant code. Requires discipline about never blocking. Module 9 taught the pieces.
RTOS (preemptive tasks) Tasks with genuinely different rates or priorities; third-party stacks (USB, TCP/IP, BLE) that expect threads. Shared data, priority inversion, stack sizing, harder debugging.
Linux Networking, filesystems, displays, lots of RAM, boot time in seconds is acceptable. Not hard real time without effort; power and cost. Module 15.

Do

  • Checkpoint 10.1: Measure before you assume. In your Module 9 superloop project, toggle a GPIO at the top of the loop and look at it on the logic analyzer. Measure the loop period and its jitter while the UART is busy. Write down your worst-case number. This is why an RTOS might (or might not) be needed.
  • Checkpoint 10.2: FreeRTOS on the Nucleo. Add FreeRTOS (CubeMX can do it) and split your project into tasks: sensor sampling at a fixed rate, a UART CLI task, and an LED/status task. Pass sensor data through a queue. Verify the sampling task's period on the logic analyzer with the CLI active and compare to 10.1.
  • Checkpoint 10.3: Break it three ways. (a) Share a variable between two tasks without protection and make the corruption visible. Fix it with a mutex. (b) Create a priority inversion: low-priority task holds a mutex the high-priority task wants, medium-priority task hogs the CPU. Watch the high-priority task starve; fix it with priority inheritance. (c) Under-size a task's stack and watch it crash; then use the RTOS's high-water-mark API to size every stack from data.
  • Checkpoint 10.4: Zephyr blinky and sensor. Build Zephyr's blinky for your Nucleo. Then wire up your I2C sensor through Zephyr's device tree and sensor API instead of your own driver, and print readings. Note what the device tree replaced from your BSP.

Check yourself

  • A system samples audio at 48 kHz and updates a display at 30 Hz. Which is hard real time, which is soft, and why?
  • What is the difference between a binary semaphore and a mutex, and why should an ISR never take a mutex?
  • Describe priority inversion in two sentences, and name the standard fix.
  • Two tasks each take mutex A then mutex B, but in opposite order. What happens, and what is the rule that prevents it?
  • Why does an RTOS need per-task stacks, and how do you decide how big each one is?

Go deeper

Optional extras
  • Docs FreeRTOS documentation Reference
    The API reference and the kernel configuration options you will tune.
  • Video Embedded Security, Safety and Software Quality by Phil Koopman Concurrency and timing lectures, ~1.5 h
    Race conditions and timing failures as they show up in shipped products.
  • Community Golioth blog Ongoing
    Practical Zephyr articles from a team that uses it daily.
  • Other RTOSes, in one line each: Eclipse ThreadX (formerly Azure RTOS, safety-certified, now open source), Micrium µC/OS (classic, now open source), RTX (Arm's own, part of CMSIS). If you know FreeRTOS and Zephyr, the others take an afternoon.