FreeRTOS and Zephyr RTOS are two of the most widely adopted real-time operating systems in the embedded industry, but they serve different needs and design philosophies. FreeRTOS, originally created by Richard Barry and now maintained by Amazon Web Services, is a lightweight, minimal-footprint kernel focused on task scheduling, synchronization primitives, and memory management. It has been the de facto choice for resource-constrained microcontrollers for over two decades. Zephyr, backed by the Linux Foundation, takes a more comprehensive approach by providing a full-featured RTOS with built-in networking stacks, device driver frameworks, a sophisticated build system based on CMake and Kconfig, and native support for over 600 boards. FreeRTOS excels when you need a lean scheduler with minimal overhead on Cortex-M0/M3 class devices, while Zephyr is the stronger choice for complex IoT products requiring Bluetooth, Thread, or Matter protocol stacks.
What Are the Core Architectural Differences?
FreeRTOS has a monolithic kernel architecture with a minimal code footprint, often under 10 KB of flash. It provides core primitives: tasks, queues, semaphores, mutexes, timers, and event groups. The kernel itself does not include a HAL, driver model, or networking stack—these are provided through separate libraries like FreeRTOS+TCP and FreeRTOS+CLI. Zephyr, in contrast, uses a modular architecture with a sophisticated subsystem model. Its kernel provides threads, scheduling classes (cooperative and preemptive), workqueues, and a rich set of synchronization primitives including condition variables. Zephyr integrates a complete device driver model with device tree support (borrowed from Linux), a hardware abstraction layer, and full networking, Bluetooth, USB, and filesystem stacks.
How Do the Build Systems Compare?
FreeRTOS is typically integrated into vendor-provided IDEs such as STM32CubeIDE, MCUXpresso, or MPLAB X. The build process involves adding FreeRTOS source files to your project and configuring FreeRTOSConfig.h. This simplicity is both a strength and limitation. Zephyr uses a dedicated build system called West, powered by CMake and Kconfig. While it has a steeper learning curve, it provides powerful features like out-of-tree board definitions, application-specific device tree overlays, and reproducible builds. Zephyr's build system also supports multiple toolchains including Zephyr SDK, GNU ARM Embedded, and LLVM.
# Zephyr project structure
west build -b nrf52840dk_nrf52840 samples/hello_world
west flash
# FreeRTOS typical integration
# 1. Add FreeRTOS source to project
# 2. Configure FreeRTOSConfig.h
# 3. Build with IDE or Makefile
/* FreeRTOS task creation */
xTaskCreate(vTaskFunction, "Task1", 256, NULL, 1, &xHandle);
vTaskStartScheduler();
/* Zephyr thread creation */
K_THREAD_DEFINE(my_thread, 1024, thread_entry, NULL, NULL, NULL, 7, 0, 0);Which RTOS Has Better Hardware Support?
FreeRTOS supports virtually every microcontroller with a C compiler and a port layer, with official ports for ARM Cortex-M, RISC-V, Xtensa, PIC, AVR, and more. However, driver development is left to the developer or vendor SDK. Zephyr natively supports over 600 boards with standardized driver APIs covering GPIO, SPI, I2C, UART, PWM, ADC, CAN, and more. Adding support for a new board in Zephyr involves creating a device tree description and a board configuration file, following a well-documented process.
What About Networking and Connectivity?
This is where Zephyr has a decisive advantage. Zephyr includes production-quality Bluetooth LE (both Host and Controller), Bluetooth Mesh, OpenThread, Matter protocol support, Wi-Fi, 6LoWPAN, LwM2M, and a full TCP/UDP/IP stack. FreeRTOS offers FreeRTOS+TCP and the coreMQTT, coreHTTP libraries through AWS IoT integrations, but for Bluetooth or Thread, you typically depend on vendor-specific stacks (like Nordic's SoftDevice or Silicon Labs' Bluetooth stack).
When Should You Choose FreeRTOS vs Zephyr?
Use this decision framework to guide your choice:
- Choose FreeRTOS when: you need a minimal scheduler, your MCU has under 64 KB flash, you are working within a vendor IDE, or your project does not require complex networking.
- Choose Zephyr when: you need built-in BLE/Thread/Matter stacks, require device tree support, want a Linux-like development experience, or are building a complex IoT product.
- Consider both when: your organization has multiple product lines with varying complexity levels—FreeRTOS for simple sensors, Zephyr for gateway devices.
- Licensing: FreeRTOS uses the MIT license; Zephyr uses Apache 2.0. Both are permissive and suitable for commercial products.
Key takeaway: Choose FreeRTOS for lightweight scheduling on resource-constrained MCUs under 64 KB flash with vendor IDE integration. Choose Zephyr for complex IoT products needing built-in BLE, Thread, or Matter stacks, device tree hardware abstraction, and a Linux-like development experience with CMake and Kconfig build system configuration.
What Does a Real-World Migration from FreeRTOS to Zephyr Look Like?
When we implemented a BLE mesh lighting controller for a client at EmbedCrest, we initially prototyped on FreeRTOS with Nordic's SoftDevice BLE stack on the nRF52840. However, as the product requirements expanded to include Thread networking and Matter protocol support, we migrated to Zephyr RTOS using Nordic's nRF Connect SDK. The migration took approximately three weeks for a two-engineer team. Task creation calls (xTaskCreate) were replaced with Zephyr K_THREAD_DEFINE macros, FreeRTOS queues became Zephyr k_msgq message queues, and semaphores mapped to k_sem equivalents. The most significant effort was adapting the build system from a flat Makefile project to Zephyr's west/CMake/Kconfig structure and rewriting hardware access to use Zephyr's devicetree-based GPIO and SPI APIs. After migration, we gained native BLE Mesh, Thread, and Matter support without additional third-party libraries, reducing our total dependency count from 12 external libraries to 3.
What Are Common Pitfalls When Choosing an RTOS?
The most frequent mistake is selecting an RTOS based on popularity rather than project requirements. FreeRTOS is often chosen by default due to its ubiquity, but teams then spend months integrating separate networking stacks, driver frameworks, and build systems that Zephyr provides out of the box. Conversely, choosing Zephyr for a simple sensor node with a single SPI peripheral and no networking adds unnecessary complexity. Another common pitfall is underestimating the learning curve: Zephyr's devicetree, Kconfig, and west tool require 2-4 weeks of ramp-up for engineers accustomed to vendor IDEs and FreeRTOS. Evaluate the total integration effort, not just the kernel. If your product needs BLE or Thread, Zephyr saves 2-3 months of stack integration work. If your product is a bare sensor with UART output, FreeRTOS or even bare-metal is more appropriate.
How Do Memory Footprints Compare in Practice?
In production firmware, the minimal footprint difference is significant for constrained targets. A minimal FreeRTOS application (scheduler, two tasks, one queue, one semaphore) compiles to approximately 6-9 KB flash and 1-2 KB RAM on Cortex-M4 with GCC -Os optimization. An equivalent Zephyr application (kernel, two threads, one message queue, one semaphore) compiles to 12-18 KB flash and 4-6 KB RAM. However, when you add BLE connectivity, the gap narrows dramatically: FreeRTOS plus Nordic SoftDevice plus NimBLE consumes 200-280 KB flash, while Zephyr with its integrated BLE Host and Controller consumes 180-250 KB flash. For a full Matter over Thread application, Zephyr's integrated stack uses 450-600 KB flash total, while a FreeRTOS equivalent would require assembling OpenThread, Matter SDK, and BLE commissioning stack separately, often exceeding 550 KB with more complex integration. Memory-constrained projects targeting MCUs with 64 KB or less flash should favor FreeRTOS, while projects on 512 KB+ flash MCUs with networking requirements benefit from Zephyr's integrated approach.
