5 Popular RTOSes for Embedded Devices: A Practical Comparison
There is no reliable public market-share ranking for embedded RTOSes. In practice, FreeRTOS and Zephyr are common open-source starting points for connected MCU products; ThreadX is established in commercial and vendor ecosystems, while embOS and NuttX fit particular support and API needs. The best choice depends on the exact chip, drivers, middleware, licensing, and product lifetime.
Quick comparison
| RTOS | Typical fit | Hardware examples | Main trade-off |
|---|---|---|---|
| FreeRTOS | Small connected products; broad vendor SDK use | Cortex-M, ESP32, and many MCU families | Kernel is small; select and integrate additional components |
| Zephyr | Connected IoT with integrated drivers and networking | Cortex-M/A/R, RISC-V, Xtensa, x86 and many supported boards | Rich feature set brings a steeper build and configuration learning curve |
| Eclipse ThreadX | MCU products using a vendor stack or commercial support | Arm, RISC-V and other maintained processor ports | Check current port, middleware, and support details for your target |
| embOS | MCU products needing a commercial vendor and toolchain | Common MCU families including Arm Cortex-M | Commercial ecosystem and licensing; less open-source flexibility |
| Apache NuttX | MCU systems that benefit from POSIX-like APIs | Arm, RISC-V, AVR and other supported architectures | POSIX-style features can cost more memory and configuration effort |
“Supported” does not necessarily mean every peripheral is ready for production. Verify the exact board, silicon revision, drivers, debugging tools, and vendor maintenance commitment.
1. FreeRTOS
FreeRTOS is a frequent choice for small products because its kernel is compact, its task model is familiar, and MCU vendors commonly provide examples or integrate it into their SDKs. Official materials describe ports for more than 40 processor architectures.
- Good for: sensors, appliances, connected controllers, and firmware with several concurrent tasks.
- Hardware: many microcontroller families, including Arm Cortex-M and ESP32; check the vendor SDK or official demo list for the exact device.
- Pros: small footprint, broad ecosystem, lots of examples, straightforward scheduler and synchronization primitives.
- Cons: networking, file systems, and other components may need separate selection and integration; quality and maintenance vary by library.
Choose it when your chip vendor already supports it well and you want a small, familiar kernel. FreeRTOS supported demos show maintained vendor targets.
2. Zephyr
Zephyr combines an RTOS kernel with device drivers, networking, Bluetooth LE, power management, and a configurable build system. Its official documentation lists many architectures and more than a thousand supported boards and shields.
- Good for: connected devices that need Bluetooth, networking, and reusable drivers across board families.
- Hardware: Cortex-M, Cortex-A/R, RISC-V, Xtensa, x86, and many vendor development boards.
- Pros: integrated subsystems, consistent APIs, active open-source development, and extensive board coverage.
- Cons: configuration and build concepts take time to learn; board listing alone does not guarantee every peripheral is complete.
Choose it when you want an integrated platform and your target has solid board support. Check the Zephyr supported boards and architecture list.
3. Eclipse ThreadX
ThreadX is a compact RTOS with a long history in MCU products. Formerly Azure RTOS ThreadX, it is now maintained as Eclipse ThreadX, with companion components available for networking, USB, and file systems.
- Good for: established products, vendor SDK ecosystems, and teams that want a compact kernel with related middleware.
- Hardware: multiple processor families; consult the current ThreadX hardware support list for processor ports and toolchains.
- Pros: small kernel, mature task model, and a set of companion components.
- Cons: inspect the current status of the specific port and component you need; migration from another RTOS can mean porting middleware and adapting tooling.
Choose it when your silicon vendor or product stack already provides tested ThreadX support.
4. embOS
embOS is SEGGER’s commercial RTOS for deeply embedded systems. Teams often consider it when vendor support, integration with embedded tools, and a maintained commercial product matter.
- Good for: industrial, instrumentation, and commercial MCU products.
- Hardware: numerous MCU families, particularly Arm-based targets; confirm the exact chip and compiler in SEGGER’s embOS documentation.
- Pros: commercial support, mature tooling integrations, and a focused MCU-oriented design.
- Cons: licensing and toolchain choices add cost; compare support terms and long-term availability with open-source alternatives.
Choose it when paid support and the existing SEGGER toolchain fit your team and lifecycle.
5. Apache NuttX
NuttX is an open-source RTOS with POSIX and Unix-like interfaces. That can ease development for teams who want familiar APIs on MCU-class hardware without moving to a full Linux system.
- Good for: MCU products that benefit from POSIX-style APIs, a shell, or a richer set of system services.
- Hardware: a broad range of MCU architectures and boards, including Arm and RISC-V; consult the NuttX supported platforms.
- Pros: familiar interfaces, open development, and a wide range of built-in services.
- Cons: more system features can increase memory needs and configuration complexity; exact board support still matters.
Choose it when POSIX-like application code is useful and the target has adequate resources.
Which one should you start with?
- Your MCU vendor ships a supported RTOS and examples: start there; working drivers usually matter more than abstract feature comparisons.
- You need the smallest familiar kernel: evaluate FreeRTOS.
- You need integrated connectivity and broad board coverage: evaluate Zephyr.
- Your product stack already uses ThreadX or embOS: continuity and vendor support may outweigh a migration.
- You want POSIX-like APIs on an MCU: evaluate NuttX and budget memory for the services you enable.
Before committing, build a small prototype on the exact board. Check RAM and flash use, interrupt latency under load, sleep current, debugger support, security updates, licensing, and who will maintain the BSP for the product’s lifetime. An RTOS provides scheduling primitives; meeting timing and safety goals still depends on application design and system testing.