The RTOS That Thinks It's Linux
Zephyr is what happens when the Linux Foundation applies the Linux development model to a microcontroller kernel: vendor-neutral governance, a single upstream tree, Devicetree for hardware description, Kconfig for configuration, and a merge cadence that looks like a real OS project because it is one. Per the Zephyr Project documentation, the tree supports over 1,000 boards across ARM Cortex-M, RISC-V, Xtensa, and more, with networking, Bluetooth LE, filesystems, and crypto in-tree rather than bolted on.
That's the pitch in one line: FreeRTOS gives you a kernel and wishes you luck with the rest; Zephyr gives you an integrated embedded OS and asks you to learn its build system.
Devicetree Is the Moat
The feature that actually changes your engineering life is hardware abstraction done the Linux way. Your board is described in a Devicetree file: which UART, which pins, which sensor on which I2C address. Application code asks for "the temperature sensor," not "TWI0 at 0x48." Port the product to a different MCU and, in the well-behaved case, you edit the board file and rebuild, with the same application code running on an ESP32-C6, an STM32H7, or a $0.13 CH32V003 RISC-V part. Nordic bet its entire nRF Connect SDK on Zephyr, contributing roughly a quarter of upstream commits, which is why the freshest BLE, Thread, and Matter support tends to land there first.
The cost is the learning cliff. Devicetree overlays, Kconfig fragments, and the west meta-tool are genuinely alien to a firmware engineer raised on a Makefile and a vendor HAL, and the first two weeks are humbling. Teams describe the same arc: fight the build system, despise it, then quietly refuse to go back once multi-board support pays out.
Where It Beats FreeRTOS, and Where It Doesn't
Choose Zephyr when you're building a product line rather than a product: multiple boards, radio protocols (BLE/Thread/Matter), and a team that benefits from upstream code review and long-term-support releases. The in-tree subsystems mean your TLS, your flash filesystem, and your Bluetooth stack were integration-tested together, which is precisely the glue work that eats months in kernel-plus-libraries land, as we noted in the FreeRTOS guide.
Choose FreeRTOS when the product is one chip doing one job, when your vendor SDK is built on it anyway (every ESP32), or when binary size is king: a minimal Zephyr image starts noticeably heavier than an 4-9 KB FreeRTOS kernel, though a full connected stack converges toward the same footprint on both. And if the decision is really about hard deadlines versus rich userland, that's the RTOS-versus-Linux question, not a kernel bake-off.
Safety certification sits in between: the project maintains functional-safety work and Zephyr's LTS releases are auditable, but if you need pre-baked IEC 61508 or DO-178C artifacts today, the certified commercial kernels still own that column of the matrix.
Frequently Asked Questions
Is Zephyr production-ready or still a science project? Production. It ships in Nordic-based products at enormous volume, and the LTS releases get multi-year maintenance. The governance is the boring, durable kind: Linux Foundation, published roadmaps, real security advisories with CVEs.
Do I have to use west and Devicetree? Effectively yes, and fighting the workflow is the classic self-inflicted wound. Budget the two-week cliff, copy an in-tree board that resembles yours, and use overlays instead of editing board files. The system rewards surrender.
Zephyr on ESP32: worth it over ESP-IDF? If you're all-in on Espressif silicon, ESP-IDF (FreeRTOS-based) has deeper chip support and WiFi maturity. Zephyr on ESP32 makes sense when the same firmware must also run on non-Espressif parts, which is exactly the multi-board case Devicetree exists for.
What's the licensing? Apache 2.0 for the kernel and most of the tree. Commercially friendly, patent-granting, no copyleft surprises.
