A Real-Time Operating System (RTOS) provides deterministic task scheduling for embedded systems where timing guarantees matter. Unlike general-purpose operating systems where tasks run "eventually," an RTOS ensures tasks meet their deadlines—critical for control systems, safety applications, and time-sensitive processing.
When Do You Need an RTOS?
Not every embedded system needs an RTOS. Many devices work fine with bare-metal programming (no OS) or a simple event loop. Consider an RTOS when:
- Hard timing requirements: Tasks must complete within guaranteed deadlines.
- Multiple concurrent activities: Multiple independent functions that need to run simultaneously.
- Complex synchronisation: Tasks need to coordinate and communicate safely.
- Priority-based scheduling: Some tasks are more urgent than others.
- Code organisation: RTOS provides structure for complex applications.
When to stay bare-metal: Simple, single-purpose devices; extremely resource-constrained systems (under 4KB RAM); when you can meet timing requirements with interrupt-driven design; or when you need maximum control over every CPU cycle.
Key RTOS Concepts
Tasks and Threads
Independent units of execution. Each task has its own stack and runs as if it owns the processor. The RTOS scheduler switches between tasks based on priority and scheduling policy.
Scheduling
Preemptive priority-based: Highest priority ready task always runs. If a higher-priority task becomes ready, it immediately preempts the running task.
Round-robin: Equal-priority tasks share time in rotation.
Rate-monotonic: Priorities assigned based on task period—shorter period = higher priority.
Synchronisation Primitives
- Semaphores: Control access to shared resources.
- Mutexes: Mutual exclusion with priority inheritance.
- Queues: Pass messages between tasks.
- Event flags: Signal events between tasks.
Determinism
The key RTOS property: predictable, bounded response times. Worst-case latencies are known and guaranteed. This determinism enables certification for safety-critical systems.
RTOS Comparison
FreeRTOS
The most popular open-source RTOS. Now owned by Amazon and integrated with AWS IoT. Extremely portable, runs on almost any microcontroller.
- Strengths: Mature, well-documented, huge community, MIT licence, minimal footprint (4-9KB).
- Weaknesses: Basic feature set, no built-in networking (use FreeRTOS+), limited security features in base.
- Best for: General-purpose embedded, AWS IoT integration, learning RTOS concepts.
Zephyr
Linux Foundation project with broad industry support. Modern design with extensive subsystems for connectivity, security, and device management.
- Strengths: Modern architecture, built-in Bluetooth/networking, active development, strong security focus.
- Weaknesses: Larger footprint, steeper learning curve, API still evolving.
- Best for: Connected devices, Bluetooth/BLE, devices needing modern connectivity stack.
VxWorks
Commercial RTOS 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, safety certifications, extensive tooling, commercial support.
- Weaknesses: Expensive licensing, vendor lock-in, overkill for simple projects.
- Best for: Safety-critical systems, aerospace, defence, medical devices.
ThreadX (now Azure RTOS)
Microsoft-acquired RTOS with small footprint and fast context switching. Now open source under MIT licence.
- Strengths: Tiny footprint, fast performance, safety certifications available, now free.
- Weaknesses: Microsoft ecosystem orientation, smaller community than FreeRTOS.
- Best for: Resource-constrained devices, Azure IoT integration.
—¼C/OS-III
Mature commercial RTOS with excellent documentation. Recently open-sourced by Silicon Labs.
- Strengths: Extensive documentation, textbook-quality code, safety certifications.
- Weaknesses: Smaller ecosystem than FreeRTOS/Zephyr.
- Best for: Learning RTOS internals, projects needing well-documented code.
Selection Criteria
Key Questions to Ask
- Does it support my target processor/MCU?
- Does the memory footprint fit my device?
- Do I need safety certification?
- What connectivity stacks do I need (TCP/IP, Bluetooth, etc.)?
- Is commercial support required?
- What's the licensing model?
| Criteria | FreeRTOS | Zephyr | VxWorks |
|---|---|---|---|
| Footprint | ~5KB | ~10KB+ | Varies |
| Licence | MIT | Apache 2.0 | Commercial |
| Safety certs | Available | In progress | Extensive |
| Networking | Add-on | Built-in | Built-in |
| Learning curve | Low | Medium | Medium |
Practical Advice
Start Simple
If you're new to RTOS development, start with FreeRTOS. It's simple, well-documented, and teaches core concepts without overwhelming complexity.
Consider the Ecosystem
The RTOS kernel is just the beginning. You'll need networking stacks, file systems, USB drivers, and more. Evaluate the complete ecosystem, not just the scheduler.
Don't Over-Engineer
An RTOS adds complexity. If you can solve your problem with a simple super-loop and interrupts, that's often better than introducing multitasking overhead.
Plan for Debugging
RTOS bugs (race conditions, priority inversion, stack overflow) are notoriously hard to debug. Ensure your RTOS has good debugging tools and trace capability.
Summary
For most projects: FreeRTOS provides the best balance of simplicity, maturity, and community support. For connected devices needing modern stacks: Zephyr is worth the learning investment. For safety-critical systems: VxWorks or another certified RTOS is worth the licensing cost.
Match the RTOS to your requirements—footprint constraints, certification needs, connectivity requirements, and team experience. And always ask: do I actually need an RTOS, or would bare-metal be simpler?