清风徐来——Zephyr实战篇(4)之Kconfig

NXP管管 · 发表于 2021-10-11 11:10:02

这次小编为大家带来的是ZephyrOS系列文章的第五篇，将为大家介绍Kconfig。

"清风徐来"前期回顾：
新型物联网操作系统Zephyr介绍
 Zephyr实战篇(1)之环境搭建
 Zephyr实战篇(2)之西(工具)
Zephyr实战篇(3)之DeviceTree
Zephyr实战篇(4)之Kconfig(本文)

这次小编紧接着上篇给大家带来ZephyrOS中对于Kconfig的介绍。

简单的来说，Kconfig就是Zephyr的配置系统，Zephyr内核可以在构建阶段，根据不同的配置，包含特定的应用和平台。而这个配置过程正是通过Kconfig实现的，其也与Linux内核配置所使用的Kconfig完全一致。设计目标就是让我们无需修改源代码就可以完成Zephyr的配置工作，包括内核，硬件，子系统等。
通常配置项（也被称作symbol）是在Kconfig文件中定义的。当然不同的配置项之间也是可以存在依赖关系的，比如定义一个符号A，它依赖于B，那么只有当B被使能之后，A才是有效的。同时，所有的符号可以被合并到一个叫做menu/sub-menu的组里面，便于图形化管理。
在正式开篇之前，小编先给大家推荐一个小工具，叫做menuconfig，他是一个可选的图形化工具，可以用来查看和修改Kconfig设置：

当然默认是不会打开的，即默认使用west构建工程是不支持menuconfig的，需要传入-t menuconfig参数：

west build –t menuconfig –b mimxrt1060_evksamples\hello_world

最终，所有配置项会被生成到一个叫做autoconf.h的文件中，没有用到的代码就不会再被编译系统所编译，以节省代码空间。

下面，介绍Kconfig中的一个比较重要的概念，visible和invisible符号。

首先说visible符号，也就是那些可以在menuconfig窗口中见到的，这些符号，通常都有一个prompt属性，即一个字符串来进行描述，例如：

config FPU
  bool “Support floating point operations”
  depends on HAS_FPU
然后，我们就可以在menuconfig界面中找到他：

[ ] Support floating pointoperations

Invisible符号则与之相对，一般没有prompt属性，即字符串来说明，例如：
config CPU_HAS_FPU
  bool
  help
   This symbol is y if the CPU has a hardwarefloating point unit.

他的特殊性在于，这些符号对于用户是不可见的，即不能通过menuconfig提供的图形化工具来配置，只能通过其他手段来修改其的值。

例如，通过Kconfig.defconfig文件设置下面这个符号的值为32：

config FOO_WIDTH
  int

我们就可以在Kconfig.defconfig文件中定义：

config FOO_WIDTH
  default 32
endif

这样一来，我们就修改了FOO_WIDTH的默认值为32。

要注意的是，Kconfig.defconfig中所定义的默认值会覆盖掉起始值，且优先级比较高。

我们再举一个choice的例子，比起上面我们定义的config形式的变量，choice类似于一种单选框，当有多个配置存在时，只能一个配置项有效，这样一来，达到一个互斥的效果。要如何操作呢？假定有一个choice叫做FOO，他有两个配置项A和B，初始默认值是B：

choice FOO
  bool “Foo choice”
  default B
config A
  bool “A”
config B
  bool “B”
endchoice

下面我们把他的默认值修改为A，完成这个操作，除了在Kconfig.defconfig中修改外，我们还可以在prj.conf中添加：

choice FOO
  default A
endchoice

当然，这里要注意，如果我们定义了一个invisible的choice变量FOO的话，就只能通过Kconfig.defconfig来修改了。

那么在Zephyr工程中，都有哪些修改默认配置的地方呢？如果只考虑板级（即Zephyr所支持的开发板）+ 应用这一层，大致分为三类：

板子相关的配置文件，一般名为：boards/<ARCH>/<BOARD>/<BOARD>_defconfig

任意的CMake cache文件，以CONFIG_开头

应用配置：
a)    默认prj.conf
b)    通过-DCONF_FILE=<conf_file>指定，进行重载
c)    通过-DOVERLAY_CONFIG=<conf_file>指定，进行扩展
d)    通过prj_<BOARD>.conf进行重载
e)    通过boards/<BOARD>.conf进行扩展

那么小编就不再扩展Kconfig的其他语法了，大家可以参考这里来了解更多。

至此，Zephyr所使用的两大配置系统就大致讲完了，那么有朋友可能会问了，我们什么时候要用DeviceTree什么时候要用Kconfig呢？小编在这里简单总结一下：

使用设备树来描述硬件和启动配置，例如板载外设和设置启动时系统时钟频率等

使用Kconfig来配置哪些源代码将要被放到最终的镜像中，例如是否添加网络的支持，哪个驱动是需要的。

通俗点讲，DeviceTree负责管理那些硬件资源，Kconfig负责管理软件资源。

举个例子，有个设备同时拥有2.4GHz，multi-protocol radio; 蓝牙和802.15.4，那么设备树就用来描述：

·是否有radio硬件存在
·兼容性驱动
·启动阶段配置，比如TX power in dBm

Kconfig文件决定哪个软件包需要被构建，是选择BLE还是选择802.15.4协议栈。

聊到这里，结合上一篇关于DeviceTree的文章，小编就将DeviceTree和Kconfig的一

些知识点分享给大家了，不过，限于篇幅，都只是一些比较简单的介绍，大家可以自行深入探索。

阅读全文