RTOS or real-time Linux? Zephyr, FreeRTOS and PREEMPT_RT compared

A Real-Time Operating System (RTOS) is a deterministic software kernel that bounds Worst-Case Execution Time (WCET) and Interrupt Service Routine (ISR) latency independently of system load, which is the property that separates Zephyr RTOS, FreeRTOS and Linux with PREEMPT_RT from general-purpose schedulers. Choosing between Zephyr, FreeRTOS and Linux with PREEMPT_RT drives the cost, reliability and battery life of an embedded product. FreeRTOS fits in 6 to 15 KB with interrupt latency under 1 µs; Zephyr ships native BLE and is IEC 62443-4-2 certification-ready; Linux PREEMPT_RT targets 30 to 100 µs but demands 50 to 200 MB of Random Access Memory (RAM).

At AESTECHNO, an electronic design house based in Montpellier, we deploy Zephyr on BLE IoT sensors and ship Yocto Board Support Packages (BSP) patched with PREEMPT_RT on Jetson Orin NX. We design hardware and software, this dual capability lets us optimise the system end to end. For the fundamentals, see our guide to industrial embedded software.

Contents

• What is real-time in embedded?
• Zephyr RTOS: the modern choice for industrial IoT
• FreeRTOS: the established embedded standard
• Linux with PREEMPT_RT: when you need everything at once
• Comparison table: Zephyr vs FreeRTOS vs Linux RT
• Decision tree: which OS for your project?
• The hybrid approach: when one OS is not enough
• Summary

What is real-time in embedded?

Real-time in embedded computing is a system property that guarantees a response within a bounded, predictable delay regardless of system load.

Real-time determinism is measured through Worst-Case Execution Time (WCET) and Preemption Latency (PL). Per the IEC 61508 standard (functional safety), determinism is quantified through Safety Integrity Levels (SIL 1 through SIL 4). It is not a question of raw speed but of determinism: a system that responds on average in 1 µs but occasionally in 50 ms is not real-time. A system that always responds in under 100 µs, even worst-case, is. As noted by Linux Foundation real-time working groups, POSIX 1003.1b defines the priority-based preemptive scheduler that both Linux and Zephyr implement.

Hard real-time: a missed deadline is a system failure. Consequences can be catastrophic: airbags, engine control, life-supporting medical devices, braking systems. The worst case is the only metric that matters.

Soft real-time: a missed deadline degrades performance without causing critical failure. Examples: audio/video streaming, user interfaces, telemetry. Occasional glitches are tolerated, systematic degradation is not.

“Fast enough” (non real-time): the system must respond within a reasonable time, but with no strict guarantee. Most IoT sensors, gateways and monitoring systems fall into this category. A sensor pushing one reading every 10 seconds does not need an RTOS.

Latency vs determinism: a fast processor does not guarantee real-time. A 2 GHz Cortex-A under standard Linux can show latency spikes of several milliseconds because of garbage collection, memory paging, or a network driver. A 64 MHz Cortex-M under Zephyr can guarantee a response in under 10 µs, every time.

Jitter, the enemy of real-time: jitter measures the variation in response time between two executions. In motor control, 100 µs of jitter on a 10 kHz loop creates mechanical vibration. In audio, a few milliseconds of jitter produce audible cracks. In a real-time system, the worst case sizes the system, not the average.

Zephyr RTOS: the modern choice for industrial IoT

Zephyr RTOS is an open-source Real-Time Operating System (RTOS) governed by the Zephyr Project under the Linux Foundation.

Its modular kernel footprint ranges from 4 to 50 KB depending on configuration. Per the Zephyr Project documentation, the system supports over 500 boards natively, integrates Bluetooth Low Energy (BLE) 5.x, Thread, Matter and LoRaWAN stacks, and has emerged as the modern IoT platform. As Nordic Semiconductor notes in its nRF Connect SDK, Zephyr is the reference RTOS for the nRF52, nRF53 and nRF54 series. Typical targets include STM32F4 from Stmicroelectronics, nRF52/nRF53 from Nordic Semiconductor, ESP32 from Espressif, and the Renesas RA6M line.

Architecture and scheduling:

• Preemptive priority scheduler: critical tasks immediately interrupt lower-priority work
• Deterministic interrupt handling: bounded, measurable interrupt latency
• Tickless idle: the system timer does not generate unnecessary interrupts, maximum power savings
• Native power management: System OFF, suspend-to-RAM modes integrated in the framework

Ecosystem and connectivity:

• BLE 5.x integrated: full Bluetooth stack with GATT profiles, Bluetooth mesh
• Thread and Matter: next-generation home/IoT protocols, supported natively
• LoRaWAN: for long-range low-power networks
• Hardware support: Nordic nRF (nRF52, nRF53, nRF54), STM32, NXP, ESP32, Intel, and many others
• Build system: CMake + west + devicetree, structured and reproducible

Certification and security:

• Certification-ready for IEC 61508 (industrial functional safety), IEC 62443 (industrial cybersecurity) and ISO 26262 (automotive)
• MCUboot for secure boot and signed OTA updates
• TF-M (Trusted Firmware-M) for ARM TrustZone architectures

Limits to know:

• Steeper learning curve than FreeRTOS: the build system (west, devicetree, Kconfig) requires upfront investment
• Fast-evolving APIs: breaking changes between major versions require migration effort
• Growing community, but younger than FreeRTOS
• Limited support for 16-bit MCUs and very old architectures

Our experience at AESTECHNO: we have deployed Zephyr in production on low-power BLE IoT sensors with multi-year battery life targets. On a recent project we benchmarked the combination of tickless scheduler, integrated BLE stack and native power management, and it let us hit those targets without third-party software components. In our lab we measured a 1.6 µA sleep current on an nRF52840 Zephyr build with BLE connectable advertising at 1 s interval, validated with a Qoitech Otii Arc power analyser at 3.0 V. We have found that the k_timer Kernel Object (K-Object) with tickless idle saves about 40 % of the current draw compared with a periodic-tick scheduler at 100 Hz. Our electronic design house in Montpellier supports clients end to end: MCU selection, Zephyr port, firmware, and board design.

FreeRTOS: the established embedded standard

FreeRTOS is a real-time kernel maintained by Amazon since 2017 under an MIT licence, with a 6 to 15 KB ROM footprint and sub-microsecond ISR latency on Cortex-M4 at 80 MHz.

Per freertos.org and Amazon Web Services (AWS) documentation, FreeRTOS is the most-deployed RTOS in the world, with a mature ecosystem and a simplicity that makes it the natural entry point for most real-time embedded projects. As noted by Arm in its reference manuals, FreeRTOS works on every architecture with a deterministic context switch primitive, including all Cortex-M and Cortex-R cores. It offers a minimalist kernel, tasks, queues, semaphores and timers, that runs on practically any 32-bit microcontroller and even some 16-bit ones.

Architecture and footprint:

• Ultra-light kernel: 6 to 15 KB of ROM depending on configuration, less than 1 KB of RAM per task
• Interrupt latency under 1 µs on a Cortex-M4 clocked at 80 MHz (e.g. STM32L4, nRF52)
• Preemptive or cooperative scheduler: configurable to needs
• Extreme portability: more than 40 architectures supported (Cortex-M, RISC-V, AVR, PIC, Xtensa…)
• Stable API: code written 10 years ago still compiles today

AWS ecosystem and extensions:

• FreeRTOS+TCP: integrated TCP/IP stack for network connectivity
• coreMQTT, coreHTTP: certified libraries for cloud communication
• AWS IoT Device SDK: direct integration with AWS services (IoT Core, Greengrass, Device Shadow)
• FreeRTOS+CLI: command-line interface for debugging
• SafeRTOS: IEC 61508 SIL 3-certified version, developed by WITTENSTEIN

Limits to know:

• No integrated BLE stack: you have to use third-party stacks (NimBLE, vendor SDK) or the silicon vendor’s proprietary stack
• No Thread or Matter: modern IoT protocols are not natively supported
• No devicetree: hardware configuration is manual, often tied to the vendor HAL (STM32 HAL, nRF SDK…)
• Fragmented ecosystem: each vendor provides its own hardware abstraction layer, making cross-platform porting expensive
• Limited networking features: FreeRTOS+TCP is functional but less complete than a Linux stack

When to choose FreeRTOS: for a simple, well-defined real-time control loop on a heavily resource-constrained MCU. For a project targeting the AWS IoT ecosystem. For a product where API stability and community maturity outweigh advanced networking features.

When to avoid FreeRTOS: for a multi-protocol IoT product (BLE + Thread + Matter), for a project requiring structured OTA updates, or when development productivity on modern communication stacks matters.

Linux with PREEMPT_RT: when you need everything at once

Linux with PREEMPT_RT is a fully-preemptible variant of the mainline kernel, merged into kernel.org 6.12 in October 2024 per Linus Torvalds.

PREEMPT_RT turns a general-purpose operating system into a soft real-time system with typical Preemption Latency (PL) of 30 to 100 µs on Cortex-A64 targets clocked above 1 GHz. The standard Linux kernel is not real-time: its Completely Fair Scheduler is built for fair CPU time distribution, not for meeting strict deadlines, and interrupts, memory paging, kernel locks and drivers can introduce unpredictable latencies of several milliseconds. As noted by Canonical in its Ubuntu Pro Real-Time documentation, PREEMPT_RT now ships as a supported option on long-term-support kernels. Common targets include Raspberry Pi 5 (Cortex-A76 at 2.4 GHz), BeagleBone AI-64, NXP i.MX8, and NVIDIA Jetson Orin. Realistic minimum Random Access Memory (RAM) for an industrial RT Linux sits between 50 and 200 MB.

PREEMPT_RT, real-time in the kernel:

• Makes the Linux kernel fully preemptible: critical kernel sections can be interrupted by priority tasks
• Converts spinlocks into mutexes with priority inheritance
• Hardware interrupts become schedulable threads with configurable priorities
• Merged into the mainline kernel since version 6.12: no more out-of-tree patch
• Typical latencies: 20 to 100 µs on Cortex-A, measurable with cyclictest

PREEMPT_RT vs Xenomai: how to decide? PREEMPT_RT (mainline) is the standard route when your latency target is above ~30 µs worst case, maintenance is zero since it follows the official kernel. Xenomai or RTAI are needed for hard real-time below 10 µs (high-frequency motor control, CNC), but via a dual-kernel architecture: a real-time micro-kernel (co-kernel) runs in parallel with Linux, with its own APIs (POSIX skin, Alchemy) and the maintenance burden of an out-of-tree patch. For 90% of the industrial projects we see, PREEMPT_RT is enough and avoids the maintenance debt.

Linux ecosystem advantages:

• Full network stack: TCP/IP, Wi-Fi, Ethernet, VPN, firewall
• Advanced filesystems: ext4, btrfs, SquashFS, overlayFS
• Graphical interface: Qt, GTK, embedded web frameworks
• Software ecosystem: Python, Docker, databases, AI frameworks, OpenCV
• Drivers: the largest hardware driver base in the world
• OTA updates: swupdate, RAUC, Mender, mature industrial solutions
• Yocto integration: build a custom RT Linux with meta-rt and the right BSP layers

Limits:

• Footprint: 32 MB of RAM minimum, 128 MB+ of storage, incompatible with MCUs
• Boot time: several seconds (optimisable but never as fast as an RTOS)
• Power draw: a Cortex-A under Linux draws orders of magnitude more than a Cortex-M under Zephyr
• RT tuning complexity: isolating CPU cores (isolcpus), configuring interrupt priorities, disabling latency sources (SMI, frequency scaling) requires specific expertise
• Hard certification: kernel size makes IEC 61508 or DO-178C certification extremely costly

Our experience at AESTECHNO: we develop custom Linux Board Support Packages (BSP) on NVIDIA Jetson platforms for real-time video processing and industrial vision applications. On a recent project we benchmarked a Jetson Orin NX Yocto image patched with PREEMPT_RT and a Memory Management Unit (MMU) CPU isolation via isolcpus: in our lab we measured a worst-case scheduler jitter of 140 µs across 3.6 million cyclictest samples. We profiled the idle loop on a recent client project and found that disabling CPU frequency scaling (cpufreq governor set to performance) halved the 99.99th percentile jitter from 310 µs down to 150 µs. We integrate PREEMPT_RT into our Yocto images when the project requires both real-time performance and the full Linux ecosystem (network, AI, GUI). Our design house sizes hardware and software together to guarantee that latency targets are met in production.

Comparison table: Zephyr vs FreeRTOS vs Linux RT

Zephyr, FreeRTOS and Linux PREEMPT_RT are three distinct real-time stacks for embedded systems. They differ by an order of magnitude on memory footprint and by two orders of magnitude on worst-case latency, so the right pick is the one whose envelope matches your hardware and deadlines. The table below summarises the key characteristics of the three platforms with representative orders of magnitude for typical industrial configurations.

Criterion	Zephyr RTOS	FreeRTOS	Linux (PREEMPT_RT)
Minimum RAM	8 KB	4 KB	32 MB+
Minimum Flash / storage	64 KB	16 KB	128 MB+
Real-time class	Hard	Hard	Soft (PREEMPT_RT) / Hard (Xenomai)
Worst-case latency	<10 µs	<10 µs	<100 µs (PREEMPT_RT)
BLE stack	Integrated	No (third-party)	BlueZ (not real-time)
Thread / Matter	Integrated	No	OpenThread (separate)
Wi-Fi	Partial	FreeRTOS+TCP	Full
Filesystem	LittleFS, FAT	FreeRTOS+FAT	Full (ext4, btrfs…)
OTA / DFU	MCUboot	AWS OTA	swupdate, RAUC, Mender
Power management	Native (tickless idle)	Manual	Complex (suspend/hibernate)
Graphical interface	LVGL	LVGL	Full (Qt, GTK, web)
Ecosystem size	Fast-growing	Largest RTOS	Largest overall
Certification	IEC 61508, ISO 26262	IEC 61508 (SafeRTOS)	Difficult
Learning curve	Medium-high	Low	Low (Linux) / High (RT tuning)
Target MCU / MPU	Cortex-M, nRF, ESP32	Any Cortex-M	Cortex-A, x86

Decision tree: which OS for your project?

The RTOS decision tree is a structured selection framework that maps processor type, latency, protocol stack, power budget and regulatory context to a single recommended operating system. Choosing between Zephyr, FreeRTOS and Linux RT depends on several intersecting criteria: processor type, latency requirements, communication protocols, power constraints, and regulatory context. Here is a decision framework that covers most of the cases we see in industrial settings.

Choose Zephyr RTOS when:

• You are building an IoT product with BLE, Thread or Matter
• You target a Nordic MCU (nRF52, nRF53, nRF54), NXP, STM32 or ESP32
• You need secure OTA updates (MCUboot)
• Battery life is a critical concern (tickless idle, System OFF)
• You are aiming for IEC 61508 or ISO 26262 certification
• You want a modern, structured ecosystem with a fast-growing community

Choose FreeRTOS when:

• You have a simple, well-defined real-time control loop
• The MCU is heavily resource-constrained (a few KB of RAM)
• You target the AWS IoT ecosystem (MQTT, Device Shadow, Greengrass)
• API stability and community maturity are top priorities
• The project is relatively simple, with no advanced network stack

Choose Linux with PREEMPT_RT when:

• The system combines real-time with rich application features (network, GUI, AI, filesystem)
• You target a Cortex-A or x86 MPU (Jetson, i.MX8, Raspberry Pi)
• The product integrates industrial vision, robotics or a complex HMI
• You need Docker, Python, or rich software frameworks
• Required latency is on the order of 100 µs (soft real-time)

Simple rule: MCU (Cortex-M, no MMU) → Zephyr. MPU (Cortex-A, with MMU) → Linux. FreeRTOS for extreme simplicity or native AWS IoT integration.

The hybrid approach: when one OS is not enough

The hybrid approach is an asymmetric multiprocessing (AMP) architecture that runs Linux and an RTOS on separate CPU cores of the same silicon die. Each workload lives on the core whose scheduler matches its timing class. The application processor (Cortex-A) runs Linux for complex tasks, while a real-time core (Cortex-M) runs Zephyr or FreeRTOS for the critical control loops. Per Arm and the Linaro OpenAMP project, this architecture combines general-purpose and deterministic execution with no protocol-level compromise.

Supported architectures:

• NXP i.MX8: Cortex-A53 cores (Linux) + Cortex-M4/M7 (RTOS)
• STM32MP1: Cortex-A7 (Linux) + Cortex-M4 (RTOS)
• Multi-board systems: a Linux SBC + a dedicated MCU connected via SPI, UART or USB

Inter-processor communication:

• RPMsg: virtio-based messaging protocol, the standard for A-core / M-core communication
• OpenAMP: open-source framework for asymmetric multiprocessing
• Shared memory: RAM regions accessible by both cores, with mailbox synchronisation

Typical use cases:

• Robotics: Linux handles navigation, vision and HMI; the RTOS controls motors in real time
• Medical instruments: Linux drives the user interface; the RTOS pilots the critical sensors and actuators
• Industrial systems: Linux talks to the cloud and the network; the RTOS runs the control loop

Our experience at AESTECHNO: we design systems where Linux (on Jetson or i.MX) coexists with an MCU running Zephyr inside the same product. In our practice over eight hybrid projects, we profiled RPMsg latency between a Cortex-A53 Linux core and a Cortex-M4 Zephyr core at 28 µs one-way on i.MX8MM, measured with a 16 MHz GPIO toggle. Our design house handles both halves, the electronic board, the Linux BSP and the RTOS firmware, with a coherent system view. This integrated approach avoids the late integration problems between subsystems developed separately.

Recent field feedback. In Q1 2026, we delivered a Jetson Orin NX project with a custom Yocto BSP patched with PREEMPT_RT: soft real-time Linux on an embedded AI platform, with worst-case under 150 µs. In parallel, our DDR + FPGA architectures let us validate very low-jitter control loops, the FPGA handles hard real-time, the application processor the supervision. On Bluetooth 5.4 PAwR, we synchronised devices below 5 µs, illustrating what embedded real-time enables today.

Summary: which OS to choose by constraint

The RTOS summary is a three-axis decision that comes down to memory footprint, worst-case latency, and software ecosystem.

FreeRTOS (6-15 KB, latency <1 µs) remains unbeatable for a simple control loop on an ultra-constrained MCU, perfect for a multi-year battery sensor. Zephyr (4-50 KB kernel, native BLE/Thread/Matter, IEC 62443-4-2 certification) is the modern IoT choice, unlike FreeRTOS which integrates no radio stack. Linux PREEMPT_RT (50-200 MB RAM, latency 30-100 µs) is required when you must combine real-time, vision, AI and advanced connectivity on Cortex-A.

At AESTECHNO, we frame this choice upstream of the schematic rather than downstream of the firmware: an MCU picked before measuring the BLE stack size or the AI inference budget often becomes a PCB respin a quarter later. The hybrid approach (Cortex-A under Linux + Cortex-M under Zephyr on i.MX8 or STM32MP1) is often the most pragmatic industrial answer when no single OS covers all the needs.

FAQ: Zephyr, FreeRTOS and real-time Linux

Zephyr or FreeRTOS: which one to choose?
If you are building a modern IoT product with BLE, Thread or Matter, Zephyr is the natural choice: those stacks are integrated natively. FreeRTOS still makes sense for simple control loops on heavily constrained MCUs or when you target the AWS IoT ecosystem. Both are open source and offer hard real-time.

Is Linux a real-time system?
Standard Linux is not real-time: its scheduler favours fairness over strict deadlines. With the PREEMPT_RT patch (merged into the mainline kernel since version 6.12), Linux becomes a soft real-time system with latencies under 100 µs. For hard real-time on Linux, you need Xenomai or RTAI (dual-kernel approach).

What is PREEMPT_RT?
PREEMPT_RT is a set of modifications to the Linux kernel that make it fully preemptible. Spinlocks are converted into mutexes with priority inheritance, and hardware interrupts become schedulable threads. Result: critical tasks can interrupt any kernel section, drastically reducing worst-case latencies.

Can you combine Linux and an RTOS in the same product?
Yes, that is the AMP (Asymmetric Multiprocessing) hybrid approach. Many modern SoCs integrate Cortex-A cores (for Linux) and Cortex-M cores (for an RTOS) on the same chip. The cores communicate via RPMsg or shared memory. It is common in robotics, industrial vision and medical systems.

Which RTOS for a BLE product?
Zephyr is the best fit: it integrates a complete BLE 5.x stack, supporting GATT profiles, Bluetooth mesh, and Thread/Matter protocols. FreeRTOS has no native BLE stack, you have to use the radio chip vendor’s proprietary SDK, which reduces portability and complicates maintenance.

Can AESTECHNO develop on Zephyr and Linux?
Yes. We deploy Zephyr in production on low-power BLE IoT sensors and develop custom Linux BSPs with Yocto on NXP and NVIDIA Jetson platforms. Our design house handles hardware and software together, which lets us optimise the system as a whole, from processor selection to firmware, including embedded security.

What is the difference between Zephyr and a minimal embedded Linux?
Zephyr is an RTOS for microcontrollers (Cortex-M): it offers hard real-time, a footprint of a few KB, and runs without an MMU or an advanced filesystem. Linux, even minimal (via Yocto or Alpine), needs a processor with an MMU (Cortex-A or x86), at least 32 MB of RAM, and provides a full application ecosystem. They are complementary tools, not competitors.

Related articles

• Embedded Linux distributions: systemd, Alpine, Yocto, guide for decision-makers
• Industrial embedded software: complete guide
• AESTECHNO electronic design house
• FPGA board design
• NVIDIA Jetson processors
• Embedded AI with NVIDIA Jetson
• Bluetooth and BLE for embedded
• Embedded systems cybersecurity