Zephyr RTOS vs FreeRTOS: A Comprehensive Comparison for IoT and Embedded Systems

Modern embedded and IoT devices often need an efficient Real-Time Operating System (RTOS) to juggle multiple tasks reliably. Ezurio’s System on Modules and Bluetooth Embedded Modules feature embedded RTOS support, and that includes Zephyr RTOS and FreeRTOS. Zephyr RTOS and FreeRTOS are two of the most popular open-source RTOS options available today, each with its own strengths and ideal use cases. In this in-depth comparison, we’ll explore Zephyr RTOS vs FreeRTOS from multiple angles – architecture, features, performance, community support, and real-world use cases – to help you determine which is better suited for your project. We’ll also consider real-world benchmarks, industry adoption in areas like wearables, medical devices, and industrial automation, and key factors to guide your decision. Let’s dive in to see how these two RTOS heavyweights stack up against each other.

What Are FreeRTOS and Zephyr RTOS?

Before we pit them head-to-head, it’s important to understand the background of each RTOS.

FreeRTOS at a Glance

FreeRTOS is one of the most widely adopted RTOS kernels in the embedded world. First released in 2003 by Real Time Engineers Ltd., it’s now maintained by Amazon Web Services (AWS). FreeRTOS is known for its simplicity and small footprint, essentially providing just the core scheduling and synchronization primitives needed for real-time task management. It’s often described as a “bare-bones” or lightweight RTOS – in fact, some developers quip that FreeRTOS is basically an extensible scheduler rather than a full OS. The kernel is MIT-licensed (permissive for commercial use) and is free to integrate into products.

Key characteristics of FreeRTOS include:

• Minimalist Design: The focus is on providing essential RTOS features (task scheduling, inter-task communication like queues/semaphores, etc.) with very low overhead. It leaves higher-level functions to the developer or third-party libraries.
• Small Footprint: A basic FreeRTOS kernel can run in as little as a few KB of memory (roughly ~5–10 KB ROM for a minimal build). This makes it ideal for resource-constrained microcontrollers.
• Extensive MCU Support: FreeRTOS supports a wide range of microcontroller architectures (over 40 architectures officially). It’s commonly used on ARM Cortex-M, AVR, PIC, and many other platforms. Many semiconductor vendors provide FreeRTOS ports with their SDKs – e.g., STMicroelectronics, Microchip, and Espressif (ESP32) are notable users.
• AWS Integration: Under Amazon’s stewardship, FreeRTOS has integrated libraries for cloud connectivity (AWS IoT Core) and security. The official distribution (sometimes called Amazon FreeRTOS) comes with MQTT, TLS, and over-the-air update libraries for easy AWS cloud integration. If your IoT application plans to use AWS services heavily, this tight integration is a big plus.
• Community and Documentation: Given its long history, FreeRTOS has a massive user base and extensive documentation, tutorials, and examples. There are countless forum posts, books, and articles addressing common patterns. This large community means finding help for FreeRTOS is usually easy.
• Safety Certification Options: For safety-critical industries, a subset of FreeRTOS is available as SafeRTOS (commercially) or an upcoming community-driven safety-certifiable edition, aiming to meet standards like IEC 61508 or ISO 26262.

Overall, FreeRTOS excels in simple applications that need a lightweight scheduler with minimal overhead. It “gets out of the way” of the developer – you add only what you need on top of it.

Zephyr RTOS at a Glance

Zephyr is a newer entrant, launched in 2016 as a Linux Foundation project. It is a fully-featured, scalable RTOS designed for small embedded devices to complex IoT systems. Unlike FreeRTOS’s minimalist approach, Zephyr comes with a rich set of built-in components and a modular, highly configurable design. It’s licensed under Apache 2.0 (also permissive for commercial use) and has a broad industry backing by firms like Intel, NXP, Nordic Semiconductor, Google, and others contributing to its development.

Key characteristics of Zephyr include:

• Comprehensive Feature Set: Zephyr is often likened to a slimmed-down Linux for micros. It provides not just a kernel but device drivers, networking stacks, file systems, power management, and more out-of-the-box. This means you have a one-stop solution for many common IoT functionalities.
• Hardware Support and Portability: Zephyr supports multiple CPU architectures (ARM Cortex-M, ARM Cortex-A, RISC-V, ARC, x86, Tensilica Xtensa, and more) and over 600 boards with official board definitions. Adding support for a new board is facilitated by using Linux-like Devicetree descriptions and a consistent driver model, making it easier to scale projects across different hardware. This broad hardware support and neutrality (governed by Linux Foundation) appeals to those avoiding lock-in.
• Modern Architecture: The kernel of Zephyr is robust and supports multiple scheduling algorithms, including both preemptive and cooperative multitasking. It even has experimental SMP (symmetric multiprocessing) support for multi-core microcontrollers, which vanilla FreeRTOS lacks in mainline. Zephyr emphasizes memory safety and reliability – features like memory protection (MPU/MMU support) to isolate threads, stack overflow protection, and fault handling are built in. In essence, it’s designed with a focus on security and stability for complex applications.
• Rich Subsystems and Libraries: Zephyr comes with a wide array of subsystems built-in. This includes networking (IPv4/IPv6 stack with TCP/UDP, 6LoWPAN, etc.), wireless protocols (Wi-Fi, Bluetooth LE, Thread, LoRaWAN), file systems (LittleFS, FAT), USB support, sensor drivers, display and GUI (supports libraries like LVGL), shell and logging systems, and even firmware update support (like MCUboot for bootloading). These ready-made components can drastically cut development time for IoT devices that need such features.
• Highly Configurable & Modular: Zephyr uses a Kconfig-based build configuration and allows you to include or exclude components to optimize footprint. Practically, this means if you need a tiny system, you can strip Zephyr down to just the kernel and minimal drivers; if you need more, you enable the relevant modules. Zephyr can run on devices with as little as 8 KB of RAM (in minimalist configs), and some documentation even claims a ~2 KB minimum kernel image for the simplest case. The build system (CMake with a west meta-tool) automates pulling in only what’s required. In short, Zephyr’s motto could be “pay for what you use” – it can be small, but it can scale up.
• Development Ecosystem: Because of its Linux Foundation roots, Zephyr feels a bit like “embedded Linux” in style. Development involves dealing with Kconfig options and Devicetree files to configure the system, which is powerful but has a steeper learning curve. Many have noted that “Zephyr is 80% configuration and 20% coding” – getting started requires understanding its build and config system. In contrast, FreeRTOS feels closer to bare metal coding – you include the kernel and write your application using vendor HAL libraries, with much less upfront configuration structure. Debugging and tracing in Zephyr can also be more complex out-of-the-box due to abstraction layers, whereas FreeRTOS simplicity means “what you wrote is what’s running,” easing debug. Newcomers might find FreeRTOS easier to start, whereas Zephyr rewards you later with its rich features once you overcome the learning curve.
• Community and Governance: Zephyr is a true open-source collaborative project. It is governed by the Linux Foundation with a technical steering committee of major industry players ensuring vendor-neutral development. The community is vibrant and growing, with contributions from hundreds of developers globally. Extensive documentation, sample projects, and even formal training programs (e.g., Nordic’s Zephyr-based DevAcademy) are available. This strong community and neutral governance give Zephyr a long-term sustainability and appeal, especially to companies who want an RTOS not under the control of a single corporate entity.

In summary, Zephyr aims to be a scalable, one-stop RTOS solution with a rich feature set and strong security focus, suitable for everything from a simple sensor node to a complex IoT hub. It trades a steeper learning curve and slightly higher baseline overhead for a much broader range of capabilities out-of-the-box.

 

Architecture and Design Philosophy

When comparing Zephyr RTOS vs FreeRTOS, one core difference lies in their design philosophy:

 

• FreeRTOS takes a minimalist kernel-only approach. It provides a scheduler (supporting preemptive multitasking with priority-based scheduling, or cooperative if configured), basic synchronization primitives (mutexes, semaphores, queues), and not much else. There is no native device driver framework or I/O subsystem – you directly use whatever drivers or HAL (Hardware Abstraction Layer) the MCU vendor provides or write your own. All tasks by default run in a single memory space (no memory protection or user/kernel mode separation in the base FreeRTOS), which keeps it simple and fast. This lean design makes FreeRTOS easier to learn and optimize for very constrained devices. Developers often describe FreeRTOS as “just add water”: a quick way to get basic real-time scheduling into a bare-metal application, without imposing a large structure.
• Zephyr takes a more integrated OS approach. It not only has a scheduler (which supports preemptive and cooperative threads, and even allows mixing them), but also defines a standardized driver model, system services, and abstractions for peripherals. Hardware Abstraction is a strong focus – Zephyr uses Devicetree descriptions for hardware, and drivers are written to use those, meaning an application can often switch hardware with minimal code changes beyond updating Devicetree bindings. Zephyr also supports running threads in user mode (on supported MCUs) with an MPU, meaning tasks can be isolated from each other and from the kernel. This adds safety (one errant task can’t corrupt others easily) but at the cost of slightly higher memory overhead per task (for stacks/guards, memory partitions, etc.) – unlike FreeRTOS where all tasks share the same memory space, Zephyr can enforce memory boundaries, meaning more reserved memory per task for isolation and protection (stack guards, MPU regions). Zephyr’s design is modular; you enable subsystems as needed. This modularity, along with its extensive use of compile-time configuration, means the “OS” is tailored per application, which is powerful but means there’s a lot of configuration knobs. Essentially, Zephyr’s architecture is closer to that of a tiny Linux or a traditional commercial RTOS (like ThreadX or VxWorks) with a focus on scalability, safety, and feature richness, whereas FreeRTOS is more akin to a super-lightweight scheduler you build upon.

To illustrate the differences, the AMD whitepaper on porting from FreeRTOS to Zephyr highlights that FreeRTOS’s main advantage is being “very minimal, making [it] easier to learn and optimize for heavily resource constrained devices,” whereas Zephyr “offers a multitude of features and drivers that can be used out of the box”. In other words, FreeRTOS = simplicity, Zephyr = completeness (with complexity).

A practical consequence of these philosophies: if you need to get a basic application running quickly on a microcontroller with limited resources, FreeRTOS will have you up and running faster. It’s straightforward C code that looks much like bare-metal development with an added scheduler. On the other hand, if your application demands rich connectivity (Wi-Fi, BLE), file systems, or needs to easily scale across different hardware, Zephyr’s architecture is already set up to handle that – you won’t have to integrate lots of external code because it’s provided in-tree. The trade-off is you’ll invest more time upfront learning Zephyr’s system (Kconfig options, driver model, etc.) and possibly dealing with its configuration overhead.

Scheduling and Determinism: Both RTOSes are designed for real-time performance. FreeRTOS uses a fixed-priority preemptive scheduler (with optional time-slicing for equal priorities). Zephyr by default also uses a priority-based preemptive scheduler, but uniquely it allows configuring different scheduling algorithms or policies (and can do SMP load balancing on multi-core systems). For most applications, both will meet typical real-time requirements (interrupt latency on the order of a few microseconds, etc.), as we will quantify in the performance section. Zephyr’s support for things like thread priority inheritance, deadline scheduling, and tickless idle are comparable or superior to FreeRTOS – FreeRTOS also supports priority inheritance for mutexes and tickless idle mode, but Zephyr’s timing subsystem is more extensive. Importantly, FreeRTOS does not natively support SMP (multi-core) scheduling in the official kernel (each core would need a separate scheduler instance or use vendor modifications), whereas Zephyr has had SMP support (e.g., used on some dual-core and multi-core chips) which can be a deciding factor if your project runs on a multi-core MCU.

Memory Management: FreeRTOS typically uses dynamic memory allocation (heap) for creating tasks and queues (though it has options to use static allocation). Zephyr leans towards static allocation and compile-time definition of resources (you can often define thread stacks, message pools, etc., at build time), which is said to better suit long-running systems by avoiding fragmentation. Zephyr also provides memory heaps and similar if needed, but the philosophy is to know your resource usage upfront (common in safety-critical design). This difference means FreeRTOS might be a bit more flexible at runtime for creating objects on the fly, whereas Zephyr encourages planning at compile time. However, this is a nuanced point and both can be used in either static or dynamic ways depending on developer choices.

In summary, FreeRTOS’s design is minimalistic and developer-driven (you bring the pieces you need), whereas Zephyr’s design is feature-rich and integrated, providing a full framework for embedded development. Neither is “better” universally – it depends on whether you favor lean simplicity or out-of-the-box functionality.

Features and Ecosystem Comparison

Next, let’s compare specific features and the broader ecosystem of Zephyr vs FreeRTOS. Here are some key differences and considerations:

• Device Drivers and HAL: FreeRTOS itself does not include device drivers for peripherals (UART, I2C, sensors, etc.). You rely on the microcontroller vendor’s SDK or write direct register code. In contrast, Zephyr comes with an integrated device driver interface and many drivers already available. Zephyr’s driver model means you can call standard APIs (for example, spi_write() or gpio_pin_configure()) and it will work across boards that have a compatible driver. This greatly enhances code portability. For example, Zephyr has drivers for things like GPIO, SPI, I2C, serial, sensors (accelerometers, temperature sensors, etc.), displays, and more, often implementing a common API. This means less time writing or porting driver code when you change hardware. FreeRTOS, being vendor-agnostic but minimal, leaves driver provision to you and the chip vendor – which can sometimes mean vendor lock-in to their SDK. Zephyr’s approach provides a unified hardware abstraction across vendors.
• Networking and Connectivity: If your project needs connectivity (network protocols), this is a major differentiator. Zephyr has built-in networking stacks: full TCP/IP support with IPv4/IPv6, MQTT, COAP, HTTP, Bluetooth Low Energy stack (with support for BLE Mesh), Zigbee, Thread, LoRaWAN, CAN bus, and more. These are production-quality and optimized for embedded use. For example, Zephyr includes a native IP stack and also can leverage third-party ones (like mbedTLS for TLS, OpenThread for Thread protocol, etc.). On the other hand, FreeRTOS requires adding libraries for networking. Amazon provides FreeRTOS+TCP (a TCP/IP stack) and FreeRTOS+TLS, as well as integrations for Bluetooth (via Nordic’s BLE stack on some platforms) in the context of AWS IoT, but these are separate components, not part of the core kernel. If you’re not using AWS’s distribution, you might use something like LWIP or TinyTCP integrated with FreeRTOS yourself. In short, Zephyr delivers extensive connectivity options out-of-the-box, whereas FreeRTOS is à la carte via add-ons or vendor solutions. This can be a critical factor for IoT devices that need wireless communication.
• File Systems and Storage: Zephyr includes file system support (e.g., LittleFS for flash-friendly filesystem, FAT for SD cards) and a storage subsystem. FreeRTOS doesn’t have a native file system – you’d integrate something like FatFs separately if needed. Similarly, Zephyr has a concept of a settings subsystem (for configuration storage in flash), and even supports updates via DFU (device firmware upgrade) frameworks built-in.
• User Interface and Graphics: Zephyr can integrate with GUI libraries like LVGL (Lightweight GUI Library) for devices that have displays. It also has drivers for displays (LCD, OLED, e-paper) and input devices. FreeRTOS by itself has no UI capability – you’d again bring in a library and drivers from the hardware vendor.
• Security Features: Both RTOSes being open source mean security depends on how they’re maintained. Zephyr, from the start, emphasized security as a key pillar – it has features like stack overflow detection, optional execution of threads in unprivileged mode, secure boot support (via MCUboot), cryptography libraries, and was one of the first RTOS projects to achieve the Open Source Security Foundation (OpenSSF) “Gold” badge for best practices. FreeRTOS benefits from AWS’s security expertise, but some have noted that Zephyr provides more frequent security updates and long-term support releases compared to FreeRTOS. FreeRTOS’s security largely comes from using AWS-provided secure connectivity libraries (which do get patched by Amazon as needed) and the simplicity of the kernel (small code surface area). Both can be used in secure devices, but Zephyr has more built-in frameworks for things like access control, secure services (like Trusted Firmware-M integration for Arm TrustZone), etc. One notable difference: Zephyr being modular and having open governance means security issues are openly tracked and fixed by the community; whereas FreeRTOS’s development is controlled by Amazon, and historically security patches for AWS FreeRTOS have been infrequent (AWS tends to bundle updates). If security certification or scrutiny is a priority, you might favor Zephyr for its track record and features, or use the upcoming safety/security-certified FreeRTOS variant if applicable.
• Cloud Integration: FreeRTOS, especially under AWS, is designed to plug into cloud services easily. If you plan to use AWS IoT Core, Device Defender, or Greengrass, there are libraries and examples ready-made for FreeRTOS devices. Zephyr is cloud-agnostic – it doesn’t favor one cloud, which is great if you want flexibility (you can use Azure IoT, Google IoT, or others by adding appropriate SDKs), but it means more work to integrate those compared to FreeRTOS with AWS. Essentially, FreeRTOS is the path of least resistance for AWS cloud connectivity, whereas Zephyr might require more integration effort for cloud, or using intermediate layers (Zephyr can run an AWS IoT SDK too, it’s just not pre-packaged). As one source put it, if your devices need to “talk to the cloud” a lot and you’re an AWS shop, FreeRTOS will get you there fastest. But if you want multi-cloud or a custom cloud solution, Zephyr’s neutrality might be better.
• Tooling and Development Experience: With FreeRTOS, development is often done using the vendor’s IDE or toolchain (for example, ESP32 developers use ESP-IDF which includes FreeRTOS, STM32 developers might use STM32Cube with FreeRTOS, etc.). There’s no official “FreeRTOS IDE” – you use whatever C/C++ development tools for your platform. Zephyr, however, provides a unified build system (CMake + devicetree + Kconfig) that is platform-agnostic. You can develop Zephyr projects from the command line with West (the Zephyr meta-tool) and your favorite editor, or integrate with VS Code, etc. Zephyr’s build outputs include a device tree blob, configuration headers, etc., which is more involved than the typical single FreeRTOSConfig.h and source files of a FreeRTOS project. This means Zephyr has a steeper learning curve initially (more complex build/config), but it also means once you learn it, you get a consistent experience across all boards and chips. No more diving into different vendor HAL setup code for each project – Zephyr abstracts that. Many developers say that once you “get” Zephyr, it starts to feel like developing for Linux (in terms of being able to quickly leverage existing drivers and subsystems) even though it’s for microcontrollers. In contrast, FreeRTOS development can feel like traditional microcontroller programming – which is familiar, but you may end up writing more custom code for things that Zephyr would have provided.
• Extensibility: FreeRTOS can be extended with middleware, but it’s on you to assemble the puzzle. Zephyr’s ecosystem already includes not just the OS, but testing frameworks (ZTest for unit testing on hardware or emulation), continuous integration hooks, and even support for running as a Linux userspace process (via their native_posix board for simulating on PC). The philosophy differs: Zephyr tries to give you everything you might need; FreeRTOS stays minimal and lets the ecosystem (or AWS distribution) fill the gaps.

To summarize the features, here is a high-level comparison of FreeRTOS vs Zephyr on key aspects:

Aspect	FreeRTOS (AWS)	Zephyr RTOS (Linux Foundation)
License	MIT (permissive, open source)	Apache 2.0 (permissive, open source)
Core Kernel Size	Very small (kernel ~5–10 KB minimum)	Small but variable (kernel can be 2–8 KB min)
CPU Architecture Support	40+ architectures (ARMv8-M, ARM Cortex-M/A/R, RISC-V, etc.) – ports provided by community/vendors	Multiple arch (ARM Cortex-M/A, x86, ARC, RISC-V, Xtensa, etc.) – official support for 600+ boards
Multiprocessing (SMP)	Not in main kernel (single-core only)	Yes, supports SMP on multi-core processors
Device Drivers	Not included (use vendor HAL or custom drivers)	Extensive built-in driver library (sensors, I/O, etc.)
Network Stack	Not in kernel; AWS IoT libs or add-ons (FreeRTOS+TCP, etc.) for networking	Built-in TCP/IP stack, IPv4/6, Bluetooth, Thread, LoRaWAN, CAN, etc.
File System	No native FS (integrate FatFs or other if needed)	LittleFS, FAT, NVS included in Zephyr’s subsystems
Memory Protection	Optional (FreeRTOS-MPU on Cortex-M33 provides basic MPU protection)	Yes, supports thread isolation, stack overflow protection, user mode threads
Scheduling	Preemptive or cooperative (configurable), priority-based (no dynamic algos)	Preemptive or cooperative, priority-based by default; optional algorithms (e.g., EDF), tickless idle
Ecosystem & Community	Huge user base, many examples; governed by AWS (contributions less community-driven)	Fast-growing community, active development by industry players; governed by Linux Foundation
Vendor Support	Provided via partners (chip vendors, AWS Partner Network); many MCU vendors include FreeRTOS in SDKs	Supported by multiple vendors collaboratively (Intel, NXP, Nordic, etc., contributing to main project)
Cloud Integration	Excellent for AWS (comes with AWS IoT libraries)	Cloud-agnostic (any cloud via additional SDKs; not tied to one)
Learning Curve	Easy to start (simple API, fewer concepts)	Steeper initially (many config options, tools like devicetree)
Documentation	Extensive and mature (plus many third-party tutorials)	Comprehensive official docs and growing community content (forums, blogs)
Long-Term Support (LTS)	FreeRTOS doesn’t have formal LTS versions; AWS updates occasionally	Zephyr offers LTS releases (e.g., LTS v2, LTS v3) with backported fixes for stability over years

As shown, Zephyr offers a more feature-rich, integrated stack, whereas FreeRTOS is lightweight and modular (bring your own extras). These differences mean that the “best” choice depends heavily on project requirements. If your application needs a lot of the features that Zephyr already has (complex networking, multiple drivers, etc.), Zephyr can significantly reduce development effort. If your application is simple and you value quick setup and minimal overhead, FreeRTOS might be the more straightforward path.

Performance and Footprint

Real-time performance is often a critical factor in choosing an RTOS. Both FreeRTOS and Zephyr are designed for fast context switching and low interrupt latency, but their differing scopes can influence performance. Let’s examine some real-world benchmarks and memory footprint considerations.

Memory Footprint: It’s a common perception that FreeRTOS is much smaller than Zephyr. Out of the box, a typical FreeRTOS binary with a simple task can indeed be just a few kilobytes, whereas a “Hello World” Zephyr application might be on the order of tens of KB due to default subsystems. However, when configured for minimum size, Zephyr can be surprisingly close to FreeRTOS in footprint. In fact, developers have observed Zephyr applications as small as ~8 KB, and Zephyr’s own documentation notes a theoretical minimal image around ~2 KB. FreeRTOS kernels similarly can be around 5–10 KB minimum. The difference is that a useful Zephyr configuration (with drivers, console, etc.) will pull in more code than a minimal FreeRTOS. If you add networking, file system, etc., to FreeRTOS, your total firmware size could equal or exceed a Zephyr build that has those features built-in. So, in terms of pure kernel size, FreeRTOS has an edge (smaller bare kernel), but Zephyr’s footprint can be kept quite low by disabling features, and it scales as you include more functionality. For most microcontrollers with at least 64KB+ flash, either RTOS can fit comfortably; for ultra-tiny devices (e.g., <32KB flash), FreeRTOS might be easier to squeeze in unless you very carefully trim Zephyr. RAM usage per thread might be a bit higher in Zephyr due to overheads for thread metadata and optional protections.

Benchmarking Context Switch and Interrupt Latency: A 2022 benchmark by UL Solutions compared FreeRTOS and Zephyr on an ARM Cortex-M4 (STM32F4) running a suite of kernel performance tests. Some illuminating results:

• Task Context Switch Time: In a cooperative context switch test (one task yielding to another), FreeRTOS took about 223 CPU cycles on average, whereas Zephyr took about 524 cycles – over twice as long. This indicates FreeRTOS has a lighter context switch overhead, likely due to its minimalistic scheduler. Zephyr’s additional kernel bookkeeping makes context switches a bit more expensive.
• Interrupt Latency: From interrupt trigger to running the handler, FreeRTOS averaged ~101 cycles, vs ~143 cycles for Zephyr. Again FreeRTOS showed lower latency. On constrained CPUs, those extra cycles mean Zephyr might have slightly slower high-priority interrupt responses (though tens of cycles difference on a 168MHz MCU is under 1 microsecond).
• Mutex Lock/Unlock (Synchronization): Interestingly, not all operations were slower on Zephyr. In tests for a task blocking on a locked mutex, Zephyr only took ~969 cycles while FreeRTOS took ~1964 cycles (FreeRTOS was ~2× slower in this case). This was attributed to FreeRTOS internally using a generic queue mechanism for mutexes, whereas Zephyr has a more optimized mutex implementation. Releasing a mutex and waking a waiting task was roughly similar (Zephyr ~1309 cycles, FreeRTOS ~1212 cycles) with FreeRTOS a tad faster.
• Message Queue throughput: Similarly, for inter-task message queues, Zephyr performed better in the “block on empty queue” scenario (Zephyr ~710 cycles vs FreeRTOS ~1660 cycles) – again likely due to different internal implementations. Sending a message to unblock a task was slightly faster on Zephyr as well (923 vs 1058 cycles).

We can summarize a few of these benchmark results in a table (lower cycles = faster):

Operation (on STM32F4 @168MHz)	FreeRTOS	Zephyr	Notes
Context switch (yield to next task)	~223 cycles	~524 cycles	Zephyr ~2× slower (more overhead)
Interrupt latency (ISR dispatch)	~101 cycles	~143 cycles	FreeRTOS faster (lower latency)
Mutex lock (task blocks on mutex)	~1964 cycles	~969 cycles	Zephyr faster (optimized mutex API)
Queue receive (task blocks on empty queue)	~1660 cycles	~710 cycles	Zephyr faster (optimized IPC)

These results show that FreeRTOS tends to have lower overhead for basic kernel operations like context switching and interrupt handling – likely due to its simplicity. Zephyr, however, can excel in higher-level synchronization primitives (mutexes, message queues), possibly due to more optimized or dedicated implementations (at the cost of a larger codebase). The benchmark authors concluded that one OS isn’t universally “better”; instead, each might suit different use cases (e.g., FreeRTOS for extremely context-switch-heavy scenarios, Zephyr for communication-heavy scenarios with lots of IPC). They also noted that tuning either RTOS (disabling features like stack protection on Zephyr, which they did for a fair comparison) is important for a fair match.

In practical terms, both FreeRTOS and Zephyr are capable of sub-millisecond response times and determinism needed for most IoT and embedded tasks. FreeRTOS’s leaner kernel means if absolute minimal latency is critical and your app is simple, it has a slight edge. Zephyr’s overhead is a bit higher but still very low in an absolute sense (hundreds of cycles). And Zephyr might allow you to do more in kernel space (like using its IPC mechanisms) without writing as much code, which can sometimes offset the raw cycle count differences.

Power consumption considerations: Both RTOS can be configured for tickless idle (i.e., they won’t periodically tick when idle, to let the CPU sleep). Zephyr has an advantage in providing a more integrated power management subsystem – for example, it can work with the hardware’s sleep states and device driver power states out of the box. FreeRTOS itself doesn’t manage peripheral power or deep sleeps – that’s left to the developer or vendor SDK. So, if low power is a big concern, Zephyr’s framework might help enforce a good low-power design (though using it requires more understanding). FreeRTOS can achieve the same low power, but you manually control it.

In summary, FreeRTOS is extremely efficient for simple scheduling – it’s hard to beat in terms of minimal runtime overhead. Zephyr introduces some overhead due to its richer features but still maintains good real-time performance, and sometimes even outperforms in specific scenarios due to more advanced algorithms. Both can be optimized to the needs of your application, and factors like clock speed, optimization level, and configuration will influence results. For a typical developer, these differences mean FreeRTOS might use a little less CPU time on background OS tasks, whereas Zephyr uses a little more but offers more functionality in return. It’s a classic trade-off: raw efficiency vs. built-in capabilities.