STM32F407移植Zephyr：设备树配置与定时器触发DAC实战

当年我从 Keil 切到 Zephyr 的时候，第一反应是“这也太复杂了吧”。一个简单的串口打印，FreeRTOS 工程里配个库调用就行，Zephyr 里要折腾 west、SDK、设备树、Kconfig，还没跑通就先被工具链劝退。但等我把整个流程走通之后，回头看这一步特别值：Zephyr 不是另一个嵌入式实时内核，它是一整套嵌入式操作系统生态。你花在设备树和构建系统上的时间，会在后续驱动开发、多板卡维护、协议栈集成的时候加倍赚回来。

这篇文章记录的就是我基于一块淘宝常见的 STM32F407VET6 最小系统板，从零把 Zephyr 3.7 LTS 跑起来，并完成串口、GPIO、DAC 定时触发输出的完整过程。重点是设备树配置，因为这是 Zephyr 和传统 STM32 开发之间最大的一道坎。文章里没有任何需要特定高价开发板的内容，适合手里有一块 F4 板子、想尽快上手 Zephyr 的嵌入式工程师参考。我会把关键命令、完整配置和踩过的坑都摆出来，你照着走一遍，基本能少走两周弯路。

1. 移植前先把思路换过来：Zephyr 到底在做什么

1.1 先澄清一个误区：Zephyr 不是 FreeRTOS 的“替代品”

很多朋友第一次接触 Zephyr，是抱着“FreeRTOS 用腻了，换个内核”的心态来的。这个出发点会害了你。FreeRTOS 本质是一个内核库，你把它源码加进自己的工程，用它提供的 API 创建任务、消息队列、信号量，剩下的事情比如引脚初始化、外设驱动、构建脚本，全部由你的工程自己负责。Zephyr 不一样，它对自己的定位是“适用于资源受限设备的操作系统”，内核调度只是它的一小块。

具体到开发模式的差异，用一句话概括：FreeRTOS 是“把内核嫁接到你的工程里”，Zephyr 是“把你的板卡嫁接到 Zephyr 生态里”。后者意味着你写的应用代码要跑在 Zephyr 的驱动模型上，板级硬件要用设备树来描述，编译配置要用 Kconfig 来控制。刚开始这套流程确实繁琐，但它换来的好处是，驱动接口在不同 SoC 之间保持统一，你给 STM32F4 写的应用层代码，换到 nRF52840 或者 ESP32 上，硬件相关部分只需要改设备树，驱动 API 几乎不用动。这是量级上的区别，不是“换一个调度器而已”。

1.2 STM32F4 在 Zephyr 生态里的支持现状

Zephyr 对 STM32F4 系列的支持已经相当成熟，官方仓库里的 boards/arm 目录下能找到 nucleo_f411re、stm32f4_disco、olimex_stm32_h405 等一批官方板卡。但国内工程师手里最多的其实是那种几十块钱的 F407VET6/F407ZGT6 最小系统板，这种板子官方没有提供现成 board 定义。这反而是一件好事，因为你刚好可以借此学会“自己给板子在 Zephyr 里建立户口”，等课程结束后，哪怕换一块完全冷门的国产 ARM 芯片，也知道该从哪里下手。

硬件方面，F407VET6 有 512KB Flash、128KB RAM，主频可以跑到 168MHz，外设也很全，UART、SPI、I2C、DAC、FSMC 都有，拿来做 Zephyr 学习板算是非常舒服的组合。Zephyr 对 STM32F407 的 SoC 级支持集中在 soc/st/stm32/stm32f4 下面，它会定义中断控制器、时钟树、默认内存布局，再往上是 stm32f407.dtsi 这类设备树 include 文件，描述芯片内部所有外设节点。板级支持要做的事情，就是把“芯片内部有哪些外设”和“你板子上实际接了哪些外设”关联起来。

1.3 移植前需要备好的三样东西

我用的开发环境是 Ubuntu 22.04 虚拟机，8GB 内存，编译 Zephyr 和应用工程绰绰有余。第一样东西是 Python 环境和 west，west 是 Zephyr 的元工具，负责拉取源码、管理多仓库、构建和烧录。第二样是 Zephyr SDK，里面包含了针对各种架构的交叉编译工具链、OpenOCD 等调试烧录工具，装一次全架构都齐了，比你在 Linux 下手动配 arm-none-eabi-gcc 省事得多。第三样是一块能正常工作的 STM32F407 板子和一个调试器，ST-Link V2 淘宝二十块就能买到，OpenOCD 对它支持很完善。

整个环境搭建我建议按官方文档来，大致命令如下：

pip install west west init zephyrproject cd zephyrproject west update west zephyr-export pip install -r zephyr/scripts/requirements.txt

Zephyr SDK 从官方 GitHub 下载 .tar.gz 解压到 /opt 目录，然后在 ~/.zephyrrc 里设置 ZEPHYR_SDK_INSTALL_DIR 指向它。这里我要多说一句，安装完成后先别急着写代码，用 west build -b nucleo_f411re 随便编一个 samples/hello_world，确认工具链和构建系统真的能跑通，再开始折腾板卡移植。否则你后面遇到编译报错，就分不清是环境问题还是自己的代码问题。

2. 新建自己的 board：让 Zephyr 认识你的 F407 板子

2.1 board 定义由哪些文件构成

Zephyr 里“板卡”不是一个抽象概念，它就是 boards/arm/ 下的一个目录。官方给每块板子建了一个目录，里面有 board.dts、board_defconfig、Kconfig.board、Kconfig.defconfig、board.cmake 和 CMakeLists.txt 这几个核心文件。我在自己的 zephyr 源码目录下新建了 boards/arm/black_f407ve，目录名就是板卡名，后面所有 west build -b 参数都跟这个名字走。

这几个文件的分工我理解了很久才彻底理顺。board.dts 是设备树源文件，描述板级硬件：LED 接在哪个引脚、串口用的是哪个 USART、外部晶振频率是多少，全在这里声明。board_defconfig 是默认的 Kconfig 配置，比如选择哪个 SoC、是否需要开启浮点单元。Kconfig.board 和 Kconfig.defconfig 配合使用，让 Kconfig 系统能识别出“存在这么一块板卡”。board.cmake 负责告诉 Zephyr 烧录时用哪个 runner，是 OpenOCD 还是 JLink。CMakeLists.txt 就一行，把上述文件组织起来。刚接触的时候别被文件数量吓到，最直接的办法是把官方某块 F4 板子的目录整个复制过来，然后一项一项改成自己板卡的实际情况。

2.2 板级设备树如何引用 SoC 的描述

打开任何一块 STM32F4 官方板卡的 board.dts，第一眼看到的就是一堆 #include。这个结构指向 Zephyr 设备树的组织逻辑：SoC 级别的描述在 dts/arm/st/stm32f4/ 下，板级描述只需要 include 进来，然后追加自己的差异。以 F407VET6 为例，文件头部会这样写：

/dts-v1/; #include <st/stm32/stm32f407.dtsi> #include <zephyr/dt-bindings/gpio/gpio.h> #include <zephyr/dt-bindings/input/input-event-codes.h> #include <zephyr/dt-bindings/pwm/pwm.h>

stm32f407.dtsi 里已经定义好了芯片内部的 flash0、sram0、GPIOA 到 GPIOE、USART1 到 USART6、DAC1、定时器等一堆节点。比如 stm32f407.dtsi 里有类似这样的定义：“GPIOA 的基地址是 0x40020000，时钟门控在 RCC 的 AHB1ENR 第 0 位，支持的中断号是多少”，这些信息在传统裸机开发里要靠查阅参考手册逐个确认，在 Zephyr 里 SoC 级文件都给你写好了。板级要做的，是在 dts 文件的根节点里放置 chosen 节点，告诉系统控制台用哪个串口、内存布局选哪段：

/ { model = "Black F407VE Board"; compatible = "black,f407ve"; chosen { zephyr,console = &usart1; zephyr,shell-uart = &usart1; zephyr,sram = &sram0; zephyr,flash = &flash0; }; };

compatible 这个属性特别重要，它规定了这块板卡对外宣称的“身份”，以后如果有应用代码要判断当前运行的硬件，就是靠它来识别。model 字段纯描述性，写什么都行。

2.3 引脚复用和 pinctrl 是移植的重头戏

STM32 的引脚大多有复用功能，PA9 既可以是普通 GPIO，也可以是 USART1_TX，还可能是 USB 的某个信号。裸机开发里你直接在库函数里配置 AF 编号，Zephyr 则要求在设备树里用 pinctrl 节点描述这种复用关系。Zephyr 从 2.5 版本开始，把 STM32 的引脚配置完全切到了 pinctrl 机制上，不再支持旧的 pinmux 写法，所以这部分必须掌握。

我参考官方板卡的做法，在 board 目录下建了一个 black_f407ve-pinctrl.dtsi，专门存放板级引脚复用定义：

#include <dt-bindings/pinctrl/stm32f4-pinctrl.h> &pinctrl { usart1_tx_pa9: usart1_tx_pa9 { pinmux = <STM32_PINMUX('A', 9, AF7)>; }; usart1_rx_pa10: usart1_rx_pa10 { pinmux = <STM32_PINMUX('A', 10, AF7)>; }; };

STM32_PINMUX('A', 9, AF7) 这个宏展开了就是端口、引脚号、复用功能编号的组合。AF 编号不是随便填的，需要查 STM32F407 数据手册里的“Alternate function mapping”表，PA9 和 PA10 的 USART1 功能对应 AF7，这些信息在 ST 官方文档里都有，Zephyr 没有替你封装这一层，因为它依赖具体芯片型号。

在 board.dts 中启用 USART1 的时候，把 pinctrl 节点关联进去：

&usart1 { pinctrl-0 = <&usart1_tx_pa9 &usart1_rx_pa10>; pinctrl-names = "default"; current-speed = <115200>; status = "okay"; };

pinctrl-names 定义状态名，驱动在设备进入 default 状态时自动应用这组引脚配置。注意，pinctrl 节点放在 &pinctrl 下面，说明它们是属于 pinctrl 控制器这个父节点的一部分，这是设备树里常见的父子关系写法。

2.4 board_defconfig 和 Kconfig 让板卡可以被选中

完成板级设备树之后，还要让构建系统知道“black_f407ve 这块板子用了什么芯片、有哪些默认配置”。我的 board_defconfig 内容相当精简：

CONFIG_SOC_STM32F407XE=y CONFIG_BOARD_BLACK_F407VE=y

CONFIG_SOC_STM32F407XE 选中具体的 SoC 型号，构建系统会根据它去加载对应的 SoC 级 Kconfig 和 dtsi。这里 F407VET6 对应的是 XE 这个 Flash/RAM 密度标识，如果你的板子是 F407ZGT6，那就应该是 STM32F407XG。这个细节很容易踩坑，选错了虽然也能编译，但内存布局和 Flash 大小会不匹配。

Kconfig.defconfig 里通常会有一段：

if BOARD_BLACK_F407VE config BOARD default "black_f407ve" endif

它的作用是当用户执行 west build -b black_f407ve 时，Kconfig 系统能把 BOARD 变量解析成这个字符串，进而在构建脚本里定位到 boards/arm/black_f407ve 目录。Kconfig.board 文件里只有一行 menuconfig BOARD_BLACK_F407VE，表示这个板卡选项存在。这两步做完，你的板卡就正式进入 Zephyr 支持名单了。

3. 设备树配置详解：从点灯到串口日志

3.1 用设备树描述 LED 和 GPIO，告别魔法数字

很多第一次接触 Zephyr 的人最不习惯的一点是，GPIO 操作不再有 HAL_GPIO_WritePin(GPIOE, GPIO_PIN_1, ...) 这种直接指定引脚号的代码。取而代之的是，你先在设备树里声明“这个板子上有一个 LED，它接在 PE1 上，低电平点亮”，然后在 C 代码里通过 dt 宏拿到这个 LED 的“句柄”。这一步到底有什么意义？举一个场景你就明白了：项目从 F407VET6 换到 F411RE，裸机代码里所有 GPIOE、GPIO_PIN_1 都要全局搜索替换，Zephyr 这边只需要改设备树，C 代码一行不动。

我的 board.dts 里加了这样一段：

/ { leds { compatible = "gpio-leds"; led0: led_0 { gpios = <&gpioe 1 GPIO_ACTIVE_LOW>; }; }; };

然后在应用里用 DT_ALIAS 或者 DT_NODELABEL 引用它。我习惯在根节点的 aliases 子节点里加一句：

aliases { led0 = &led0; };

这样在主程序里可以用 DT_ALIAS 宏：

#include <zephyr/kernel.h> #include <zephyr/drivers/gpio.h> #include <zephyr/dt-bindings/gpio/gpio.h> #define LED0_NODE DT_ALIAS(led0) void main(void) { const struct device *dev = DEVICE_DT_GET(DT_GPIO_CTLR(LED0_NODE, gpios)); gpio_pin_configure(dev, DT_GPIO_PIN(LED0_NODE, gpios), GPIO_OUTPUT | DT_GPIO_FLAGS(LED0_NODE, gpios)); gpio_pin_set(dev, DT_GPIO_PIN(LED0_NODE, gpios), 0); }

注意 gpios = <&gpioe 1 GPIO_ACTIVE_LOW> 里 GPIO_ACTIVE_LOW 会被编译进设备树生成的宏里，DT_GPIO_FLAGS 取出来之后直接传给 gpio_pin_configure。为什么要把电平极性交给设备树？因为不同板子 LED 接法不一样，有的是高电平点亮，有的是低电平点亮，应用代码不关心这些，设备树把硬件差异隔离掉了。

3.2 串口配置背后的 pinctrl 机制

串口是嵌入式开发的基础设施，Zephyr 的日志、shell、调试输出都依赖它。我在这块板子上用的 USART1，PA9/PA10 分别是 TX/RX。板级 pinctrl 定义和 USART1 节点的配置我在 2.3 节已经给出了完整代码，这里补充几个容易出问题的地方。

第一，pinctrl-0 顺序没有硬性要求，但建议和原理图上引脚排列保持一致，方便排查。第二，current-speed 决定了 UART 波特率，Zephyr 的 uart 驱动会在初始化时按这个属性配置时钟分频，所以如果板载晶振频率配置错了，串口会输出乱码，这一点后面讲时钟树会重点说。第三，如果你的板子上 USART1 被调试器占用，或者你用了 USB 转串口芯片，要注意原理图上 TX/RX 是否交叉，硬件接反了设备树再怎么配都没用。

配置完成后，在应用里使用 printk 或者更现代的 LOG 模块，输出就会自动从串口出来。Zephyr 默认把 console 绑定到 zephyr,console 指向的串口设备，前面 chosen 节点里我已经把 USART1 指定为 console，所以 printk 的内容会直接送到 USART1。

3.3 时钟树配置：168MHz 是怎么算出来的

STM32F4 的时钟树在裸机开发里就是老大难，PLL 配置错一位，外设频率全乱。到了 Zephyr 里，时钟配置从代码挪到了设备树。官方 STM32F4 板卡通常默认使用内部 HSI 或者外部 HSE。我这块最小系统板板载 8MHz 晶振，所以要在 board.dts 里这样配置：

&clk_hse { hse-bypass; clock-frequency = <8000000>; status = "okay"; }; &pll { div-m = <8>; mul-n = <336>; div-p = <2>; div-q = <7>; clocks = <&clk_hse>; status = "okay"; }; &rcc { clocks = <&pll>; clock-frequency = <DT_FREQ_M(168)>; ahb-prescaler = <1>; apb1-prescaler = <4>; apb2-prescaler = <2>; };

这些参数的含义对应 STM32F4 的 PLL 计算公式：VCO 输入频率 = HSE / div-m，这里 8MHz / 8 = 1MHz，VCO 输出 = 1MHz * 336 = 336MHz，系统时钟 = VCO / div-p = 336 / 2 = 168MHz。div-q 专供 USB OTG，需要 48MHz，所以 336 / 7 = 48MHz。这里的每一个数字都能算回去，我强烈建议你对着参考手册 RCC 章节自己验算一遍，感觉完全不一样。

APB1 预分频 4，得到 42MHz，这是 UART、I2C、DAC 等低速外设的总线时钟。APB2 预分频 2，得到 84MHz，这是 USART1、SPI1、ADC 的时钟。注意 STM32F4 的定时器时钟比较特殊，当 APB1 预分频不等于 1 时，定时器时钟是 APB1 的两倍，也就是说挂在 APB1 上的 TIM6 实际时钟是 84MHz。后面做 DAC 定时触发时，这个数字会直接用到。

3.4 overlay 机制：不改 board 也能改硬件描述

实际开发中经常遇到这种情况：同一块板子，某个项目把 USART3 用作了调试串口，另一个项目想用 USART6。如果每次都去改 board.dts，板卡目录变得一团糟，而且多人协作时改动容易冲突。Zephyr 提供的解决方案是 overlay 文件，也就是运行时叠加在 board.dts 之上的额外设备树片段。

用法非常简单，在应用目录下建一个 xxx.overlay，里面写：

&usart3 { pinctrl-0 = <&usart3_tx_pd8 &usart3_rx_pd9>; pinctrl-names = "default"; current-speed = <115200>; status = "okay"; };

构建时通过参数指定：

west build -d build -b black_f407ve app -- -DEXTRA_DTC_OVERLAY_FILE=app.overlay

设备树的加载顺序是 SoC dtsi、board.dts、overlay，后面的节点会覆盖前面同名节点。overlay 里可以对某个外设节点追加属性，比如把 console 换掉：

&usart3 { status = "okay"; };

但要注意，如果 board.dts 里已经把 USART3 status 设为 disabled，overlay 里改成 okay 之后，还要检查时钟和引脚是否使能。我在实际项目里最常犯的错是，把引脚复用写在了 overlay 里，却忘了在 board.dts 的 &pinctrl 节点里补上对应的 pinctrl 子节点，结果编译时提示找不到节点引用。overlay 并不是独立的设备树世界，它只能引用 board.dts 中已存在的节点或自己新增的节点，这一点需要牢记。

4. 构建与烧录：让第一份日志从串口出来

4.1 west build 和 Kconfig 裁剪

板卡目录建好之后，第一个可以直接验证移植成果的应用当然是 hello_world。我在 zephyrproject 外面单独建了一个 app 目录，里面放了自己的 CMakeLists.txt、prj.conf 和 src/main.c。

cmake_minimum_required(VERSION 3.20.0) find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE}) project(black_f407_hello) target_sources(app PRIVATE src/main.c)

prj.conf 里最简单的配置只需要开启控制台和串口：

CONFIG_PRINTK=y CONFIG_UART_CONSOLE=y

Zephyr 默认对很多产品级功能都是关闭的，比如网络、蓝牙、文件系统，好处是空工程编译出来非常小。但这也带来一个问题，如果你在 prj.conf 里写了一个 CONFIG_XXX=y，编译后却没有生效，不要着急，用 menuconfig 打开图形化配置界面搜索这个选项，多半会发现它被某个依赖条件屏蔽了。比如你直接写 CONFIG_USB=y，但没选 USB 设备控制器驱动，这个配置会被静默忽略。Kconfig 的依赖体系比预编译宏复杂，养成用 menuconfig 确认的习惯会省很多时间。

构建命令很简单：

cd zephyrproject west build -b black_f407ve ../app

第一次构建会生成 build 目录，里面会有一堆相关文件。最关键的是 build/zephyr/zephyr.dts，这个文件是把 SoC dtsi、board.dts、overlay 全部合并、展开宏之后生成的最终设备树，写入的所有状态、地址、中断号都能在里面看到。每次设备树配置和对不上的时候，第一件事就是打开这个文件核对。

4.2 烧录方式选择和 board.cmake

设备树和代码都准备好之后，烧录这块板子也有讲究。F407VET6 可以从系统 Flash 启动，也可以用 ST-Link 通过 SWD 接口烧录。我在 board.cmake 里配置的是 OpenOCD runner：

include(${ZEPHYR_BASE}/boards/common/openocd.board.cmake)

如果你的调试器是 J-Link，那就改成：

include(${ZEPHYR_BASE}/boards/common/jlink.board.cmake)

烧录命令是：

west flash -d build -r openocd

OpenOCD 自动识别 F407，把生成的 zephyr.elf 烧进去，然后复位运行。如果没有 ST-Link，也可以先让板子进入系统 Bootloader，用串口 DFU 方式烧录，但那样每次都要手动跳 Boot0，体验差一些。调试器还是建议备一个，后面排查 HardFault 的时候，OpenOCD 的 GDB 会话是最直接的诊断工具。

第一次运行 hello_world，串口上应该输出类似这样的日志：

*** Booting Zephyr OS build v3.7.0 *** Hello World! black_f407ve

如果只看到启动横幅，没有后一行，大概率是 main 函数没有正常执行，检查一下 prj.conf 是否开启了必要的配置。如果连横幅都没有，先确认 USB 转串口模块的 TX/RX 是否接反。

4.3 理解构建产物：zephyr.dts 和 .config

构建目录里最有价值的两个文件，一个是 zephyr.dts，一个是 .config。zephyr.dts 是设备树的最终形态，相当于把你在 board.dts 和 overlay 里写的“浓缩咖啡”冲成了“美式”，所有宏展开、所有默认值补齐之后，一目了然。比如你怀疑某个外设没被使能，打开 zephyr.dts 搜一下 status，如果结果显示 disabled，那问题一定出在 dts 配置上，而不是代码逻辑。

.config 是 Kconfig 的最终结算结果，里面记录了所有被选中的配置项。我调试驱动的时候经常干一件事：把 .config 里的 CONFIG_ 项和源码里的 #ifdef 宏对照着看，能很快定位某个功能代码是否被编译进去。还有一个实用技巧，west build -t menuconfig 可以让你在图形界面里实时修改配置，保存后重新编译，比手动改 prj.conf 效率高不少。

5. 实战扩展：用定时器触发 DAC 输出波形

5.1 Zephyr 的 DAC 驱动模型

串口和点灯跑通之后，Zephyr 的基础流程算是摸清了。但嵌入式开发终究要面对外设，这里我挑一个稍有点难度、又非常能体现“设备树 + 驱动”思维的外设：DAC。STM32F407 内部有两个 12 位 DAC 通道，可以输出电压波形。Zephyr 对 DAC 的抽象在 drivers/dac.h 里，应用层只需要关心几个 API：dac_channel_setup 配置通道、dac_write_value 写入转换值。

设备树层面对应的节点是 dac1。因为 F407 的 DAC 输出引脚是固定的，PA4 对应通道 1，PA5 对应通道 2，不需要 pinctrl 配置，但需要在 board.dts 或者 overlay 里显式使能：

&dac1 { status = "okay"; };

注意，这里我说的是板级使能。SoC dtsi 里 dac1 默认是 disabled 的，没有板级代码打开它，驱动就不会初始化。Zephyr 驱动初始化采用的是“设备树驱动匹配”机制，只有 status = "okay" 的节点才会被系统自动实例化，这个规则对所有外设都适用。

5.2 在 Zephyr 中让 TIM6 触发 DAC 的完整做法

Zephyr 自带的 DAC API 只提供“写值”的能力，DAC 转换的触发时机通常是软件触发，也就是调用 dac_write_value 后立即转换。但很多实际场景需要 DAC 以固定的时间间隔自动输出数据，比如生成正弦波、音频信号，这时候就要让 DAC 由 TIM6 这类基本定时器的更新事件来触发。Zephyr 的 DAC 驱动没有提供触发源配置接口，这意味着我们要在应用层直接操作 STM32 LL 库或者寄存器。

我是这么做的。先用 LL 库配置 TIM6，让它输出更新事件作为触发源：

#include <stm32_ll_tim.h> #define TIM6_CLOCK_HZ 84000000 #define DAC_SAMPLE_HZ 1000 void tim6_dac_trigger_init(void) { uint32_t prescaler = TIM6_CLOCK_HZ / (DAC_SAMPLE_HZ * 500) - 1; LL_TIM_SetPrescaler(TIM6, prescaler); LL_TIM_SetAutoReload(TIM6, 499); LL_TIM_SetTriggerOutput(TIM6, LL_TIM_TRGO_UPDATE); LL_TIM_EnableCounter(TIM6); }

这里有几个数字要解释清楚。前面时钟树部分说过，虽然 APB1 是 42MHz，但因为预分频不为 1，定时器时钟实际是 42MHz * 2 = 84MHz。我希望 DAC 每秒输出 1000 个点，也就是采样率 1kHz，那么定时器溢出频率是 1000Hz。预分频设为 167，计数频率就变成 84MHz / 168 = 500kHz，自动重载值设为 499，最终溢出频率 500kHz / 500 = 1kHz。这套计算方式跟裸机开发完全一致，核心区别只是它不通过 HAL 库的句柄初始化。

接着配置 DAC 的触发源。STM32F407 参考手册里，DAC_CR 寄存器的 TSEL1 位段选择触发源，000 代表 TIM6 TRGO，TEN1 位置 1 使能触发。直接用寄存器操作：

DAC1->CR &= ~DAC_CR_TSEL1; DAC1->CR |= DAC_CR_TEN1;

Zephyr 驱动初始化之后，DAC1 的外设时钟已经打开，所以应用层直接访问寄存器是安全的。但要注意时序，必须等驱动完成初始化，也就是在 main 里先调用 dac_channel_setup，再修改这些寄存器，否则可能把驱动内部状态搞乱。

5.3 把外设金字塔拆解成 API、驱动、寄存器三层

做完定时器触发 DAC 这个功能，我对 Zephyr 外设架构的理解清晰了很多。顶层是应用代码能看到的统一 API，比如 dac_write_value、gpio_pin_set、uart_poll_out，不管底层是什么芯片，接口不变。中间层是 Zephyr 自带的驱动文件，比如 dac_stm32.c、gpio_stm32.c，它们负责根据设备树节点的寄存器地址、时钟信息初始化硬件，并实现 API 函数。最底层是 STM32 的寄存器或者 LL/HAL 库。

Zephyr 定位的“可移植性”并不是把 STM32 的寄存器全藏起来，而是通过设备树把硬件信息参数化，驱动代码里不出现具体地址和引脚号。当你需要做超出驱动 API 覆盖范围的操作，比如配置定时器触发 DAC，直接访问寄存器完全不违背 Zephyr 的理念，它甚至为你保留了 stm32_ll_tim.h 这样的 HAL 头文件。这是我在实现过程中最深刻的体会：学会 Zephyr 的标准用法只是第一步，理解每一层为什么这样设计，才能真正在它之上做出有创造力的东西。

6. 移植过程中的高频问题排查实录

6.1 问题速查表

我在做这块板子移植时，前后折腾了不少时间，很多问题在社区里也是反复被问到。整理了一个表格，基本覆盖了最常见的故障场景。

表格里的很多问题，根源都能在设备树里找到。所以每次出问题，我第一个动作永远是打开 zephyr.dts，搜索对应的外设节点，确认节点是否存在、status 是否为 okay、pinctrl 是否完整。设备树就是一个“硬件配置真相表”，它把玄学问题变成了可查证的问题。

6.2 几个值得写入习惯的避坑技巧

先说复制官方板卡这个习惯。从空白文件开始新建板卡定义非常容易漏东西，我从 stm32f4_disco 的目录复制过来，把 MCU 型号、LED 引脚、串口号改成自己的，一次就通过了构建。官方板卡文件经过了大量验证，是 Zephyr 设备树写法的“标准答案”，比看文档效率高得多。

再说构建目录。Zephyr 的增量构建偶尔会出现“改了 dts 但没反应”的情况，尤其是你改了 include 文件或者 overlay 文件路径的时候。我的经验是，改完设备树相关文件后，如果发现行为没变化，直接删掉 build 目录重新构建。反正 Zephyr 构建速度在 PC 上也就几十秒，没必要为增量构建那点时间省出玄学问题。

最后是关于阅读官方驱动代码。Zephyr 的 drivers 目录里的代码质量很高，注释也比较全。遇到 API 行为不符合预期的时候，直接去读对应驱动源码，比如 dac_stm32.c 里 dac_stm32_channel_setup 做了什么、什么时候启用 DMA、什么时候配置触发源，比在社区发帖等回复快得多。Zephyr 的开发模式决定了它不可能把所有外设功能都通过 API 暴露出来，理解驱动层的实现方式，才是自由扩展的底气。

这套移植流程走下来，我最大的感触是：Zephyr 的复杂度其实是一种“集中爆发的复杂度”，前期搭建环境、学习设备树、理解板卡定义的过程确实要花不少时间，但一旦打通，后面每加一个外设、每换一块板子，都是在复用同一套方法。设备树不是给新手准备的炫技概念，它就是嵌入式系统从“点硬件”走向“描述硬件”的必然形态。如果你正在计划把自己的 STM32 项目迁移到 Zephyr，或者正准备拿一块新板子开始 Zephyr 开发，我建议你从本文里最小系统板的 board 定义开始，一步一步走通串口日志，再尝试加入自己的外设。路不难走，只是需要耐心把每一步都走扎实。