// the find
zephyrproject-rtos/zephyr
Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
Zephyr is a Linux Foundation RTOS targeting microcontrollers and small embedded systems, supporting ARM, RISC-V, x86, ARC, Xtensa, MIPS, and more. It's backed by major industry players (Nordic, NXP, Intel) and is the serious open-source alternative to FreeRTOS for anyone who needs real hardware abstraction, proper subsystems, and a real build system. Aimed at embedded developers building IoT, wearables, or industrial devices.
- Architecture support is genuinely broad and well-maintained — Cortex-M, Cortex-A/R, RISC-V, and arm64 all have real MPU/MMU implementations, not just stub ports
- Devicetree-based board description and Kconfig-driven configuration is the right model; it lets you separate hardware description from application config cleanly, similar to how the Linux kernel does it
- CI infrastructure is serious — Twister test runner, bsim (Bluetooth simulator) tests, CodeQL, compliance checks, and per-PR footprint tracking all run on every change
- West workspace tool solves the multi-repo embedded dependency problem better than git submodules, and the module system lets vendors ship out-of-tree drivers without forking
- The getting-started story is painful for newcomers: west, CMake, Python virtualenv, SDK installer, and Kconfig all have to work correctly before you get a blinking LED; debugging why something doesn't build often requires understanding all four simultaneously
- Driver quality is wildly inconsistent across boards — popular targets like nRF52 and STM32 are solid, but many contributed board ports have minimal testing and drivers that silently don't implement optional API calls
- Upstream churn is high and not always backward-compatible; APIs get deprecated and removed on a fairly aggressive schedule, so out-of-tree application code that isn't actively maintained against main breaks regularly
- Memory overhead at minimum config is reasonable but the default sample configs pull in a lot, and tuning a production build down to actual minimum footprint requires deep Kconfig knowledge that isn't well documented for beginners