Configuring Zephyr: A Deep Dive into Kconfig

 

We presented The Zephyr Project RTOS and illustrated a personal best practice for beginning with "Zephyr" in an earlier blog post. A custom West manifest file is a great way to guarantee that your code is always at a known baseline when you begin development, as you saw in that blog post. Following the creation of your custom manifest file and the establishment of your baseline repositories using West, what comes next in your Zephyr journey?

 

Enabling particular peripherals, features, and subsystems is one of the first steps in putting embedded software into practice. Some MCU manufacturers, like STM32, Microchip, and TI, have tools in their IDEs that let developers add subsystems to their codebase and enable peripherals in their projects. These tools, however, are closely related to the MCUs that the vendors sell. Applying these tools' functionality to other MCUs is challenging, if not impossible.

 

However, we can enable a specific MCU subsystem or feature using a vendor-neutral mechanism provided by The Zephyr Project RTOS. For people like me who don't like GUIs, this mechanism can be used with a command line. The name of this utility is "Kconfig." I'll go over what Kconfig is, how it functions, and the various ways we can use it to incorporate particular features and subsystems into our Zephyr-based project in this blog post.

 

WHAT IS KCONFIG?

Kconfig is still utilized today as a component of the kernel compilation process, having been initially created as part of the Linux kernel. Kconfig has a particular grammar. Although fascinating, the specifics of how Kconfig is implemented in the Linux kernel are outside the purview of this blog post. Alternatively, if you're interested, you can read my article here: (https://www.linux-magazine.com/Issues/2021/244/Kconfig-Deep-Dive), which walks through the Kconfig source code.
However, after seeing an example, it's simple to become familiar with the format of a "Kconfig"—the slang term for a specific configuration option. The Kconfig system consists of three primary components.

First, there is the collection of Kconfig files scattered across different OS codebase directories. For example, if we look under "drivers/led" within the Zephyr codebase, we see a file named Kconfig with the following contents:

 menuconfig LED

     bool "Light-Emitting Diode (LED) drivers"

     help

      Include LED drivers in the system configuration

if LED

.

.

.

config LED_SHELL

    bool "LED shell"

    depends on SHELL

    help

      Enable LED shell for testing.

source "drivers/led/Kconfig.gpio"

.

.

.

endif # LED

Using the if statement, the line that begins with "menuconfig" tells the Kconfig system that "LED" contains a number of feature options that are only visible if the "LED" feature is enabled. The user can then activate the "LED_SHELL" option if the "LED" feature is enabled. The result of this configuration option is a Boolean, which determines whether this feature is enabled or disabled, as the line that follows shows. If a configuration option refers to a particular configuration parameter, the result can also be an integer in addition to a Boolean. The line that starts with "depends" indicates that in order for the "LED_SHELL" feature to be visible, the "SHELL" feature needs to be enabled. As a result, only after the "LED" and "SHELL" features have been enabled will the "LED_SHELL" feature become visible. A more detailed explanation of the feature can be found in the two lines that begin with "help". Last but not least, the final line before the "endif" lets us refer to additional Kconfig files, which aids in classifying components. As though they were copied and pasted, the features of the referenced file are present in the current file. It is crucial to remember that the path to "source" comes from the Zephyr codebase's root.

HOW SHOULD YOU USE KCONFIG?

A collection of applications that enable users to enable or disable the features listed in all Kconfig files make up the second component of the Kconfig infrastructure. Zephyr provides a Visual Studio Code extension that enables users to carry out this task with a graphical user interface.
For command line enthusiasts like myself, the VS Code extension provides an alternative to utilizing a graphical user interface. In order to configure Zephyr appropriately, the extension can accept a file, which is the final component of the Kconfig infrastructure and contains a set of configuration options that can be turned on or off. The following snippet shows an example.

CONFIG_BT=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_GATT_CLIENT=y

CONFIG_BT_MAX_CONN=1

CONFIG_BT_L2CAP_TX_MTU=250

CONFIG_BT_BUF_ACL_RX_SIZE=254

There is nothing complicated about the file format. "CONFIG_" appears at the start of each line, and then the configuration option's name. After the "=" symbol, the line either ends with a "y" to activate the feature or a "n" to deactivate it. In the example above, we configure the stack parameters and activate the Bluetooth stack in Zephyr along with specific stack features. "prj. conf," which contains user-defined features, is the default file in the majority of Zephyr-based applications.

 

CONCLUSION

The Zephyr Project RTOS provides a robust, vendor-neutral mechanism called the Kconfig infrastructure that allows us to fully configure our entire application. It can be used to control particular subsystems and peripherals within the MCU in addition to turning on or off individual stacks within the RTOS and setting configuration parameters.

Ready to bring your embedded systems to life with optimized configurations and robust solutions? We specialize in hardware design and software development tailored to your project needs. Whether you're configuring peripherals or diving deeper into Kconfig for your Zephyr-based applications, our experts are here to support you every step of the way.

👉 Contact Us Today and let's transform your embedded ideas into reality!