Skip to content

Zephyr Overview

Zephyr is an open-source real-time operating system (RTOS) designed for resource-constrained devices such as microcontrollers. It provides a portable kernel, a hardware abstraction layer, networking stacks (including Thread and Wi-Fi), and a module system that lets third-party libraries plug into the build. Zephyr uses west as its meta-tool for managing multi-repo workspaces, building firmware, and flashing targets.

The KNX IoT Point API stack integrates as a Zephyr module. This means it ships its own CMakeLists.txt and Kconfig inside a zephyr/ folder, so the Zephyr build system discovers and compiles the stack automatically alongside the kernel and any other modules. Application developers include the stack by referencing it in their west manifest and enabling CONFIG_KNXIOT_LIB=y in their project configuration. From there, CoAP, OSCORE, and the full KNX IoT protocol run natively on supported boards without additional porting effort.

Contents

Zephyr Workspace Layout

A west workspace is a directory containing multiple git repos managed together:

ZephyrWorkspace/          ← west workspace root (contains .west/)
├── .west/
│   └── config            ← points to the manifest repo
├── zephyr-rtos/          ← Zephyr RTOS itself (also the default manifest repo)
├── modules/
│   ├── hal/
│   │   ├── espressif/    ← ESP32 HAL + binary blobs
│   │   ├── nxp/          ← NXP HAL + binary blobs
│   │   ├── cmsis/
│   │   └── ...
│   ├── lib/
│   │   ├── openthread/
│   │   ├── mbedtls/
│   │   └── knx-iot-point-api-stack/   ← KNX-IoT stack as a Zephyr module
│   └── crypto/
│       └── mbedtls/
└── knx-iot-point-api-demos/          ← application repo (manifest repo)

The .west/config file says which repo is the manifest repo (the one containing west.yml). In this project that is knx-iot-point-api-demos.

See HOW-TO-BUILD-ZEPHYR.md Steps 1–6 for how to create this workspace from scratch.

The Zephyr SDK

The SDK lives outside the workspace. It contains cross-compilers for each supported target architecture:

zephyr-sdk-0.17.4/
├── riscv64-zephyr-elf/     ← compiler for RISC-V (ESP32-C6, C3, H2)
├── arm-zephyr-eabi/        ← compiler for ARM (NXP FRDM-RW612, FRDM-MCXW72, ...)
├── xtensa-espressif_esp32_zephyr-elf/  ← compiler for ESP32, S2, S3
└── cmake/                  ← SDK CMake package, registered after running setup

CMake finds the SDK via the package registry (set up by west sdk install or by running the SDK setup script directly). See HOW-TO-BUILD-ZEPHYR.md Step 10 for installation instructions.

A Zephyr Application

my-app/
├── CMakeLists.txt     ← calls find_package(Zephyr), adds sources
├── Kconfig            ← app-specific config symbols
├── prj.conf           ← default Kconfig values (CONFIG_FOO=y)
├── boards/
│   └── <board>_<variant>.overlay  ← board-specific device tree additions
└── src/
    └── main.c

Build flow:

  1. west build --board <board> invokes CMake
  2. CMake finds Zephyr via the CMake package registry, loads ZephyrConfig.cmake
  3. Zephyr collects all CONF_FILE entries and merges Kconfig
  4. dtc compiles the device tree (.dts + .overlay) into a C header
  5. Ninja compiles everything: your app + Zephyr kernel + all modules

Kconfig

Kconfig is a configuration language (from Linux). The build system:

  1. Collects Kconfig files from Zephyr, all modules, and your app
  2. Merges all .conf files (prj.conf, board defaults, etc.)
  3. Produces build/zephyr/.config, the final set of CONFIG_* values
  4. Generates a C header autoconf.h with #define CONFIG_FOO 1

A module must define a Kconfig symbol before you can set it in a .conf file. For example, CONFIG_KNXIOT_LIB=y produces an "undefined symbol" warning if the stack provides no Kconfig file registering that symbol.

Zephyr Modules

Any external library can become a Zephyr module by adding:

my-lib/
└── zephyr/
    ├── module.yml      ← tells Zephyr "this is a module, here's my CMake and Kconfig"
    ├── CMakeLists.txt  ← builds the lib using zephyr_library() calls
    └── Kconfig         ← defines CONFIG_MY_LIB and its options

module.yml looks like:

name: my-lib
build:
  cmake: zephyr
  kconfig: zephyr/Kconfig

Zephyr discovers modules automatically from west projects or from ZEPHYR_EXTRA_MODULES. Once discovered, the module's Kconfig symbols become available globally and its CMakeLists.txt gets included in the build.

Device Tree

Device Tree describes hardware topology at compile time (not runtime). The flow:

Board .dts  +  .overlay  →  dtc compiler  →  zephyr.dts  →  devicetree_generated.h

An overlay adds or overrides nodes, for example defining a button on GPIO 9. Application code then uses macros like DT_ALIAS(button0) to retrieve the GPIO spec without hardcoding pin numbers.

Supported Boards

Disclaimer: The supported boards listed here help run the demo applications on those specific platforms. This does not mean that the Zephyr implementation or the KNX-IoT stack itself restricts itself to these boards; the stack is platform-independent and runs on any Zephyr-supported target. If you would like demo application support for another board or platform, feel free to open a merge request adding the necessary board/configuration files.

Vendor Board MCU Architecture Connectivity Binary blobs
NXP FRDM-RW612 RW612 ARM Cortex-M33 Wi-Fi 6 + BLE + 802.15.4 (tri-radio) west blobs fetch hal_nxp
NXP FRDM-MCXW72 MCX W72 ARM Cortex-M33 802.15.4 west blobs fetch hal_nxp
Seeed XIAO ESP32-C5 ESP32-C5 RISC-V Wi-Fi 6 + BLE + 802.15.4 west blobs fetch hal_espressif
Seeed XIAO ESP32-C6 ESP32-C6 RISC-V Wi-Fi 6 + BLE + 802.15.4 west blobs fetch hal_espressif
Seeed XIAO ESP32-C6 (6-channel relay variant) ESP32-C6 RISC-V Wi-Fi 6 + BLE + 802.15.4 west blobs fetch hal_espressif
Seeed XIAO nRF54L15 nRF54L15 ARM Cortex-M33 802.15.4 + nRF7002 Wi-Fi companion west blobs fetch hal_nordic
Seeed IoT Button v2 ESP32-C6 RISC-V Wi-Fi 6 + BLE + 802.15.4 west blobs fetch hal_espressif

XIAO ESP32-C5, the 6-channel relay variant, and IoT Button v2 are out-of-tree boards maintained under apps-zephyr/boards/ in the demos repository (not part of upstream Zephyr).

All boards support OpenThread as the default network transport for KNX-IoT. For debugging, ESP32 targets use the built-in USB-JTAG. NXP targets use J-Link.

For the full setup and build procedure see HOW-TO-BUILD-ZEPHYR.md.