Choosing an RTOS in 2026: Zephyr, FreeRTOS, NuttX, RTEMS and PREEMPT_RT Linux Compared

Choosing a real-time operating system used to be a short conversation: a commercial kernel for anything serious, a home-grown loop for anything small. In 2026 the open-source options are mature enough that most teams start with an open RTOS shortlist. The usual candidates are Zephyr, FreeRTOS, Apache NuttX, RTEMS and, now that PREEMPT_RT is part of mainline, real-time Linux. All five can meet deadlines, but they differ a lot in footprint, programming model, ecosystem, governance and certification story.

This guide compares them from a timing-first perspective. We look at how each one schedules work, what it takes to get predictable latency, and which project characteristics tend to matter five years into a product’s life. It is not a ranking: the right answer depends on your hardware, your deadlines and your constraints.

Start with timing requirements, not features

Teams often pick an RTOS by counting drivers and protocol stacks. Those matter, but they are easier to add later than determinism. Before comparing kernels, write down:

• The tightest deadline and the tolerated jitter. A 50 µs current-control loop and a 10 ms telemetry task need different platforms. If you aren’t sure how hard your deadlines are, see hard, firm and soft deadlines explained.
• The processor class. Is it a Cortex-M or RISC-V microcontroller with an MPU and kilobytes of RAM, or an application processor with an MMU and hundreds of megabytes?
• The core count and how cores will be used. Will you run a single core, asymmetric multiprocessing (AMP) or symmetric multiprocessing (SMP)? Multicore introduces scheduling and interference questions covered in our multicore scheduling guide.
• Certification targets. Examples are IEC 61508, ISO 26262, DO-178C, IEC 62304 or ECSS. You may also have none.
• Product lifetime. A connected consumer device may ship updates for three years; an industrial controller may need maintenance for fifteen.

With that list in hand, the comparison below is much easier to read.

The five candidates at a glance

Zephyr: the broad microcontroller platform

Zephyr launched in 2016 as a Linux Foundation project and has grown into one of the most active open-source RTOS projects. It supports hundreds of boards across Arm, RISC-V, x86, Xtensa and other architectures. It borrows the Linux way of configuration: Kconfig for features, devicetree for hardware description, and the west meta-tool for managing repositories and builds.

Scheduling model

Zephyr threads have a priority. Negative priorities are cooperative: these threads are never preempted by other threads. Non-negative priorities are preemptible. With CONFIG_SCHED_DEADLINE, threads of equal priority are ordered by a deadline set through k_thread_deadline_set(), which gives a form of EDF within a priority band. A tickless kernel, time slicing and SMP are all configuration options:

# prj.conf: a timing-oriented Zephyr configuration
CONFIG_TICKLESS_KERNEL=y
CONFIG_SYS_CLOCK_TICKS_PER_SEC=10000
CONFIG_TIMESLICING=n
CONFIG_SCHED_DEADLINE=y      # EDF among threads of equal priority
CONFIG_USERSPACE=y           # MPU-based isolation of user threads
CONFIG_SMP=n                 # keep single-core unless you need it

Strengths and caveats

Zephyr’s strengths are its breadth (networking, Bluetooth LE, USB, file systems, power management), its long-term-support (LTS) releases and its formal security and safety processes. The project has worked toward IEC 61508 certification of a defined subset of the kernel. The trade-off is complexity: the build system, devicetree and the sheer size of the codebase take time to learn, and the default footprint is larger than FreeRTOS’s.

FreeRTOS: small, simple and everywhere

FreeRTOS is probably the most widely deployed RTOS kernel in microcontrollers. It has been MIT-licensed and stewarded by Amazon Web Services since 2017. The kernel itself is a handful of C files: tasks, queues, semaphores, mutexes with priority inheritance, software timers and event groups. Its ROM footprint is typically in the single-digit kilobytes. Kernel V11 merged symmetric multiprocessing support into the main codebase.

/* FreeRTOSConfig.h: timing-relevant settings */
#define configUSE_PREEMPTION        1
#define configUSE_TIME_SLICING      0   /* no round-robin among equal priorities */
#define configTICK_RATE_HZ          1000
#define configMAX_PRIORITIES        16
#define configUSE_MUTEXES           1   /* mutexes use priority inheritance */
#define configUSE_TICKLESS_IDLE     1   /* low-power idle */
#define configNUMBER_OF_CORES       1   /* >1 enables the SMP scheduler (V11+) */

FreeRTOS’s simplicity is a timing advantage. Fixed-priority preemptive scheduling with a small, well-understood kernel maps directly onto the classic response-time analysis, and kernel overheads are easy to characterize. The downside is that much of the surrounding functionality (networking, file systems, device drivers) comes from separate libraries, vendor SDKs or third parties, with uneven quality and maintenance. For safety-certified projects, WITTENSTEIN high integrity systems offers SAFERTOS, a functionally similar kernel developed under certified processes, as a commercial product.

Apache NuttX: POSIX on a microcontroller

NuttX aims to bring standards compliance (POSIX and ANSI C) to resource-constrained devices. It became an Apache Software Foundation top-level project in 2022 and is licensed under Apache-2.0. If your team knows Linux, NuttX feels familiar: pthreads, file descriptors, a virtual file system, BSD sockets and an interactive shell (NSH). It is configured with Kconfig.

From a real-time perspective, NuttX provides SCHED_FIFO and SCHED_RR, priority inheritance, and the POSIX SCHED_SPORADIC policy. Sporadic scheduling is a budget-based server that limits how much high-priority time a thread can consume per replenishment period, a conceptual cousin of the reservation servers discussed in our SCHED_DEADLINE article.

# NuttX defconfig fragment
CONFIG_SCHED_SPORADIC=y
CONFIG_PRIORITY_INHERITANCE=y
CONFIG_RR_INTERVAL=0
CONFIG_SMP=y
CONFIG_SMP_NCPUS=2

NuttX is best known as the operating system beneath the PX4 autopilot on Pixhawk-class flight controllers. Our article on flight-control timing looks at how such systems structure their rate loops. It is also used in consumer products and by several silicon vendors. There is no formal safety-certification program comparable to Zephyr’s or SAFERTOS’s.

RTEMS: space heritage and pluggable schedulers

RTEMS dates back to 1988, when it was developed for the U.S. Army Missile Command. It has since flown on many science and space missions and is widely used in the space sector. It offers two APIs, the Classic API and POSIX, and supports processors from small microcontrollers to multicore space-grade SoCs. New code is contributed under the BSD-2-Clause license as the project relicenses away from its historical GPL-with-linking-exception terms.

For scheduling researchers and timing-critical designs, RTEMS’s distinctive feature is its pluggable scheduler framework. At build time you can select deterministic priority scheduling, EDF, a Constant Bandwidth Server scheduler, or several SMP schedulers. On multicore parts, clustered scheduling lets you assign different schedulers to different groups of cores. RTEMS also implements multiprocessor locking protocols such as MrsP and OMIP:

/* RTEMS application configuration */
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
#define CONFIGURE_MAXIMUM_TASKS        16
#define CONFIGURE_SCHEDULER_EDF        /* uniprocessor EDF scheduler */
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_INIT
#include <rtems/confdefs.h>

ESA has funded work toward space-qualification data packages for RTEMS SMP, which makes it a natural candidate for ECSS-governed projects. The trade-offs: a smaller community than Zephyr or Linux, fewer off-the-shelf drivers for commercial hardware, and a single-address-space design with limited memory protection.

PREEMPT_RT Linux: real time with a full ecosystem

After almost two decades out of tree, the PREEMPT_RT patch set was merged into mainline in Linux 6.12 (November 2024). The final blocker was a reworked, non-blocking console and printk path. Enabling CONFIG_PREEMPT_RT makes most of the kernel preemptible. Spinlocks become sleeping, priority-inheriting locks, and interrupt handlers run as schedulable threads. Support was first enabled for x86, Arm64 and RISC-V, among other architectures.

Getting good latency

The kernel option alone is not enough. Predictable latency on Linux comes from configuration and hardware:

# Kernel config
CONFIG_PREEMPT_RT=y
CONFIG_NO_HZ_FULL=y
CONFIG_HZ_1000=y

# Kernel command line: isolate CPUs 2-3 for real-time work
isolcpus=managed_irq,domain,2-3 nohz_full=2-3 rcu_nocbs=2-3 irqaffinity=0-1

# Measure worst-case wake-up latency under load (rt-tests)
cyclictest --mlockall --smp --priority=95 --interval=200 --distance=0 --duration=12h

On well-behaved hardware, worst-case latencies in the tens of microseconds are commonly achieved. The figures depend heavily on the SoC, firmware (System Management Interrupts on x86 are a notorious source of jitter), power management and peripheral drivers. You should always measure on your own board under worst-case background load. Linux also offers SCHED_DEADLINE reservations for composing independent components.

Linux is the right answer when you need an MMU, process isolation, rich networking, containers, GPU or AI frameworks, or a large developer pool, and your deadlines are measured in hundreds of microseconds or more. It is usually the wrong answer for sub-10 µs control loops, very small memory budgets, or projects that need high-integrity certification of the OS itself. The Linux Foundation’s ELISA project is working on the evidence needed to use Linux in safety-related systems, but this remains an active area.

Making the decision

A few patterns recur across projects:

• Small MCU, single core, tight budget: FreeRTOS, or Zephyr if you need its connectivity stacks.
• Connected MCU product with long maintenance: Zephyr, for its LTS releases, security process and driver breadth.
• Linux-skilled team on an MCU, or a drone/robotics stack: NuttX.
• Space, science instruments, ECSS processes: RTEMS.
• Application processor, heavy software stack, deadlines ≥ ~100 µs: PREEMPT_RT Linux.
• Both hard control and rich software: a heterogeneous design, with an RTOS on a microcontroller core and Linux on application cores, or a hypervisor-based partitioning. This is the domain of mixed-criticality systems.

Finally, plan for portability. Keep timing-critical logic behind a thin OS abstraction layer and express timing needs as explicit parameters (periods, budgets, deadlines) rather than scattered priority numbers. This idea goes back to research such as the FRESCOR project, whose contract-based scheduling layer was designed to sit on top of different operating systems; see its original objectives. If you’d like an independent second opinion on a shortlist or a migration plan, our RTOS Selection & Migration Consulting service covers exactly that, and the glossary explains the terminology used above.

References and further reading

1. Zephyr Scheduling — Zephyr Project documentation
2. FreeRTOS kernel and documentation — FreeRTOS.org
3. Apache NuttX documentation — Apache Software Foundation
4. RTEMS documentation (Classic API Guide, scheduling concepts) — RTEMS Project
5. Real-Time Linux project — The Linux Foundation
6. Comparison of real-time operating systems — Wikipedia