这次我们来看一个基于 Zephyr RTOS 的 STM32F103C8T6 GPIO 控制 LED 的实战案例。对于很多从传统单片机开发（如 STM32 HAL/标准库）转向 Zephyr 的开发者来说，最大的困惑可能就是“设备树（Device Tree）”。以前配个 LED 灯，无非就是改改宏定义、初始化一下 GPIO 端口，现在怎么变得这么复杂？这篇文章的目的就是帮你彻底搞懂 Zephyr 的设备树。我们会用一个最经典的“点灯”实验作为切入点，手把手带你完成从环境搭建、设备树配置、驱动编写到最终烧录运行的完整流程。你会发现，一旦理解了设备树的设计哲学和 Zephyr 的驱动模型，开发效率会大幅提升，代码的跨平台移植也变得异常简单。1. 核心能力速览在深入细节之前，我们先快速了解下这个案例涉及的核心技术栈和它能帮你解决什么问题。能力项说明项目类型Zephyr RTOS 嵌入式应用开发核心芯片STM32F103C8T6 (Blue Pill 开发板核心)主要功能通过设备树配置 GPIO，驱动 LED 状态指示灯开发环境Zephyr SDK / nRF Connect SDK (NCS) / VS Code 插件硬件门槛任意 STM32F103C8T6 最小系统板（即 Blue Pill），一根 USB 转串口线启动方式通过west build和west flash命令编译和烧录关键概念设备树 (DTS)、设备绑定 (Binding)、Zephyr 驱动模型适合场景学习 Zephyr 设备树与驱动开发、为 STM32F103 移植 Zephyr、理解硬件抽象层不适合场景仅想快速点灯而不关心 Zephyr 框架；项目严重依赖芯片特定外设高级功能（需直接操作寄存器）简单来说，这个案例演示了如何在 Zephyr 框架下，用声明式的设备树文件（而非硬编码的宏）来描述硬件连接，并通过标准的驱动 API 来操作硬件。这是理解现代 RTOS 如 Zephyr、Linux 驱动开发的关键一步。2. 为什么需要设备树？从“点灯”说起在传统的单片机开发中，点灯代码通常长这样：// 传统方式：硬编码 #define LED_GPIO_PORT GPIOA #define LED_PIN GPIO_PIN_5 void main() { // 1. 使能时钟 __HAL_RCC_GPIOA_CLK_ENABLE(); // 2. 初始化GPIO GPIO_InitTypeDef gpio = {0}; gpio.Pin = LED_PIN; gpio.Mode = GPIO_MODE_OUTPUT_PP; gpio.Pull = GPIO_NOPULL; gpio.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(LED_GPIO_PORT, gpio); // 3. 操作IO HAL_GPIO_WritePin(LED_GPIO_PORT, LED_PIN, GPIO_PIN_SET); }这种方式简单直接，但有几个问题：硬件耦合紧：引脚信息散落在代码各处，换一个引脚需要修改所有相关代码。可移植性差：代码和具体板卡绑定，换一块板子（哪怕同型号 MCU）就要大改。驱动复用难：LED 驱动和按键驱动可能都操作 GPIO，但它们的初始化代码是重复且分散的。Zephyr 的设备树就是为了解决这些问题。它的核心思想是：用一份静态的配置文件（.dts）来声明硬件资源及其连接关系，驱动代码通过查询这份配置来获取硬件信息，从而实现硬件描述与驱动逻辑的解耦。对于上面的点灯例子，在 Zephyr 中会变成这样：硬件描述：在.dts或.overlay文件中写明“板子上 PA5 连接了一个 LED，且低电平点亮”。驱动代码：写一个通用的 LED 驱动，它能从设备树中读取“哪个引脚控制哪个 LED”的信息。应用代码：调用 Zephyr 标准的 GPIO 或 LED 驱动 API 来控制设备树中定义的 LED。这样做的好处是：板级移植只需改设备树：换一块板子，通常只需修改.dts文件，应用和驱动代码无需改动。驱动自动匹配：系统启动时，会根据设备树中的compatible属性自动找到并初始化对应的驱动。配置集中管理：所有硬件信息一目了然。3. 环境准备与工具链搭建开始实验前，你需要准备好以下环境。3.1 硬件准备主控：STM32F103C8T6 最小系统板（Blue Pill）一块。LED：板载用户 LED（通常连接在 PC13），或者自己外接一个 LED 和限流电阻到任意 GPIO（如 PA5）。下载器：ST-Link V2 或兼容的调试器，或者使用 USB 转 TTL 串口配合内置 Bootloader 进行串口下载。连接线：杜邦线若干。