转载自：cnblogs.com ｜作者：Jayant Tang
Zephyr Project是Linux基金会推出的一个Apache2.0开源项目，版权非常友好，适合用于商业项目开发。包含RTOS、编译系统、各类第三方库。NCS中的例程基本都跑在Zephyr RTOS上。
对于之前只接触过IDE+外设驱动库这种开发方式的开发者来说，Zephyr的配置和编译系统可能比较令人费解，但是一旦你能掌握，就会发现它的方便之处。
因篇幅较长，文章将分为上下两篇，本文重点介绍了NCS中的配置和编译工具，包含一些其他开发环境中常见的CMake，Kconfig，DeviceTree等的简单介绍。
通过CMake管理源码
本节只简要介绍NCS中常见的CMake使用方法，篇幅有限不可能完整的介绍CMake。希望完整学习CMake的话可以参考CMake官方文档.
CMake基本写法
通过zephyr/samples/hello_world例程的CMakeLists.txt，我们可以看到：
# SPDX-License-Identifier: Apache-2.0# 指定CMake版本cmake_minimum_required(VERSION 3.20.0)# 从系统环境变量${ZEPHYR_BASE}找到NCS中的Zephyr安装目录# 并把整个Zephyr系统当作包来导入find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})# 设定项目名称project(hello_world)# 把main.c添加为app目标的源码target_sources(app PRIVATE src/main.c)
这里的编译目标是app，最终会编译为libapp.a，也就是把用户自己的应用层代码编译成库的形式。最后再链接进Zephyr系统。
这里的PRIVATE控制的是编译的行为：
PRIVATE：main.c修改后，只会重新编译app目标
PUBLIC：main.c修改后，app目标要重新编译，且所有与APP目标链接的其他目标也要重新编译
条件添加源码
条件添加也很好理解，就是某个CMake变量值为true时，才把源码添加到目标中去。例如：
# Include UART ASYNC API adaptertarget_sources_ifdef(CONFIG_BT_NUS_UART_ASYNC_ADAPTER app PRIVATEsrc/uart_async_adapter.c)
这里就是CONFIG_BT_NUS_UART_ASYNC_ADAPTER为y时，才添加src/uart_async_adapter.c到源码中。
把整个目录添加源码
有时目录层级很多，我们没必要在一个CMakeLists.txt里把所有源码都添加完。
|-CMakeLists.txt|-aaa| |-CMakeLists.txt| `-main.c`-bbb|-CMakeLists.txt`-hello.c
这时，就可以在项目根目录的CMakeLists.txt中写：
add_subdirectory(aaa)add_subdirectory(bbb)
然后在两个子目录的CMakeLists.txt中添加对应的源码。
当然，目录也是可以条件添加的，最典型的就是在${NCS}/zephyr/driver/CMakeLists.txt中：
add_subdirectory_ifdef(CONFIG_ADC adc)也就是说，只有启用了CONFIG_ADC=y，Zephyr才会去编译${NCS}/zephyr/driver/adc/目录下的驱动。
此外，如果再去看${NCS}/zephyr/driver/adc/CMakeLists.txt：
...zephyr_library_sources_ifdef(CONFIG_ADC_MCUX_LPADC adc_mcux_lpadc.c)zephyr_library_sources_ifdef(CONFIG_ADC_SAM_AFEC adc_sam_afec.c)zephyr_library_sources_ifdef(CONFIG_ADC_NRFX_ADC adc_nrfx_adc.c)zephyr_library_sources_ifdef(CONFIG_ADC_NRFX_SAADC adc_nrfx_saadc.c)...
就可以看到，这里又根据不同的MCU平台，来添加对应的adc驱动代码。
添加include目录
也就是存放头文件的目录，如：
# 添加CMakeLists.txt所在目录下的inc/目录到app目标target_include_directories(app PRIVATE inc)# 也是可以条件添加的zephyr_include_directories_ifdef(CONFIG_MEMFAULT configuration/memfault)
设置变量
和宏定义类似，把A定义成B。主要是用来定义一些编译系统会用到的东西，例如：
# 指定自己项目的device tree overlay文件set(DTC_OVERLAY_FILE app.oerlay)
除了上述直接把变量定义写在CMakeLists.txt内，还可以在命令行编译时，通过-D选项传入的参数：
west build -b nrf52840dk/nrf52840 -d build --sysbuild -- -D DTC_OVERLAY_FILE app.overlay注意，CMake参数的传递在--之后，再用多个-D分别传入。
上述通过编译命令添加的CMake变量，也可以在nRF Connect for VS Code的界面中编译时输入：
在CMakeLists.txt中用set()函数，或者在命令行编译时用-D参数，都可以设置你自定义的变量。但是更多时候，还是用来设置Zephyr编译系统的一些选项，这里给出一个表格，方便查找：
Zephyr系统自带选项
CMake中直接修改Kconfig配置项
直接在CMake中指定某个Kconfig选项的值。
命令行参数：
-D= CONF_FILE
设置当前工程的Kconfig基本配置文件。通常是prj.conf。
命令行参数：
# 设置默认的配置文件-DCONF_FILE=.conf # 设置特定Build Type下的配置文件-DCONF_FILE=prj_.conf`
SHIELD
很多开发板都是支持Arduino接口的，因此很多器件厂商/分销商会制作Ardiono接口的扩展板：
Zephyr中，也会有这些扩展板的配置（包含device tree和Kconfig）。如果要在工程中启用扩展板，则需要设置CMake变量：
set(SHIELD nrf21540_ek)或者在编译目标的配置中添加CMake参数：
编译时，会自动合并原始板子和扩展板的Kconfig和Devicetree。
更多CMake配置项，请参考Providing CMake Options
总结
项目通过CMake管理源码和include目录。项目本身会把应用代码编译成build/app/libapp.a，最后和Zephyr系统一起链接成可执行文件。
Zephyr系统本身的内核、库、驱动等源码也都是用CMake来管理的。
通过Kconfig管理配置
一个编译系统中，肯定有很多配置项的需求，如：
布尔类型：开关某些功能，决定一些库和内核功能代码是否参与编译
枚举类型：配置某些预设好的功能，比如日志打印级别(ERR/WRN/INF/OFF)等
数值类型：设置具体参数，如线程栈大小、蓝牙MTU Size大小等
Kconfig就是用来结构化地管理整个项目以及SDK中所有的配置项的。
在Zephyr系统中，RTOS内核、各个功能模块都会有自己的配置项；并且，开发者自己的项目也会有很多配置项。这些配置项之间可能还有依赖关系。
Kconfig就是把一个模块的所有配置项组成一个菜单。所有模块的菜单，通过层级关系拼接在一起，形成一个大菜单。菜单有默认配置项，开发者可以随意修改配置项。只需把自己和默认配置项有差异的部分写到一个配置文件（*.conf）中，就可以方便地进行配置项的管理了。
Kconfig不止适用于源码。编译系统（CMake）也可以用到其中的配置来决定源码是否参与编译。
Kconfig是结构化的，可以规定配置项之间的依赖关系；支持提前枚举好允许的配置范围。
Kconfig菜单方便互相引用。一个功能库在提供源码和API之外，还会提供一个Kconfig菜单，方便开发者使用。
配置项可以保存到配置文件中。多个配置文件可以合并、覆盖。
Kconfig交互式菜单
我们知道，Kconfig实际上是定义了一个菜单，在哪里能看到这个菜单呢？
我们可以在VS Code中点击nRF Kconfig GUI:
也可以把鼠标悬浮在这个按钮上，点右边的三个点，然后用Guiconfig（弹窗）或Menuconfig（命令行）的方式进行配置。
这里就只介绍nRF Kconfig GUI：
修改并保存配置项
如果我们只是单纯点击界面右上角的"Apply"，那么这些配置是保存在.config中的。这是编译过程中生成的一个临时文件，是把各种配置项来源整合到一起，得到的最终配置文件。
如果我们进行pristine build，那么.config文件就会重新生成，我们之前的修改就消失了。
要想永久保存，应该点击“save to file”。然后保存到配置文件（如prj.conf）中。
当你熟练后，就不需要再去这个菜单中找选项了，直接修改配置文件（如prj.conf）即可。
构建时配置项的合并
配置项有许多来源。在构建可执行文件时，会在configure阶段，compile之前，对所有来源的配置项按顺序进行合并，合并后的文件就是前面说的临时配置文件.config，路径为：
注：在NCS v2.7.0之前，未采用Sysbuild。不使用Sysbuild时，合并后的配置文件位于build/zephyr/.config
那么，配置项总共有哪些来源呢？
Kconfig菜单中的默认值
选择板子后，板子自带的一些config。可以在zephyr/boards或者nrf/boards中查看。
CMake变量CONF_FILE指定的配置文件内的配置项，这也是最常用的。默认情况下是以下两个文件：
项目的prj.conf，它可以覆盖默认值；
项目的boards/
CMake变量EXTRA_CONF_FILE指定的额外配置文件，也就是在VS Code中创建新的build target时，可以选择的"Extra Kconfig fragments"
了解Kconfig菜单基本写法
可以先从一个简单的例子${NCS}/nrf/samples/bluetooth/peripheral_uart来参考：
# 引用Zephyr的Kconfig菜单source "Kconfig.zephyr"# 自定义本项目的菜单menu "Nordic UART BLE GATT service sample"... 此处省略...endmenu
菜单中的选项，可以配置它的类型、说明，和默认值：
# 此选项用来设置Nordic UART Service线程的栈大小# 并且具有默认值config BT_NUS_THREAD_STACK_SIZEint "Thread stack size"default 1024helpStack size used in each of the two threads
菜单中的选项可以连锁使能：
# 当本选项被设置成y时，通过select，同时把CONFIG_BT_SMP的值设置成yconfig BT_NUS_SECURITY_ENABLEDbool "Enable security"default yselect BT_SMPhelp"Enable BLE security for the UART service"
此外，一个选项也可以指定一个依赖项。如果本选项被启用，但依赖项未被启用，则编译前的配置过程就会报错：
# 配置是否在系统启动时，自动初始化USB ACM设备 （用于输出日志）# 此配置依赖于CONFIG_USB_CDC_ACM=y，也就是说，起码要把USB_CDC_ACM的代码编译进来config USB_DEVICE_INITIALIZE_AT_BOOTbool "Initialize USB device support at boot"depends on USB_CDC_ACMhelpUse CDC ACM UART as backend for console, shell, or logging.
当然，Kconfig也不是说要写的非常大，把整个项目的配置都写进去。你也可以每个子文件夹下单独写Kconfig，然后在项目的Kconfig中进行包含：
# 通过绝对路径进行包含source "xxx.Kconfig"# 通过相对路径进行包含rsource "src/xxx.Kconfig"
某些简单例程，例如zephyr/samples/hello_world，没有什么配置项，所以是可以没有自己的Kconfig的。这种情况下，相当于直接用了Zephyr的Kconfig菜单，也就是相当于：
source "Kconfig.zephyr"显性与隐性配置项
在Kconfig中定义菜单选项时，我们会发现，大多数选项，在变量类型后面会有一个说明字符串(prompt)。
如bool后面的"Support floating point operations"：
config FPUbool "Support floating point operations"depends on HAS_FPU
这意味着，这个配置项会出现在Kconfig交互式菜单中，我们可以在交互式菜单中修改它的值：
[ ] Support floating point operations也可以用prj.conf之类的配置文件来直接改它的值：
CONFIG_FPU=y但是，也有一些隐性配置项，它们的变量类型后面不带说明字符串，我们无法直接修改它的值：
config CPU_HAS_FPUboolhelpThis symbol is y if the CPU has a hardware floating point unit.
一个CPU到底带不带FPU，肯定不由开发者的配置决定，因此不能直接修改是很合理的。
这种配置，通常是通过连锁使能select的方式，被其他配置项使能的，例如zephyr/soc/arm/nordic_nrf/nrf52/Kconfig.soc：
# 隐性配置项config SOC_NRF52840boolselect CPU_CORTEX_M_HAS_DWTselect CPU_HAS_FPU...# 显性配置项config SOC_NRF52840_QIAAbool "NRF52840_QIAA"select SOC_NRF52840
而这个SOC_NRF52840_QIAA，是我们选择板子时，52840DK的板子自带的默认配置，来自于
zephyr/samples/application_development/out_of_tree_board/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840_defconfig：
CONFIG_SOC_NRF52840_QIAA=y总结
Zephyr的配置系统是Kconfig定义的菜单。可以用prj.conf之类的文件来修改配置项的值。
Kconfig中的配置项，可以影响CMake中的条件，选择是否添加哪些源码，从而剪裁内核。
Kconfig中的配置项，最终会生成到build/
不要去尝试修改隐性的Kconfig配置项。
DeviceTree和Zephyr驱动模型
device tree比较复杂，具体的语法、使用方法可以参考我的另一篇文章：《详解Zephyr设备树（DeviceTree）与驱动模型》。https://www.cnblogs.com/jayant97/articles/17209392.html
本文中尽量简洁地说明device tree的用途。
设备树文件
device tree的文件是Device Tree Source (DTS)。这里用最简洁的语言描述一下dts文件的产生：
芯片级的dts文件，定义了芯片上的各种外设资源及其地址；
板级的dts文件，可以包含芯片级的dts文件。除了芯片之外，也会包含板子上的资源，如按键、LED、i2c等总线上挂的外设等等；
在工程中选板子时，实际上就是选择了板级的dts文件。在工程中，如果想修改默认的dts，是通过*.overlay文件进行覆盖；例如开发板默认的dts（SDK中的文件）默认没有打开串口1，那么就可以在Overlay文件（你的工程中的文件）中打开串口1；
build target时，所有这些dts会在编译目录下合并成zephyr.dts。这就是最终的dts。
合并dts的位置
NCS v2.7.0引入了sysbuild，zephyr.dts的路径为build/
在NCS v2.6.x之前，zephyr.dts的路径为：build/zephyr/zephyr.dts;
overlay文件
如果说*.conf文件是你当前工程的软件配置，那么*.overlay文件就是你的当前工程的硬件配置。
app.overlay是整个项目的overlay，如果CMake不设置DTC_OVERLAY_FILE,则默认使用app.overlay
boards/
外设的使能与关闭，引脚的分配等与硬件相关的内容，都在dts overlay文件中编写。修改时，注意不要修改SDK里的dts，因为这会影响其他的工程。只在自己的工程内用Overlay修改就好。
// 例如，在overlay中使能串口1. uart1是label，可以直接引用&uart1 {compatible = "nordic,nrf-uarte";status = "okay";}// 另一种写法，不用label，而用绝对路径/{soc{uart@40028000{compatible = "nordic,nrf-uarte";status = "okay";}}}
Zephyr驱动程序
在main()函数运行起来之前，zephyr设备驱动的初始化程序就已经先运行了。设备的驱动程序根据device tree中的配置，自动把外设进行相应的初始化，配置寄存器。然后driver还会提供一个struct device结构体，方便应用层操作这个外设。
程序的application层起来之后，开发者就可以用driver初始化好的device结构体，用标准的Zephyr API进行操作。
有以下5个阶段可以用来初始化外设驱动：
Zephyr外设驱动的整个流程：
【编译阶段】
1. 开发者在Kconfig中，使能了某个外设驱动，如CONFIG_SERIAL=y
2. zephyr/driver/下的CMakeLists.txt，根据CONFIG_SERIAL=y，把zephyr/driver/serial/添加到工程中
3. zephyr/driver/serial/下有各个半导体厂商向Zephyr提交的串口驱动代码。此目录下的CMakeLists.txt根据你的当前Kconfig配置，来选择哪个驱动文件编译进来：
zephyr_library_sources_ifdef(CONFIG_UART_NRFX_UART uart_nrfx_uart.c)if (CONFIG_UART_NRFX_UARTE)if (CONFIG_UART_NRFX_UARTE_LEGACY_SHIM)zephyr_library_sources(uart_nrfx_uarte.c)else()zephyr_library_sources(uart_nrfx_uarte2.c)endif()endif()
4. 驱动代码中，会通过宏来匹配zephyr.dts中的所有串口节点，也就是匹配哪些节点的compatible与当前驱动是一致的。然后，再匹配这些节点的status="okay"，就说明这个外设被使能了，于时就定义一个device结构体实例。
device结构体的定义：
struct device {const char *name; // 设备的名称const void *config; // 设备的初始配置const void *api; // 设备的api函数集合struct device_state *state; // 设备的工作状态void *data; // 设备的运行数据/* ... */ // 其他参数，例如电源管理};
【运行阶段】
1. 系统启动后，在设备驱动程序预设好的阶段（上图5个阶段之一），进行外设的初始化和配置。配置的值就来自于dts overlay中节点的配置。
如果是外挂芯片的驱动，则会在这个阶段完成外挂芯片的配置（如SPI总线的液晶屏、I2C总线的RTC时钟等）。
以上只是两个示例，具体的行为，要看根据驱动程序的代码。
2. 程序进入到应用层之后，所有需要的外设就已经被初始化好了。在应用层代码中，开发者只需先获得这个device结构体的指针，后续调用Zephyr标准外设API时，把这个指针作为参数传入即可。
// 例如，获取串口1的device结构体指针static const struct device *uart1_dev = DEVICE_DT_GET(DT_NODELABEL(uart1));// 使用串口1发送数据uart_tx(uart1_dev, buf, len, timeout);
Zephyr驱动模型的优劣
优点：
代码里调用的都是Zephyr标准API，与硬件细节无关。如果后需要更换MCU平台，几乎没有什么移植成本，只需要更换所选的board即可。
通用性强，无论是普通的串口，还是USB串口，抑或是LPUART，它们的应用层代码均是Zephyr标准API，只需要更换底层驱动即可。
开发者无需花精力在标准、通用的基本功能上，如串口、SPI、网络、按钮等。因为这些驱动都是厂商提供的，在性能、健壮性、功能性上往往都强于开发者自己用寄存器或外设驱动库开发的代码。
缺点：
上手难度稍高，需要花精力去学习语法，并且要简单了解驱动代码
功能不完全。Zephyr只提供最标准的用法，当用到串口、spi、i2c等协议时，就是最标准的协议。一旦有不符合标准的，或者Zephyr标准库未提供的功能，就无法在Zephyr驱动模型的框架下实现了。
例如，nordic的芯片有PPI的功能，可以让一个外设的event触发另一个外设的task。这个功能Zephyr是没有标准驱动的。
Nordic可以在提交给Zephyr的驱动代码中用PPI。例如，在串口驱动中，通过uart外设和timer外设，加上PPI，实现异步流控串口（Timer的作用是记录发送/接收了多少字节，然后用PPI控制GPIO CTS/RTS），Nordic提供的驱动代码，把他们整体封装成串口，也就是说，Zephyr标准驱动操作的串口，实际并不是单独对应uart这一个外设，而是UART+GPIOTE+TIMER+PPI的复合外设。
如果用户想自己用PPI实现一些自定义功能，只能直接调用nrfx api。
Nordic NRFX外设驱动库
如果你的需求比较特殊，想要绕过Zephyr驱动层，直接在底层驱动甚至寄存器和中断的级别来进行开发，NCS也是支持的。
请参考《在NCS中使用NRFX外设驱动库》。
https://www.cnblogs.com/jayant97/articles/17835258.html
总结
dts怎么写，本质上取决于驱动代码里怎么读取dts。dts的本质就是保存硬件细节相关的信息，使自己的应用代码与硬件细节解耦。
要更详细地了解Device Tree，请参考《详解Zephyr设备树（DeviceTree）与驱动模型》。
https://jayant-tang.github.io/jayant97.github.io/2023/03/4b274a50e575/
后半部分将于下期连载，敬请期待
❤️ 感谢伙伴们的热情支持，新的一年，Nordic会带着大家的期待推出更多优秀产品和技术解决方案，增加大家呼声很高的nRF54系列等产品产量，一起加油！
任何产品和技术相关问题，欢迎随时私信Nordic ！
本期获奖名单如下
@iam铭哥、@Figo、@pretty、@kinggate、@文若、@W11、@Dan、@安静、@Lucifer、@Rain、@释怀、@Rabbit米唐、@一两、@如去如来、@小瞌睡虫、@🌙 、@nikkkkk 、@悠悠海
请以上朋友于2月14日前后台私信联系我们，及时领取红包卡券！
中文官网：www.nordicsemi.cn
英文官网：www.nordicsemi.com
微信公众号：nordicsemi
https://devzone.nordicsemi.com
北京分公司: +86 010 8438 2767
上海分公司: +86 21 6330 0620
深圳分公司: +86 755 8322 0147
sales.cn@nordicsemi.no
点击“阅读原文” 探索更多Nordic资讯
