Configure Zephyr: Kconfigs and Devicetree in Simple Words

### Overview In this Zephyr Summit talk, trainer and engineer Rory from AC6 provides an introductory guide to configuring the Zephyr RTOS, specifically focusing on Kconfig and Devicetree. Rory explains that developers transitioning from bare-metal programming, traditional real-time operating systems, or Linux user space often find Zephyr's configuration mechanisms intimidating. The talk aims to demystify these systems, explaining how Kconfig handles global feature selection and conditional compilation, while Devicetree manages hardware description and peripheral layout.

### Key Topics The presentation distinguishes between two developer perspectives: the **Application Developer**, who takes an existing board port and configures it to suit a specific application project, and the **Platform Developer**, who introduces new drivers, extends Zephyr capabilities, and creates board definitions. The speaker emphasizes that most work occurs at the application level through configuration overlays and fragment files rather than modifying core platform files.

The core configuration systems operate at build time: - **Kconfig System Configuration**: Used for enabling or disabling global kernel and software features, managing conditional compilation (in source files and CMakeLists), tuning kernel parameters, and setting default values. - **Devicetree Hardware Description**: A platform-agnostic format describing peripherals, memory-mapped register addresses, interrupts, and hardware settings, abstracting hardware specifics to make code portable.

### Technical Details - **Kconfig Build Flow and Tools**: The build process merges the board's default configuration (`<board>_defconfig`), the application's `prj.conf`, and any specified configuration fragments into a unified `.config` file in the build directory. This file is then transformed into a C header file, `autoconf.h`. The speaker notes that `.config` is automatically generated and should not be edited manually, as clean or pristine builds (`west build -t pristine`) will wipe temporary changes. Developers can explore options and manage dependencies interactively via tools like `menuconfig` and `guiconfig`. - **Persisting Kconfig Changes**: To make temporary modifications permanent, developers can save minimal configs (which only record settings differing from defaults) or diff `.config` states to produce configuration fragments. These fragments can then be included into the build via CMake using `set(EXTRA_CONF_FILE ...)`. Rory demonstrates this workflow by configuring tracing support using Tracealyzer. - **Devicetree Hierarchy and C Generation**: Devicetree descriptions use a tree hierarchy starting from root (`/`). Source files (`.dts`) include shared device tree source includes (`.dtsi`), which can be overlaid by application overlays (`app.overlay`) or extra overlays. The build merges these into `zephyr.dts` and ultimately generates `devicetree_generated.h`. - **Devicetree Properties and Bindings**: Nodes represent hardware devices using labels, unit addresses, and standard properties such as `compatible` (used to bind devices to appropriate C drivers), `reg` (defining base address and register size), and `status` (`"okay"` to enable). Devicetree property validation and typing (e.g., integers, strings) are enforced via YAML binding files. In C application code, drivers and peripherals are accessed through structs and macros such as `DT_NODELABEL`, `DT_PROP`, and `DEVICE_DT_GET`.

### Takeaways Both Kconfig and Devicetree are proven, standardized concepts adapted from mature open-source projects like the Linux kernel and U-Boot. In Zephyr, both systems resolve at build time into standard C header macros, providing modularity, consistency, and clean separation between software logic and hardware representation. Application developers can maintain clean projects by confining changes to `prj.conf`, `app.overlay`, and modular fragment files without modifying upstream source trees. During the Q&A, Rory noted that Devicetree debugging and pin multiplexing are best approached by inspecting the generated compiler error index, studying upstream `.dtsi` reference files, and consulting the Zephyr documentation.