The decision of whether to use a Real-Time Operating System in an embedded design - and which one to choose if so - is one of the earliest and most consequential architectural decisions a firmware team makes. An RTOS changes not just how the firmware is structured but how tasks are scheduled, how stack overflows are detected, how inter-task communication is managed, and how the overall system responds to deadline violations. Getting this decision right requires honest assessment of what the application actually needs rather than defaulting to what the team knows or what the reference design recommends.
When Bare Metal is the Right Choice
Bare metal - firmware that runs without an RTOS, executing tasks through a main loop with interrupt service routines - is the right choice more often than RTOS advocates suggest. For single-function devices with a simple, predictable execution pattern - a sensor that reads a value and transmits it on a fixed schedule, a motor driver that executes a control algorithm in a timer ISR - bare metal eliminates the scheduler overhead, memory footprint, and conceptual complexity of an RTOS without sacrificing any meaningful capability. Bare metal is also the only option on MCUs with under 8 KB of RAM, where any RTOS kernel would consume a significant fraction of available memory.
When an RTOS Adds Value
An RTOS becomes the right choice when the application has multiple logically independent tasks with different timing requirements that are difficult to manage cleanly in a cooperative main loop. A gateway device that simultaneously maintains a Modbus polling cycle at 10ms, processes incoming MQTT messages at variable rates, manages an OTA download in the background, and handles a watchdog kick at 100ms has four independent timing requirements that conflict in a main loop. An RTOS scheduler resolves these conflicts by preempting lower-priority tasks when higher-priority deadlines arrive, making each task's timing independent of what other tasks are doing.
| RTOS | Min Flash | Min RAM | Safety Cert | Licensing | Best For |
|---|---|---|---|---|---|
| FreeRTOS | ~5 KB | ~4 KB | SAFERTOS variant | MIT | General embedded, IoT |
| Zephyr | ~32 KB | ~8 KB | None native | Apache 2.0 | Complex IoT, Matter |
| AUTOSAR OS | ~50 KB | ~10 KB | ISO 26262 ASIL D | Commercial | Automotive safety-critical |
| ThreadX (Azure) | ~6 KB | ~2 KB | IEC 61508 SIL 4 | MIT (Azure RTOS) | Industrial, medical |
| embOS | ~6 KB | ~1.5 KB | IEC 62304, DO-178C | Commercial | Medical, aerospace |
FreeRTOS: The Dominant Choice for General Embedded
FreeRTOS has the largest user base and ecosystem of any embedded RTOS. Its MIT licence imposes no restrictions on commercial use, its minimal 5 KB flash footprint suits Cortex-M0 through M7 devices, and its API is well-documented with extensive community support. FreeRTOS task management, queues, semaphores, and timer services cover the needs of most IoT and industrial embedded applications without requiring safety certification overhead. For automotive safety-critical applications, SAFERTOS - a pre-certified FreeRTOS variant from WITTENSTEIN safe technology - provides IEC 61508 SIL 3 and ISO 26262 ASIL D safety certification.
Zephyr: The Rising Choice for Complex IoT
Zephyr RTOS, maintained by the Linux Foundation, has gained significant momentum in complex IoT applications - particularly for Matter-compatible device development, where the official SDK targets Zephyr as its primary RTOS. Zephyr's device tree-based hardware abstraction, built-in networking stack, and comprehensive peripheral driver coverage make it a strong choice for devices that need Ethernet, Bluetooth LE, Thread, and Wi-Fi support in a single firmware. Its larger minimum footprint (32 KB flash) makes it unsuitable for the most constrained devices, but appropriate for Cortex-M33 and above class platforms.
Implementing RAPIDSEA Protocol Stacks on RTOS Platforms
RAPIDSEA's protocol stacks are designed to operate with or without an RTOS. All stacks provide a cyclic execution model - a stack task function that is called periodically and processes pending events - that maps directly to an RTOS task for RTOS-based deployments and to a main loop function call for bare metal deployments. The same stack binary works in both contexts without recompilation, enabling the RTOS decision to be made independently of the protocol stack integration. For RTOS-based deployments, RAPIDSEA provides recommended task priorities and stack sizes for each protocol stack component based on measured worst-case execution times on representative MCU platforms.
Conclusion
RTOS selection is a context-dependent decision that should be driven by the application's actual concurrency and timing requirements, available memory, safety certification needs, and team familiarity. Bare metal is often the right answer for simple applications; FreeRTOS for general embedded IoT and industrial; Zephyr for complex IoT platforms; AUTOSAR OS or SAFERTOS for safety-certified automotive. RAPIDSEA's RTOS-agnostic architecture supports all of these deployment contexts with the same protocol stack implementation.
Ready to integrate RAPIDSEA protocol stacks into your RTOS-based firmware? Contact our team to request an evaluation build or book a technical demo.