FreeRTOS is a small real-time kernel you add to a chip vendor's SDK; Zephyr is a complete embedded operating system with its own driver model, build system, and connectivity stacks. Choose FreeRTOS for a simple product on a single well-supported microcontroller where you want minimal footprint and the fastest path to working firmware. Choose Zephyr for a connected product with Bluetooth, networking, over-the-air updates, multiple hardware variants, or a real chance you will change silicon later.
Two Different Philosophies
The distinction matters more than any feature table.
FreeRTOS is a scheduler. It gives you tasks, queues, semaphores, mutexes, timers, and not much else. Everything around it — drivers, radio stack, filesystem, bootloader — comes from the chip vendor's SDK or from you. It is a library you drop into an existing project, and you can read and understand the whole kernel in an afternoon.
Zephyr is a platform. It brings a hardware description layer (devicetree), a configuration system (Kconfig), a unified driver model, its own build tooling, plus subsystems for Bluetooth, IP networking, storage, logging, a shell, power management, and a bootloader with signed-update support. You write application code against portable APIs rather than against a specific vendor's HAL.
What Each One Is Good At
FreeRTOS strengths
- Tiny footprint. The kernel fits in a few kilobytes, so it runs on parts where Zephyr will not.
- Trivial to adopt. A competent engineer can add it to an existing bare-metal project in a day.
- It is everywhere. Nearly every chip vendor ships FreeRTOS-integrated examples, so their drivers, radio libraries, and reference applications work out of the box.
- Permissive licensing with no meaningful obligations for a commercial product.
- Enormous installed base. Whatever problem you hit, someone has hit it before, and hiring for it is easy.
- Predictability. Small enough to reason about fully, which is comforting in a hard real-time control loop.
Zephyr strengths
- Portability. Because drivers sit behind a common API and the board is described in devicetree, moving to a different MCU or a new board revision is a configuration change rather than a rewrite. In an era of component shortages and second-source pressure, that is a business advantage, not just an engineering nicety.
- Batteries included. A mature Bluetooth Low Energy host, IP networking, filesystems, settings storage, sensor abstraction, and a bootloader supporting signed images — all maintained together and tested against each other.
- Update story built in. The associated bootloader and image-management tooling make OTA firmware updates a configuration and integration exercise rather than a from-scratch project.
- Real engineering infrastructure. Logging, a runtime shell, tracing, unit tests that run on host, and continuous-integration support across many boards.
- Vendor-neutral governance under an open-source foundation, with permissive licensing and active safety-certification work — useful when you have to document your software process.
The Real Cost Difference
Zephyr's price is the learning curve. Devicetree, Kconfig, its build tooling, and its directory conventions take a team weeks to become fluent in, and the error messages are unforgiving early on. On a first project that ramp can cost more than the framework saves. On the second product, on the third board revision, and on the day a chip goes end-of-life, that investment pays back repeatedly.
FreeRTOS is cheap to start and gets more expensive later, in a different way: everything the platform does not give you, you build and maintain yourself. Teams routinely discover that they have written a private, undocumented, partially tested version of Zephyr's driver layer and update mechanism — and now own it forever. Both costs are real; the question is which one fits your product's lifetime. Either way, see firmware development cost for how these choices land in a budget, and IoT product development cost for the full connected-product picture.
How to Decide in Practice
- How constrained is the chip? Very small RAM and flash budgets point to FreeRTOS or bare metal.
- Do you need BLE, Wi-Fi, or IP networking? If yes, Zephyr's integrated stacks are a strong pull. If your vendor's own stack is excellent and FreeRTOS-integrated, that counterbalances it — see ESP32 vs STM32 for how much the ecosystem varies by vendor.
- Will there be more than one hardware variant? Multiple SKUs, board revisions, or a planned second-source MCU favor Zephyr strongly.
- Does the product update in the field? A signed, robust, rollback-capable OTA path is much less work on Zephyr.
- How large is the team, and how long is the product's life? A solo developer shipping one simple device is well served by FreeRTOS. A team maintaining a product family for years is not.
- Is bare metal enough? Do not skip this question. A device with one sensor, one radio, and a simple loop may need no RTOS at all, and an event loop with interrupts is simpler to verify than either option.
What to Verify Before You Commit
- Board support for your exact part. "The family is supported" is not the same as your specific chip and peripherals being supported.
- Driver maturity for the peripherals you actually use — USB, external flash, display, and low-power modes are the usual weak spots.
- The bootloader and update path, end to end, including recovery from a failed update.
- License obligations for the kernel and every module you pull in, including vendor blobs.
- Long-term support policy and how often you will be forced to migrate.
- Certification evidence if your device faces medical or functional-safety review — see ISO 13485 requirements.
- Who can maintain it later. Hiring reality is part of the technical decision.
Language choice interacts with this decision too; see Rust vs C for embedded. If the whole layer is new to you, start with what firmware is, and browse more in our embedded software hub.
Choosing the software foundation for a connected product and want the decision made against your real requirements rather than a preference? Contact Projects House and we will architect the firmware with you.