Embedded Operating Systems and RTOS: A Practical Guide by Use Case

A Wi-Fi router, a smartwatch, a car braking ECU, and a factory robot all contain embedded software, but they do not need the same operating system. Some run a tiny real-time kernel; others run Linux or a commercial safety-focused OS. Some use a software standard such as AUTOSAR rather than a standalone OS.

This guide covers the major OS families used in embedded products and what each is good at. It is not an exhaustive catalog: vendors and industries have many specialized systems, and hardware support changes over time.

First, separate the terms

• Bare metal: no operating system. Firmware runs directly on the MCU.
• RTOS: a real-time operating system that schedules tasks with bounded, predictable behavior when designed correctly.
• Embedded Linux: Linux customized for a product, often with a smaller user space and product-specific drivers and services.
• Build system: tools used to create an OS image. Yocto and Buildroot are build systems, not operating systems themselves.
• Platform or standard: software architecture and interfaces that may run on top of an OS. AUTOSAR is in this category.

A real-time OS does not automatically make an application safe, and Linux does not automatically mean a product is too slow. The right choice follows from workload, timing, memory, safety, connectivity, and maintenance needs.

Quick choice by product goal

These are common starting points, not mandates. A project can combine multiple processors and OSes.

1) Bare metal: one focused job, minimal footprint

Bare-metal firmware has no scheduler or general-purpose OS. The main loop handles routine work, and interrupts respond to events such as a timer tick or sensor input.

Good for: simple appliances, low-cost sensor nodes, small motor controllers, and devices that sleep most of the time.

Hardware: small microcontrollers such as AVR, PIC, STM32, or Cortex-M parts with tight flash and RAM budgets.

Strengths: smallest footprint, fast startup, few dependencies, and direct control of timing and power.

Trade-offs: as features grow, developers must build or manage their own task coordination, timers, drivers, and communication patterns. Complex concurrency becomes harder to maintain.

Example: a temperature sensor wakes periodically, samples an ADC, and sends one short radio message. A full OS may add little value.

2) Small RTOSes for MCU products

FreeRTOS

FreeRTOS is a widely used, small-footprint RTOS for microcontrollers and small microprocessors. It provides tasks, priorities, queues, semaphores, timers, and optional companion libraries for networking and IoT connectivity.

• Use it for: connected sensors, appliances, industrial instruments, and products that need a straightforward task scheduler.
• Hardware: many MCU families and small processors, including Arm and RISC-V devices; check the port and vendor SDK for the exact chip.
• Strengths: compact kernel, broad processor support, large body of examples, and a familiar task-based model.
• Trade-offs: projects choose and integrate many libraries themselves; its ecosystem can feel fragmented across vendors, and it is not a full Linux-style user-space system.

Example: a smart thermostat can run separate tasks for sensor sampling, display updates, Wi-Fi communication, and firmware-update status.

Zephyr

Zephyr is an open-source RTOS designed for connected and resource-constrained embedded systems. It includes a kernel, device drivers, networking, Bluetooth LE, power management, and a configurable build system.

• Use it for: IoT products, Bluetooth accessories, sensor nodes, and devices that need more integrated connectivity than a tiny kernel alone.
• Hardware: a broad set of supported MCU and MPU boards, including Arm, RISC-V, x86, Xtensa, and others. Verify support for the exact SoC and peripherals.
• Strengths: integrated subsystems, consistent APIs across boards, active open-source development, and compile-time configuration.
• Trade-offs: its build and configuration model takes time to learn; a supported board does not guarantee every peripheral or vendor feature is production-ready.

Example: a battery-powered environmental sensor can use Zephyr threads, BLE, sensor drivers, and low-power states in one configurable firmware image.

Eclipse ThreadX (formerly Azure RTOS ThreadX)

ThreadX is a compact RTOS used in deeply embedded products. The project is now maintained under Eclipse ThreadX.

• Use it for: MCU products needing a mature scheduler and companion components for file systems, USB, networking, or safety-focused development.
• Hardware: ports span numerous MCU and processor families; confirm current support and vendor toolchain availability.
• Strengths: small kernel, established commercial use, and a suite of companion middleware.
• Trade-offs: product support, qualification evidence, and tools depend on the specific project and supplier; moving between RTOS ecosystems can require porting middleware.

Other compact RTOS options

• NuttX: an open-source RTOS with POSIX-like APIs, useful when a small system benefits from familiar Unix-style interfaces. It runs on a wide range of MCUs and some application processors.
• RTEMS: an open-source real-time OS used in aerospace, scientific, and other long-lived embedded systems. It is designed for deterministic operation and supports multiple processor architectures.
• embOS: SEGGER’s commercial RTOS, often selected for MCU products that need vendor support and integration with its embedded tools.
• RIOT: an open-source OS for low-power IoT devices, with networking stacks and support for small microcontrollers.
• Contiki-NG: designed for constrained IoT nodes that use low-power IPv6 networking, including sensor-network devices.
• ChibiOS and µC/OS-III: compact RTOS options also found in MCU and industrial products; check current licensing, support, and exact chip coverage before selecting either.

For these systems, evaluate the exact board support package, drivers, networking needs, support model, and maintenance commitment. “Runs on Cortex-M” alone is not enough to establish a good fit.

3) Commercial RTOSes for demanding or regulated products

QNX Neutrino

QNX Neutrino uses a microkernel design: many services and drivers run as separate processes outside the kernel. This supports fault isolation and service restart, and QNX provides POSIX interfaces.

• Use it for: automotive systems, medical devices, industrial control, networking equipment, and other products where isolation and availability matter.
• Hardware: application processors such as ARM and x86; board support and certification scope depend on the product.
• Strengths: process isolation, mature development tools, POSIX compatibility, and commercial support.
• Trade-offs: licensing and engineering costs; availability of drivers and middleware for the exact hardware; certification still requires system-level work.

VxWorks

VxWorks is a commercial real-time OS used in aerospace, industrial, medical, automotive, and other mission-critical products.

• Use it for: systems that need deterministic scheduling, vendor support, and a path to safety or industry certification.
• Hardware: supported embedded processors and development boards listed by Wind River.
• Strengths: mature tooling, broad processor support, and commercial safety and security offerings.
• Trade-offs: license and vendor ecosystem costs, plus certification effort and constraints on component choice.

INTEGRITY

Green Hills INTEGRITY is a commercial RTOS and separation-kernel family used in safety- and security-sensitive embedded systems, including aerospace, automotive, and industrial designs.

• Use it for: systems that must isolate software components or partitions and need a vendor-backed certification path.
• Hardware: selected embedded processors and supported boards; verify exact target and qualification evidence with the vendor.
• Trade-offs: commercial tooling and support are valuable for some projects but bring cost and vendor dependence.

A certification claim applies to a defined product version, configuration, hardware, and development process. It does not transfer automatically to every application built on that OS.

4) Embedded Linux: networking, storage, UI, and rich applications

Linux is a common choice when a device needs processes, mature networking, filesystems, storage, complex drivers, or a graphical interface. It generally targets an application processor (MPU) with external RAM and persistent storage such as eMMC or flash. A standard Linux kernel is not a hard real-time OS, though tuning and real-time configurations can improve latency for suitable workloads.

OpenWrt

OpenWrt is an embedded Linux distribution focused on routers and network appliances. Its writable filesystem and package ecosystem make it easy to add features such as VLANs, VPNs, firewall rules, and traffic monitoring.

• Use it for: routers, access points, and network gateways.
• Hardware: supported networking SoCs and devices; verify the exact model and hardware revision in the OpenWrt Table of Hardware.
• Strengths: strong networking tools, flexibility, and a large package collection.
• Trade-offs: limited flash/RAM constrain features; Wi-Fi driver support varies by device; product maintainers must manage security updates.

Yocto Project and Buildroot

These are ways to build a custom Linux system, rather than separate kernels or operating systems.

• Yocto Project / OpenEmbedded: suited to products needing a reproducible, configurable Linux distribution with layers, package feeds, and long-term product maintenance. It is powerful, but its learning curve and build infrastructure are substantial.
• Buildroot: suited to generating a relatively compact, fixed-purpose Linux image with a simpler configuration and build flow. It is often easier to start with, but its update and package-management model differs from a full distribution workflow.

Both need a Linux-capable MPU platform and a maintained board support package. Pick based on image lifecycle, update strategy, team experience, and vendor support.

Other Linux choices

Some products use vendor-provided Linux SDKs, Debian or Ubuntu-based images, or Android. These can speed development when the board and software ecosystem match, but may need more storage and RAM than a tightly tailored image. For consumer devices, also consider the update and security-support lifetime, not just how quickly a demo boots.

5) Automotive platforms are a special case

AUTOSAR Classic and Adaptive

AUTOSAR is a standardized automotive software architecture and methodology, not one OS that installs on any board.

• Classic Platform: targets deeply embedded MCU-based ECUs. Its layers include application components, the Runtime Environment (RTE), Basic Software (BSW), and an AUTOSAR OS. Typical jobs include body control, powertrain, chassis, and sensor/actuator control.
• Adaptive Platform: targets high-performance computers. Adaptive applications use standardized AUTOSAR services over a POSIX OS, commonly embedded Linux or a commercial POSIX system. Typical jobs include advanced driver assistance, centralized compute, and service-oriented vehicle communication.

AUTOSAR can improve interfaces and integration across suppliers, but configuration, tools, integration, and validation are complex and often costly.

Android Automotive OS

Android Automotive OS (AAOS) runs directly on automotive hardware and is mainly used for in-vehicle infotainment: media, navigation, vehicle settings, and Android applications. It is different from Android Auto, which projects a phone interface onto the car display.

• Hardware: automotive application processors with RAM, graphics, and persistent storage.
• Strengths: Android application framework, rich UI, and a familiar ecosystem for infotainment.
• Trade-offs: larger compute and storage needs, automotive integration work, and a distinct safety boundary from real-time vehicle-control functions.

6) How to decide for a real product

Ask these questions before choosing:

1. What must respond on time? Motor control, braking, and protection loops have very different timing needs from a web dashboard.
2. What hardware is fixed? Check CPU architecture, RAM, flash, peripheral drivers, radio support, and vendor BSP status.
3. How much isolation is needed? Consider process protection, partitions, fault recovery, and whether one failing application may take down the device.
4. What connectivity and UI are required? Networking, USB, storage, display, audio, and updates can drive the choice toward Linux or an RTOS with the right middleware.
5. Who will maintain it? Plan for security patches, toolchain updates, hardware revisions, field diagnostics, and product lifetime.
6. Are there certification requirements? Confirm the exact OS version, hardware, tools, process evidence, and intended standard with the vendor and certification body early.

In short

There is no single “best embedded OS.” Bare metal fits tiny single-purpose firmware; FreeRTOS and Zephyr fit many MCU products; commercial RTOSes such as QNX, VxWorks, and INTEGRITY address demanding systems; embedded Linux fits gateways and rich applications; and AUTOSAR or Android Automotive address specific automotive needs. Match the platform to the product’s timing, hardware, safety, connectivity, and lifetime requirements.

References

• FreeRTOS
• Zephyr introduction and supported architectures
• Eclipse ThreadX
• RIOT documentation
• Contiki-NG documentation
• RTEMS documentation
• QNX Neutrino RTOS
• Wind River VxWorks
• OpenWrt documentation
• Yocto Project overview
• Buildroot manual
• AUTOSAR Classic Platform
• AUTOSAR Adaptive Platform
• Android Automotive OS