IllustrationAn RTOS, or real-time operating system, is a small kernel that splits microcontroller firmware into tasks with priorities and switches between them, so urgent work such as a radio or sensor interrupt is handled within a known time. FreeRTOS and Zephyr are two open source examples used in connected devices.
Most connected devices run on a microcontroller, and an early firmware decision is what runs on it: a plain loop, a real-time operating system or embedded Linux. The choice shapes battery life, updates and security patching. This guide explains what an RTOS does, compares FreeRTOS and Zephyr using their own documentation, and gives a decision table and a question list for your hardware team.
This is an engineering summary. Version numbers and support dates change, so check the linked pages before you decide. All sources were read on November 6, 2026.
What is an RTOS, and what does it do in a device?
An RTOS is an operating system kernel sized for microcontrollers and small processors. Its main job is scheduling. You split the firmware into tasks (Zephyr calls them threads), give each one a priority, and the kernel decides which one runs at each moment. The kernel also gives tasks safe ways to share data and wait for each other: queues, semaphores, mutexes and timers.
The Zephyr introduction lists the kernel services a typical RTOS offers: multi-threading, interrupt handling, memory allocation, inter-thread synchronization, data passing and power management (Zephyr introduction, as of November 2026).
"Real-time" means predictable timing. A fast system can still miss a deadline. In a real-time system, a correct answer that arrives too late counts as a failure. In a device, that might be an audio buffer that must be emptied before the next block arrives, a sensor that must be read at a fixed rate, or a haptic motor that must stop on time. An RTOS helps you meet those deadlines because the most urgent ready task always gets the CPU.
An RTOS is built into one firmware image together with your application. For how that image fits next to the app and the cloud, see firmware vs software vs hardware. For the processor, memory, interfaces and power supply that firmware runs on, see what an embedded system is.
How does an RTOS scheduler decide what runs next?
Priorities and preemption
Espressif describes the upstream FreeRTOS scheduler as fixed priority preemptive with time slicing. The scheduler can preempt the running task when a higher-priority task becomes ready, and the kernel needs a periodic tick interrupt (ESP-IDF FreeRTOS, as of November 2026).
The Zephyr scheduler picks the highest-priority ready thread. When several ready threads share a priority, it picks the one that has waited longest. A cooperative thread keeps the CPU until it does something that makes it unready, such as sleeping. A preemptible thread can be replaced as soon as a higher-priority thread is ready. Time slices are measured in system clock ticks, and slicing makes sure no thread runs longer than one slice without yielding to equal-priority threads (Zephyr scheduling, as of November 2026).
Interrupts and determinism
Interrupt handlers run ahead of all task code. Zephyr says an interrupt can replace the current thread at any time unless interrupts are masked (Zephyr scheduling, as of November 2026). The usual design keeps each handler short: it records the event and wakes a task, and the task does the work.
Determinism means the worst-case time from an event to the response is known and bounded. The average does not tell you much. A long critical section or a lock held by a low-priority task can stretch the worst case. Measure it on your own board: toggle a pin in the interrupt and another in the task, and record the gap with a logic analyzer over a long run.
Hard and soft deadlines
A hard deadline is one where a single miss is a failure. A soft deadline is one where a miss lowers quality, such as a dropped audio frame. List each deadline, mark it hard or soft, and size priorities from that list.
RTOS vs Linux vs bare metal: which fits your device?
The three options sit on a scale from least to most software. The table compares them for a battery-powered device. The rows are engineering reasoning, and none describes a specific project.
| Option | How it runs | Where it fits | Watch out for |
|---|---|---|---|
| Bare metal | One main loop plus interrupt handlers. No scheduler and no tasks. | Single-purpose parts: a simple sensor node, a remote, a bootloader. | Every new feature adds to the loop, and timing gets harder to reason about as it grows. The chip SDK may already assume an RTOS (see the chip SDK section below). |
| RTOS | Tasks with priorities on a microcontroller. A small kernel switches between them and handles interrupts. | Battery products with a radio: Bluetooth LE wearables, trackers, voice capture with a wake word. | Each task needs its own stack, so RAM fills up fast. Priorities need a design, or a low-priority task holding a lock can stall a high-priority one. |
| Embedded Linux | A full kernel with processes, file systems and a large driver base, on an application processor with external RAM. | Camera devices, on-device models too big for a microcontroller, products that reuse Linux software. | Higher idle power, longer boot, larger update images and a whole distribution to patch. Timing depends on kernel configuration. |
Linux can be made more real-time. The kernel documentation says PREEMPT_RT transforms Linux into a real-time kernel. It shrinks the sections of code where interrupts or preemption are disabled, and it reduces the delay between a high-priority task becoming runnable and actually running. A few critical code paths stay non-preemptible (kernel.org PREEMPT_RT theory, as of November 2026). That helps timing, but the board still has an application processor and its idle power.
Some products use both: a Linux processor for heavy work and a small microcontroller running an RTOS for the always-on parts. For published sleep currents and the battery math behind this choice, see MCU or Linux SoC for an AI wearable. If you plan to run a small model on the microcontroller itself, TinyML on microcontrollers is the next read.
FreeRTOS vs Zephyr: how do they differ?
FreeRTOS and Zephyr are both open source kernels for microcontrollers. They differ more in scope and governance than in how they schedule tasks. Sourced cells link to the page they came from, as of November 2026. The FreeRTOS hardware row is engineering reasoning.
| Topic | FreeRTOS | Zephyr |
|---|---|---|
| License | Released under the MIT open source license. AWS says this means you can use it in commercial and personal projects (FreeRTOS user guide). | Apache 2.0. The Zephyr introduction notes that some imported or reused components use other licenses, documented separately (Zephyr introduction). |
| Who runs it | The FreeRTOS user guide is published by AWS, and its source is on the FreeRTOS GitHub organization (FreeRTOS user guide). | A Linux Foundation hosted Collaboration Project with neutral governance (Zephyr project page). |
| What you get | A kernel plus libraries for connectivity, security and over-the-air updates. The kernel repository holds kernel files and ports only, with chip and compiler specific code in its portable directory (FreeRTOS-Kernel). | A kernel plus a networking stack with BSD sockets and LwM2M, Bluetooth 5.0 support with GATT and Bluetooth Mesh, and file systems including LittleFS and FatFS (Zephyr introduction). |
| How hardware is described | Board support and drivers sit outside the kernel repository, so they usually come from the chip vendor SDK or your own code. | Devicetree describes the hardware, and the build uses it to create the application image (Zephyr introduction). |
| Scheduling | Espressif describes the upstream scheduler as fixed priority preemptive with time slicing, driven by a periodic tick interrupt (ESP-IDF FreeRTOS). | Cooperative and preemptive threads, an optional earliest-deadline-first rule, meta IRQs and time slicing (Zephyr introduction). |
| Long-term support | LTS releases get security updates and critical bug fixes for two years. Release 202604-LTS, with kernel 11.3.0, has an end date of April 30, 2028. AWS offers an optional Extended Maintenance Plan for up to 10 more years (FreeRTOS-LTS). | LTS releases come every 2.5 to 3 years and are maintained for about 5 years: general and security fixes for the first 2 years, then security and stability fixes only (Zephyr release process). |
| Vulnerability handling | Not described in the pages cited here. | Vulnerabilities are managed in GitHub security advisories, and the project runs a CNA with a PSIRT team (security overview, project page). |
FreeRTOS gives you a small kernel and lets the chip vendor or your team supply the rest. Zephyr gives you more in one tree: drivers, devicetree, networking and Bluetooth. That is more to learn at the start and less to assemble yourself.
The chip SDK usually decides
In practice the chip you pick often makes the choice for you. Espressif integrates FreeRTOS into ESP-IDF as a component, and says all ESP-IDF applications and many of its components are written based on FreeRTOS. Its default kernel, ESP-IDF FreeRTOS, is based on upstream FreeRTOS v10.5.1 and modified for SMP on up to two cores (ESP-IDF FreeRTOS overview, ESP32-S3 stable docs, as of November 2026). The FreeRTOS 202604-LTS release ships kernel 11.3.0 (FreeRTOS-LTS, as of November 2026).
So the kernel in your build can be a vendor version on a different base than the current upstream release. Ask who ships kernel fixes for your build: the vendor, upstream, or your own team. With a vendor fork, an upstream fix must be ported into the SDK before you can ship it. Other chip families may build on Zephyr or on their own kernel, so read the SDK documentation for the exact chip you plan to use before you compare kernels in the abstract.
What does the RTOS choice mean for OTA updates and security fixes?
A device can stay in the field for years. The RTOS release you start on needs a support plan that covers that time.
- FreeRTOS LTS releases get security updates and critical bug fixes for two years, and 202604-LTS has an end date of April 30, 2028. AWS lists an optional Extended Maintenance Plan for up to 10 more years (FreeRTOS-LTS, as of November 2026).
- Zephyr ships a regular release roughly every six months. Each LTS release is maintained for about five years, and support for one LTS ends when the LTS two versions later is first released (Zephyr release process, as of November 2026).
- FreeRTOS includes libraries for over-the-air updates (FreeRTOS user guide, as of November 2026). Zephyr lists the ability to update the operating system and security subsystems of fielded devices as part of device management (Zephyr security overview, as of November 2026).
Three habits keep this manageable. Start on an LTS line. Record the kernel version, the vendor SDK version and each component license in the SBOM. And make sure the OTA image can replace the kernel and the radio stack, because security fixes can land in any of the three. For how updates fail in the field and how bootloaders recover, see firmware OTA failures that brick devices.
What should you ask your hardware team?
Bring this list to the platform review, before the firmware architecture is fixed.
- Which chip is planned, and which RTOS does its vendor SDK assume?
- Which kernel version is in our build, and is it the upstream release or a vendor fork?
- Which LTS line are we on, and when does its support end compared with our product life?
- Who watches security advisories for the kernel, the network stack and the Bluetooth stack, and how fast do fixes reach devices?
- Which tasks have hard deadlines, and what is the measured worst-case response for each one?
- How much RAM do the task stacks take, and how much headroom is left?
- Is the RTOS version and every component license listed in the SBOM we receive?
- Can the OTA path update the kernel and the radio stack, or only our application code?
For how the firmware work is organized and what you receive at handover, see firmware development.
Questions about RTOS choice
Is FreeRTOS free to use in a commercial product?
FreeRTOS is released under the MIT open source license, and the AWS user guide says you can use it in commercial and personal projects (FreeRTOS user guide, as of November 2026). Check the license of every other library your SDK adds. This is an engineering summary and not legal advice.
Is Zephyr better than FreeRTOS?
Neither wins in general. FreeRTOS is a small kernel that you combine with the chip vendor SDK. Zephyr bundles drivers, devicetree, networking and Bluetooth in one project, which is more to learn and more already done. In practice the chip you pick and its SDK usually decide.
Can Linux be a real-time operating system?
The Linux kernel documentation says PREEMPT_RT turns Linux into a real-time kernel and reduces the delay between a high-priority task becoming runnable and running, while a few critical code paths stay non-preemptible (kernel.org, as of November 2026). It still runs on an application processor, so idle power and boot time stay those of a Linux system.
How can Duobay help choose and build the firmware platform?
Duobay develops custom devices with a Shenzhen engineering team that covers electronics, firmware, enclosure, app and test, and builds samples and small batches. Firmware source and the SBOM are delivered to you, and source files are assigned to you at every paid gate. Initial calls are free, and we do not publish prices. Tell us about your device.
If you want help choosing between bare metal, an RTOS and Linux for a specific device, tell us about your device.
Sources. All pages accessed November 6, 2026. Releases and support dates change, so confirm current values before you decide.
- AWS, FreeRTOS User Guide, What is FreeRTOS? (link)
- FreeRTOS, FreeRTOS-LTS repository, 202604-LTS (link)
- FreeRTOS, FreeRTOS-Kernel repository (link)
- Espressif, ESP-IDF FreeRTOS overview, ESP32-S3 stable (link)
- Espressif, ESP-IDF FreeRTOS (IDF), ESP32-S3 stable (link)
- Zephyr Project, Introduction (link)
- Zephyr Project, Scheduling (link)
- Zephyr Project, Release Process (link)
- Zephyr Project, Zephyr Security Overview (link)
- Zephyr Project, Learn About (link)
- The Linux Kernel documentation, PREEMPT_RT theory of operation (link)
Planning a device like this? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →