When you need an RTOS, and which one
- Use an RTOS when you have several concurrent activities with deadlines, such as sensing, communications and a user interface, that a single super-loop cannot manage cleanly.
- FreeRTOS is the pragmatic default: small, widely supported and easy to hire for. Zephyr is stronger where you need rich connectivity stacks, device-tree hardware description and broad board support.
- Most RTOS bugs are design bugs: priority inversion, unbounded blocking, stack overflow and shared-data races. They are found by architecture review and tracing, not by luck.
- We deliver the design as well as the code, with a task map, priority rationale and measured worst-case timings.
FreeRTOS or Zephyr?
| Factor | FreeRTOS | Zephyr |
|---|---|---|
| Footprint | Very small kernel, easy to fit small MCUs | Larger, scalable with Kconfig |
| Hardware support | Port per MCU, vendor SDKs integrate it | Broad board and driver support via device tree |
| Connectivity stacks | Add libraries (TCP/IP, MQTT, LoRaWAN) | Bluetooth, networking and more built in |
| Learning curve | Gentle | Steeper (devicetree, Kconfig, west) |
| Typical choice | STM32, ESP-IDF, existing codebases | Nordic nRF, new multi-vendor products |
There is no universally right answer. We recommend based on the MCU, the connectivity needed, and the skills your team will keep after we hand over.
How we design an RTOS application
- List every activity and its deadline, then map activities to tasks and interrupts.
- Assign priorities by deadline, not by perceived importance, and document the reasoning.
- Keep interrupt handlers short and defer work to tasks using queues or notifications.
- Use mutexes with priority inheritance for shared resources and avoid holding them across blocking calls.
- Size every stack from measured high-water marks and enable overflow detection.
- Add a task-level watchdog so a stuck task is detected, not just a stuck system.
Timing and verification
We trace task execution with tools such as SEGGER SystemView or Percepio Tracealyzer, measure interrupt latency and worst-case execution time on target hardware, and keep the results in the design note. Where a product needs a formal safety argument, this evidence is what an auditor will ask for.
Porting and migration
We port RTOS applications between MCU families, move super-loop firmware to an RTOS in stages, and migrate between FreeRTOS and Zephyr when a product outgrows its first choice. Related reading: firmware development and embedded systems.
Sources and further reading
- FreeRTOS — Kernel documentation, API reference and best practices.
- Zephyr Project documentation — Kernel, device tree, Kconfig and board support.
- Arm Developer — Cortex-M architecture and exception model references.
Last reviewed: October 2026. Regulations and product availability change; confirm current rules with the issuing authority before you commit to a design.