When you need an RTOS
A Real-Time Operating System provides deterministic task scheduling. It guarantees that tasks complete within defined time windows. That matters for control systems, safety-critical devices, and anything where missing a deadline causes real problems.
But here's the thing: most embedded projects don't actually need one. A bare-metal approach (no OS at all, just an event loop and interrupts) works perfectly for single-purpose devices with straightforward timing requirements. An RTOS adds complexity, and complexity adds bugs.
Consider an RTOS when:
- Hard timing requirements: tasks must complete within guaranteed deadlines, every time
- Multiple concurrent activities: several independent functions that need to run simultaneously without stepping on each other
- Complex synchronisation: tasks that need to coordinate, share data, and communicate safely
- Priority-based scheduling: certain operations must always preempt others
- Code organisation: the application is complex enough that an OS-level structure helps manage it
When to stay bare-metal: Simple, single-purpose devices. Systems with under 4KB of RAM. Projects where you can meet all timing requirements with interrupt-driven design. Situations where you need absolute control over every CPU cycle.
Key concepts
Tasks and threads
These are independent units of execution. Each task gets its own stack and runs as if it owns the processor entirely. The RTOS scheduler handles the illusion, switching between tasks fast enough that they all appear to run simultaneously.
Scheduling
Preemptive priority-based is the standard model: the highest-priority ready task always runs. If something more urgent wakes up, it immediately takes over from whatever was running. Round-robin shares time equally among same-priority tasks. Rate-monotonic assigns priorities based on task period: shorter period gets higher priority.
Synchronisation primitives
- Semaphores: control access to shared resources
- Mutexes: mutual exclusion with priority inheritance to prevent inversion
- Queues: pass messages between tasks safely
- Event flags: signal events from one task to another
Determinism
This is the whole point. An RTOS provides predictable, bounded response times. You know the worst-case latency and can guarantee it. That determinism is what enables certification for safety-critical systems where "usually fast enough" isn't acceptable.
RTOS comparison
FreeRTOS
The most popular open-source RTOS by a wide margin. Now owned by Amazon and integrated with AWS IoT. Runs on practically every microcontroller out there.
- Strengths: Mature, well-documented, enormous community, MIT licence, tiny footprint (4–9KB)
- Weaknesses: Basic feature set out of the box. No built-in networking (that's FreeRTOS+), limited security features in the base kernel.
- Best for: General-purpose embedded, AWS IoT integration, teams new to RTOS development
Zephyr
A Linux Foundation project with backing from Intel, Nordic, and NXP among others. Modern architecture with extensive built-in subsystems for connectivity, security, and device management.
- Strengths: Built-in Bluetooth/BLE and networking stacks, strong security focus, active development, modern design
- Weaknesses: Larger footprint than FreeRTOS, steeper learning curve, APIs still evolving
- Best for: Connected devices, anything needing Bluetooth/BLE, products that need a modern connectivity stack
VxWorks
The commercial heavyweight from Wind River. Industry standard for aerospace, defence, and safety-critical applications. Certified for DO-178C, IEC 62304, and other safety standards.
- Strengths: Proven reliability, extensive safety certifications, commercial support, comprehensive tooling
- Weaknesses: Expensive licensing, vendor lock-in, overkill for anything that doesn't need certification
- Best for: Aerospace, defence, medical devices, anything requiring formal safety certification
ThreadX (Azure RTOS)
Acquired by Microsoft, now open source under MIT licence. Known for tiny footprint and fast context switching.
- Strengths: Minimal footprint, fast performance, safety certifications available, free to use
- Weaknesses: Tilted toward the Microsoft/Azure ecosystem, smaller community than FreeRTOS
- Best for: Resource-constrained devices, projects integrating with Azure IoT
µC/OS-III
A mature RTOS recently open-sourced by Silicon Labs. The codebase reads like a textbook, literally, because it was written alongside one.
- Strengths: Exceptional documentation, textbook-quality code, safety certifications available
- Weaknesses: Smaller ecosystem than the bigger players
- Best for: Teams that want to understand RTOS internals deeply, projects where code clarity matters
Selection criteria
Before picking an RTOS, answer these questions:
- Does it support your target processor/MCU?
- Does the memory footprint fit your hardware constraints?
- Do you need safety certification (DO-178C, IEC 62304, IEC 61508)?
- What connectivity stacks do you need: TCP/IP, Bluetooth, USB?
- Is commercial support required, or is community support sufficient?
- What's the licensing model, and does it fit your product's commercial model?
Quick comparison
| Criteria | FreeRTOS | Zephyr | VxWorks | ThreadX |
|---|---|---|---|---|
| Footprint | ~5KB | ~10KB+ | Varies | ~2KB |
| Licence | MIT | Apache 2.0 | Commercial | MIT |
| Safety certs | Available | In progress | Extensive | Available |
| Networking | Add-on | Built-in | Built-in | Add-on |
| Learning curve | Low | Medium | Medium | Low |
Practical advice
Start simple
If your team is new to RTOS development, start with FreeRTOS. It teaches the core concepts without burying you in configuration and build system complexity. You can always migrate later if you outgrow it.
Consider the ecosystem
The RTOS kernel is just the starting point. You'll also need networking stacks, file systems, USB drivers, crypto libraries, and debugging tools. Evaluate the complete package. A fantastic kernel with no networking support isn't helpful if your device needs WiFi.
Don't over-engineer
An RTOS adds a layer of complexity that brings its own class of bugs: race conditions, priority inversion, stack overflow, deadlocks. If you can solve the problem with a simple super-loop and a few interrupts, that's often the better choice.
Plan for debugging
RTOS bugs are notoriously difficult to reproduce and diagnose. Before committing to an RTOS, make sure it has decent trace and debugging tools. SystemView (SEGGER), Percepio Tracealyzer, and similar tools can save weeks of head-scratching.
Frequently asked questions
Can I switch from bare-metal to RTOS later?
Yes, but it's easier if you plan for it. Structure your bare-metal code as discrete tasks with clear interfaces, and the migration to an RTOS is mostly mechanical. If the code is a single monolithic loop, the refactoring effort can be significant.
Is FreeRTOS still free now that Amazon owns it?
Yes. FreeRTOS uses the MIT licence, which imposes no restrictions. Amazon monetises through AWS IoT services, not the RTOS itself.
How do I decide between FreeRTOS and Zephyr?
If your device needs Bluetooth/BLE, built-in networking, or advanced peripheral support, Zephyr is worth the steeper learning curve. If you want simplicity and wide MCU support, FreeRTOS. For AWS IoT specifically, FreeRTOS has the better integration.
What about Linux for embedded?
Embedded Linux is a different category. It's for devices with enough resources to run a full OS (typically 32MB+ RAM, MMU-capable processor). It's not real-time by default, though RT-PREEMPT patches or a co-processor running an RTOS can help. If you have the hardware for it, Linux gives you a much richer environment.
Key takeaways
- Not every embedded system needs an RTOS. Many devices work fine with bare-metal or a simple event loop.
- FreeRTOS offers the best balance of simplicity, maturity, and community for most projects.
- For connected devices needing modern networking stacks, Zephyr is worth the learning curve.
- Safety-critical applications (aerospace, defence, medical) generally require a certified commercial RTOS like VxWorks.
