Zephyr RTOS: Devicetree, Kconfig, west & Testing

Zephyr

Zephyr is an open-source real-time operating system hosted by the Linux Foundation, designed for resource-constrained devices from tiny sensors to connected gateways. It supports hundreds of boards across Arm, RISC-V, x86, Xtensa, and other architectures, and includes far more than a scheduler: device drivers, networking stacks (IPv4/IPv6, Bluetooth Low Energy, Thread), file systems, logging, an interactive shell, power management, and secure boot integration. Several silicon vendors base their SDKs on it — Nordic's nRF Connect SDK is the best-known example.

Zephyr borrows ideas from Linux: hardware is described in devicetree, features are selected with Kconfig, and builds use CMake through the west meta-tool. That makes the same application portable across boards, at the cost of a learning curve for developers used to vendor IDEs.

TL;DR

west manages workspaces (Zephyr plus modules), builds, flashing, and debugging.
Kconfig (prj.conf) turns kernel features, drivers, and subsystems on or off.
Devicetree describes hardware; overlays adapt it per board without changing code.
Drivers are accessed through the device model with devicetree macros such as GPIO_DT_SPEC_GET.
The kernel provides threads, work queues, message queues, semaphores, mutexes, and timers.
Test with ztest and Twister, run on the host with native_sim, and use MCUboot for secure updates.

Quick Example

A blinky application that works on any board defining an led0 alias:

Configuration and a board overlay:

Core Concepts

west and Workspaces

west is Zephyr's meta-tool. west init and west update create a workspace containing Zephyr and the modules listed in a manifest (west.yml) — HALs, MCUboot, crypto libraries — pinned to exact revisions. west build, west flash, and west debug wrap CMake, flashing tools, and debuggers. Applications usually keep their own manifest so the whole workspace is reproducible.

Kconfig

Kconfig options in prj.conf select features: drivers, logging, networking, the shell, stack sizes. west build -t menuconfig (or guiconfig) browses options interactively, and board or application Kconfig fragments layer settings per configuration. Only enabled code is compiled, keeping images small.

Devicetree

Devicetree source (.dts) files describe each board's SoC, peripherals, pins, and on-board devices. Applications reference hardware by node labels and aliases, and overlays add or modify nodes for a specific board — connecting a sensor to a different I2C bus, for example — without touching C code. At build time, devicetree is converted to C macros used by drivers and applications.

Device Model and Drivers

Drivers implement standard APIs (GPIO, I2C, SPI, UART, sensor, display) and are instantiated from devicetree. Applications obtain devices with macros such as DEVICE_DT_GET or spec helpers like GPIO_DT_SPEC_GET, check readiness, and call the generic API, which makes code portable across boards.

Kernel Services

Stack sizes are configured per thread; Zephyr's thread analyzer and stack sentinels help find overflows. See RTOS.

Subsystems

Logging with deferred processing, an interactive shell over UART or RTT, a settings subsystem for persistent configuration, file systems, USB, power management, and full networking and Bluetooth stacks are available as Kconfig-selected subsystems.

Updates, Security, and Releases

MCUboot is the standard secure bootloader: it verifies signed images and supports swap-based updates with rollback. See Firmware OTA Updates.
Security: Zephyr publishes security advisories, supports TF-M on Arm TrustZone devices, and offers hardened configurations. See IoT Security.
Releases: regular releases add features; long-term support releases receive fixes for an extended period — products often build on an LTS line.

Testing

ztest is Zephyr's unit test framework, with suites, fixtures, and assertions.
Twister builds and runs tests across many boards and emulators, collecting results for CI.
native_sim builds Zephyr applications as host executables, enabling fast tests, debuggers, and sanitizers without hardware.
QEMU targets emulate several architectures for integration tests.

Best Practices

Describe Hardware in Devicetree, Not Code

Keep pin numbers and peripheral choices in overlays so supporting a new board means adding an overlay, not editing application code.

Pin the Workspace

Lock Zephyr and module revisions in your west manifest and upgrade deliberately, ideally from one LTS release to the next.

Test on the Host First

Run logic and many driver interactions on native_sim in CI, and reserve hardware-in-the-loop tests for what truly needs hardware.

Size Stacks Deliberately

Measure stack usage with the thread analyzer and leave headroom; overflows cause some of the hardest embedded bugs.

Common Mistakes

Hard-Coding Hardware

Doing Work in Interrupt Handlers

Enabling Everything

FAQ

What is Zephyr RTOS?

An open-source, Apache 2.0-licensed real-time operating system for embedded devices, hosted by the Linux Foundation, providing a kernel, drivers, networking, Bluetooth, security, and tooling across hundreds of boards.

How is Zephyr different from FreeRTOS?

FreeRTOS is primarily a small kernel that you combine with vendor drivers and libraries. Zephyr is a complete platform with its own driver model, devicetree, Kconfig, networking stacks, and build tooling, offering more portability at the cost of more complexity.

What are devicetree and Kconfig in Zephyr?

Devicetree describes the hardware — peripherals, pins, and devices. Kconfig selects software features — drivers, subsystems, and kernel options. Together they configure a build for a specific board and application.

Can I run Zephyr without hardware?

Yes. The native_sim target builds applications as host programs, and QEMU targets emulate several architectures, which is useful for development and automated testing.

What is west?

Zephyr's command-line meta-tool for managing workspaces and repositories, building, flashing, debugging, and running other extension commands.