For most of embedded history, choosing a real-time operating system meant accepting a vendor’s ecosystem. You picked a chip, used that vendor’s SDK and RTOS, and rewrote a meaningful share of your firmware if you ever changed silicon.
Zephyr is the main reason that assumption is weakening. It is a Linux Foundation project supported by Nordic, NXP, Intel, STMicroelectronics and others, with a consistent driver model across hundreds of boards — and it has been displacing vendor RTOS choices in new designs for several years.
This guide explains what Zephyr actually provides, how it compares with FreeRTOS and bare-metal development, where it costs you time, and when it is the right choice.
What Zephyr Is
Zephyr is a small-footprint RTOS for resource-constrained devices, but the kernel is the least interesting part. What distinguishes it is everything around the kernel:
- A unified driver model. A sensor, SPI bus, or GPIO is accessed through the same API regardless of vendor, so application code survives a chip change.
- Devicetree configuration. Hardware description lives in data files rather than scattered through C, so board variants are a configuration change, not a code fork.
- Integrated networking and connectivity. Bluetooth LE, Thread, Wi-Fi, TCP/IP, LoRaWAN and CAN ship as part of the project rather than as separate vendor stacks.
- A real build and test system. West for dependency management, Kconfig for configuration, plus native simulation and continuous integration support.
- Security infrastructure. MCUboot for secure boot and firmware updates, TF-M support, and a defined vulnerability process.
FreeRTOS gives you a scheduler. Zephyr gives you a platform, with everything that implies in both directions.
Zephyr vs FreeRTOS vs Bare Metal
| Bare metal | FreeRTOS | Zephyr | |
|---|---|---|---|
| Scope | Your code, vendor HAL | Scheduler plus some add-ons | Full OS with drivers and stacks |
| Portability across vendors | Very low | Low — drivers stay vendor-specific | High — common driver API |
| Learning curve | Low | Low to moderate | Steep initially |
| Footprint | Smallest | Small | Small but larger; highly configurable |
| Connectivity stacks | Vendor SDK | Vendor or third party | Included and maintained |
| Secure boot and OTA | Build it yourself | Build or integrate | MCUboot integrated |
| Best for | Tiny, fixed-function devices | Familiar teams, simple tasking | Connected products expected to last |
The honest summary: for a simple device that will never change silicon and has no networking, bare metal or FreeRTOS is lighter and faster to start. Zephyr’s advantages appear once a product needs connectivity, security, updates, and a lifespan long enough that hardware will change underneath it.
Why Adoption Is Growing
The Costs You Should Expect
Zephyr is not a free upgrade, and teams that adopt it without planning for these find the first weeks frustrating.
- A genuinely steep start. Devicetree, Kconfig, and west are three unfamiliar systems at once. Expect reduced productivity for the first few weeks even from strong embedded engineers.
- Debugging crosses layers. A problem may sit in your code, a driver, the devicetree, or a Kconfig option, and narrowing that down takes experience.
- Documentation assumes context. It is extensive and accurate, but often written for people who already understand the model.
- Moving releases. The project evolves quickly; pin a version and schedule upgrades deliberately rather than tracking the latest.
- Larger footprint than minimal alternatives. Configurable down to small sizes, but a bare-metal loop will always be smaller.
Adopting Zephyr Sensibly
One more practical note: Zephyr sits on the firmware side of the hardware and firmware boundary, and its devicetree model works best when firmware has been involved in pin assignment before the schematic is frozen.
Frequently Asked Questions
Conclusion
Zephyr is gaining ground because it addresses the problems that actually hurt connected product teams: vendor lock-in, connectivity stacks that are expensive to build, security infrastructure that is now expected, and firmware that cannot be tested without hardware.
The price is a real learning curve and a larger footprint than a minimal alternative. For a simple, fixed-function device that is a bad trade. For a connected product meant to ship in volume, receive updates, and survive a change of silicon, it is increasingly the obvious one.