一、认识Zephyr构建系统的基础
很多刚接触Zephyr的朋友，一上来就被它的构建系统给整懵了。其实这东西没那么神秘，说白了就是一个帮你把代码编译成能跑在嵌入式设备上的“搬运工”。Zephyr用的是CMake加上一套叫Kconfig的配置工具，这两兄弟配合起来，让你能像搭积木一样，需要什么功能就开启什么功能。
1.1 为什么我们要自己动手配置
默认的Zephyr配置就像厂家给的“标准套餐”，能满足大多数情况。但实际做项目时，你的硬件可能只有一个LED，一张小屏幕，或者需要节省内存跑复杂的算法。这时候就得自己动手改配置。比如默认开启了很多调试日志，这会占用不少Flash空间；或者某个驱动默认没开启，你得手动加上。自定义配置就是让你从“标准套餐”变成“自定义定制”，只保留你需要的，扔掉没用的。
二、那些你必须掌握的核心配置文件
Zephyr的配置主要藏在这几个地方：prj.conf、board.h、CMakeLists.txt，以及里面各种Kconfig文件。咱们先看最常见的prj.conf。
2.1 prj.conf——你的配置“菜单”
prj.conf就是一个纯文本文件，每一行是一条配置项。比如你想开启UART0并且设置波特率，可以这么写：
# 技术栈：CMake / Kconfig (在prj.conf中使用的语法)
# 开启UART0驱动
CONFIG_UART_0=y
# 设置波特率为115200
CONFIG_UART_0_BAUD_RATE=115200
# 开启串口中断
CONFIG_UART_0_INTERRUPT=y
注意，prj.conf里写的配置项名字都是 CONFIG_ 开头。如果你不确定某个配置叫什么，可以去 zephyr/Kconfig 里翻一翻，或者用 west build -t menuconfig 打开图形界面查看。
2.2 用Kconfig实现更灵活的配置
有时候你希望自己有多个配置方案，比如“开发版配置”和“量产版配置”。Zephyr允许你在CMakeLists.txt里根据条件引入不同的配置文件。来看个例子：
# 技术栈：CMake
# 在CMakeLists.txt中根据变量选择不同配置文件
if(CONFIG_BOARD_DEVELOPMENT)
# 开发版使用调试更丰富的配置
set(CONF_FILE "prj_dev.conf")
else()
# 量产版使用精简配置
set(CONF_FILE "prj_prod.conf")
endif()
# 将这个变量传递给构建系统
zephyr_compile_definitions(CONF_FILE="${CONF_FILE}")
这里有一点要注意：CONF_FILE 这个变量是Zephyr构建系统内部使用的，你直接设成目标名字即可。在项目根目录下放两个文件 prj_dev.conf 和 prj_prod.conf，然后在构建时通过 west build -b board_name -- -DCONFIG_BOARD_DEVELOPMENT=y 来切换。
三、深入到CMake里做定制
除了修改配置项，你还可以直接动CMake脚本，对编译过程做更精细的控制。比如添加自己的源文件、增加编译参数、链接静态库等。
3.1 添加自定义源文件和库
假设你有一个自己写的驱动库 libmy_driver.a，你想把它集成到Zephyr里。在应用层的CMakeLists.txt里这样做：
# 技术栈：CMake
# 添加自定义库路径
target_link_directories(my_app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/libs)
# 链接静态库
target_link_libraries(my_app PRIVATE my_driver)
# 添加头文件搜索路径
target_include_directories(my_app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/include)
# 编译选项：开启更激进的优化，同时减小代码尺寸
target_compile_options(my_app PRIVATE -Os -fno-unwind-tables -fno-asynchronous-unwind-tables)
注意，这里的 my_app 是你应用的目标名。默认情况下，Zephyr应用的目标名就是你的项目文件夹名字。你可以通过 west build -t target_name 查看。
3.2 使用west工具的参数传递
west 是Zephyr的官方构建助手，它可以把参数直接传给底层的CMake。比如你想调试内存使用，可以这样：
# 技术栈：Shell
# 编译并开启内存统计
west build -b sam4s_xplained -- -DCONFIG_HEAP_MEM_POOL_SIZE=8192 -DCONFIG_STACK_USAGE=y -DCONFIG_FPU=y
这些参数最终会变成CMake的变量，然后写入配置。用这个方法，你甚至能在构建时临时修改配置，而不修改prj.conf。适合做快速实验。
四、常见应用场景与动手实践
下面三个场景是平时做项目时最容易遇到的，我带你一步一步操作。
4.1 场景一：给特定硬件调整栈大小
在裸机开发中，任务栈大小是个头疼的问题。Zephyr里主线程的栈大小默认是2KB，如果你的任务用到大量局部变量，就会栈溢出。可以这样做：
- 在prj.conf里添加：
# 技术栈：Kconfig (prj.conf)
# 将主线程栈扩大到8KB
CONFIG_MAIN_STACK_SIZE=8192
# 如果使用了独立的任务线程，单独设置
CONFIG_STACK_SIZE_PRIORITY_HIGH=4096
- 或者，在CMakeLists.txt里动态调整：
# 技术栈：CMake
# 根据板子类型自动调整栈大小
if(BOARD STREQUAL "nrf52840dk_nrf52840")
# nRF52840内存多，可以给大一点
set(CONFIG_MAIN_STACK_SIZE 16384 CACHE INTERNAL "")
elseif(BOARD STREQUAL "stm32f4_disco")
# STM32F4内存有限，用保守值
set(CONFIG_MAIN_STACK_SIZE 4096 CACHE INTERNAL "")
endif()
注意，直接set CMake变量不会生效，因为配置系统最终由Kconfig管理。你需要用 CACHE 这个关键字来覆盖配置。更稳妥的做法是写一个自定义的Kconfig片段，不过为简单起见，我建议通过prj.conf配合 BOARD 宏来控制。
4.2 场景二：添加自定义驱动或库
假设你买了个温度传感器，Zephyr官方没有驱动。你写了自己的 my_temp.c 和 my_temp.h，想让它成为Zephyr系统的一部分。
首先，在应用目录下创建文件夹 drivers，里面放你的驱动文件。然后在应用的CMakeLists.txt里：
# 技术栈：CMake
# 将驱动文件编译为对象并链接
target_sources(my_app PRIVATE
${CMAKE_CURRENT_SOURCE_DIR}/drivers/my_temp.c
)
# 如果你希望驱动能通过Kconfig开关，可以创建一个Kconfig文件
# 然后在CMakeLists.txt里引入
include(${CMAKE_CURRENT_SOURCE_DIR}/Kconfig.my_modules)
接下来创建 Kconfig.my_modules 文件：
# 技术栈：Kconfig (自定义Kconfig片段)
menu "My Custom Drivers"
config MY_TEMP_SENSOR
bool "Enable my custom temperature sensor"
default n
help
Say y to enable the custom temperature sensor driver.
endmenu
然后在CMakeLists.txt中根据配置条件编译：
# 技术栈：CMake
if(CONFIG_MY_TEMP_SENSOR)
target_sources(my_app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/drivers/my_temp.c)
endif()
这样你就可以通过prj.conf里的 CONFIG_MY_TEMP_SENSOR=y 来控制是否启用这个驱动，非常灵活。
4.3 场景三：优化构建速度与内存使用
构建大型Zephyr项目时，编译时间可能很长。有两个技巧可以大幅提速：
- 使用ccache：在你的CMakeLists.txt开头加上：
# 技术栈：CMake
# 启用ccache加速二次编译
find_program(CCACHE_PROGRAM ccache)
if(CCACHE_PROGRAM)
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "${CCACHE_PROGRAM}")
endif()
- 只编译修改的部分：Zephyr的构建系统已经支持增量编译，但前提是你不要每次都
west build --clean。用west build -t clean清理某个模块更高效。
内存方面，关闭不必要的日志和调试信息能省下不少Flash：
# 技术栈：Kconfig (prj.conf)
# 关闭所有日志输出
CONFIG_LOG=n
# 关闭Shell
CONFIG_SHELL=n
# 关闭断言
CONFIG_ASSERT=n
# 技术栈：CMake (可选)
# 在CMake中全局禁用调试打印
add_compile_definitions(NDEBUG)
五、自定义配置的优缺点
优点：
- 精确控制：只编译你需要的功能，体积和性能都得到优化。
- 模块化：可以轻松添加第三方库或自定义驱动，且不影响其他部分。
- 可复用：一套配置可以在不同板子上用条件判断切换，维护成本低。
缺点：
- 学习曲线：Kconfig语法和CMake的结合需要一些时间掌握。
- 调试困难：如果配置冲突，错误信息可能不直观，需要查看生成的
.config文件。 - 过度定制可能导致迁移麻烦：如果以后升级Zephyr版本，自定义的Kconfig片段可能需要适配新API。
六、注意事项与踩坑记录
- 配置项前后依赖：比如你开启了
CONFIG_USB，但未开启CONFIG_USB_DEVICE_STACK，USB功能可能不完整。建议每次修改后运行west build -t menuconfig可视化检查依赖。 - 变量作用域：在CMakeLists.txt中直接用
set(CONFIG_XXX y)有时不生效，因为Kconfig会在后面覆盖。正确做法是用CACHE INTERNAL或者通过prj.conf配置。 - 避免修改Zephyr源码：永远别改
zephyr/目录下的文件，否则升级版本时你会很痛苦。自定义文件都放在应用目录下，通过CMake引入。 - 使用
west build -- -DOVERLAY_CONFIG=my_overlay.conf：如果你不想修改prj.conf，可以用overlay文件覆盖配置，适合多个变体项目。 - 内存对齐问题：如果你在自定义配置里开启了某些硬件加速器，要注意堆栈对齐。Zephyr默认使用4字节对齐，某些加速器需要8字节，这时要设置
CONFIG_STACK_ALIGNMENT=8。
七、总结
Zephyr的构建系统其实不复杂，核心就是prj.conf和CMakeLists.txt两个文件。你只需要记住：prj.conf负责告诉系统“我要什么功能”，CMakeLists.txt负责“怎么把这些功能组织和编译起来”。通过上面讲的那些技巧，你可以根据项目需求像搭积木一样，自由组合配置。刚开始可能觉得繁琐，但用顺手之后，你会发现它比很多传统嵌入式构建系统都要强大和灵活。下次遇到内存不够或者编译太慢的问题，别慌，试着从配置入手，往往能迎刃而解。
Comments