Zephyr RTOS在STM32F103C8T6上的实践：设备树驱动的嵌入式开发-尧图网络科技

第一次接触 Zephyr RTOS 时，很多人会陷入一个误区：以为这又是一个需要复杂配置、依赖特定 IDE、只能在高端开发板上运行的嵌入式系统。但当我真正把 Zephyr 运行在一块最普通的 STM32F103C8T6 最小系统板上时，才发现它的设计哲学完全不同——它真正解决的不是“让 RTOS 能在更多芯片上跑”，而是“让嵌入式开发回归到关注业务逻辑本身”。

你可能已经习惯了这样的开发流程：先装 CubeMX，再配 HAL 库，然后处理各种外设初始化，最后才能开始写业务代码。但 Zephyr 带来的变化是，你只需要关注“设备树”这个抽象层，就能让同一份代码在不同硬件上运行。今天我们就用最常见的 STM32F103C8T6 最小系统板，完整走一遍从环境搭建到第一个程序运行的流程，看看这个号称支持 220 多种 STM32 开发板的 RTOS 到底如何改变我们的开发习惯。

1. 为什么选择 Zephyr + STM32F103C8T6 这个组合

1.1 Zephyr 的独特价值：不只是又一个 RTOS

很多人把 Zephyr 简单理解为 FreeRTOS 的替代品，这其实低估了它的设计目标。Zephyr 的核心优势在于它的设备树（Device Tree）机制和跨硬件抽象层。这意味着你可以用同一套代码基础，通过修改设备树配置就能适配不同的硬件平台。

举个例子，如果你在 STM32F103C8T6 上开发了一个基于 Zephyr 的串口通信程序，当需要迁移到 STM32F407 时，通常只需要调整设备树中的引脚定义和时钟配置，而不需要重写驱动层代码。这种可移植性对于产品迭代和跨平台开发来说价值巨大。

1.2 STM32F103C8T6 的典型性：低成本验证的最佳选择

STM32F103C8T6 作为经典的 Cortex-M3 内核微控制器，虽然性能不算顶尖，但具备了完整的外设集合：USART、SPI、I2C、定时器等一应俱全。更重要的是，它的资源约束（64KB Flash, 20KB RAM）正好可以验证 Zephyr 在资源受限环境下的表现。

选择这个组合还有一个实际考虑：如果 Zephyr 能在资源最紧张的 STM32F103 上稳定运行，那么迁移到更高端的 STM32 系列只会更加顺畅。这种“从下往上”的验证方式，比直接在高配硬件上测试更有说服力。

1.3 环境搭建的挑战与应对策略

Zephyr 的环境搭建确实比传统的 Keil 或 CubeIDE 复杂，但这背后的设计思路值得理解。它不依赖特定的 IDE，而是基于 CMake 和 West 工具链，这种选择让项目配置更加透明和可版本控制。

实际搭建过程中，最大的挑战通常来自 Python 环境、工具链路径和权限问题。我们将采用分步验证的方式，确保每个环节都独立测试通过，避免问题累积导致的排查困难。

2. 环境准备：避开依赖冲突的实用方案

2.1 基础环境配置

Zephyr 官方推荐使用 Chocolatey（Windows）、Homebrew（macOS）或 apt（Linux）来安装基础依赖。但根据实际经验，我更建议手动控制关键组件的版本，特别是 Python 和工具链。

首先确保系统已安装：

Python 3.8 或更高版本（推荐 3.8-3.10，避免使用最新的 3.12+ 可能存在的兼容性问题）
Git 2.20+
CMake 3.20+

验证命令：

python --version git --version cmake --version

如果系统中存在多个 Python 版本，建议使用 pyenv 或虚拟环境管理，避免权限问题。

2.2 安装 Zeph 核心工具 West

West 是 Zephyr 的项目管理工具，负责拉取代码、管理依赖和构建项目。安装时要注意权限控制：

pip install west

安装完成后验证：

west --version

如果出现权限错误，可以考虑使用--user参数或虚拟环境安装。

2.3 获取 Zephyr 源码和工具链

这里有个关键决策点：是使用官方发布的稳定版本，还是直接使用主分支？对于初次接触，我建议使用最新的稳定版本：

west init zephyrproject cd zephyrproject west update

这个过程会下载完整的 Zephyr 源码和所有依赖模块，耗时较长。如果网络不稳定，可以考虑配置镜像源。

工具链安装是另一个容易出错的环节。Zephyr 支持多种工具链，对于 STM32 开发，Zephyr SDK 是最简单的选择：

# 在 zephyrproject 目录下 west zephyr-export pip install -r zephyr/scripts/requirements.txt

2.4 验证环境完整性

环境搭建完成后，不要急于编译目标项目，先运行基础验证：

# 验证工具链 west build -b nucleo_f103rb zephyr/samples/hello_world

选择 nucleo_f103rb 而不是直接使用 stm32f103c8t6 是因为官方板支持包（BSP）中前者有更完整的测试用例。如果这个基础样例能编译通过，说明环境基本正常。

3. 为 STM32F103C8T6 创建第一个项目

3.1 理解 Zephyr 的项目结构

与传统嵌入式项目不同，Zephyr 项目有明确的层级结构：

CMakeLists.txt：项目构建配置
prj.conf：Kconfig 系统配置
boards/：板级支持包（可选）
src/：应用源代码
dts/：设备树文件（可选）

对于 STM32F103C8T6，我们需要重点关注设备树的配置，因为官方可能没有直接对应的板级定义。

3.2 创建项目框架

新建项目目录结构：

my_zephyr_app/ ├── CMakeLists.txt ├── prj.conf └── src/ └── main.c

CMakeLists.txt 内容：

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

prj.conf 基础配置：

CONFIG_HEAP_MEM_POOL_SIZE=8192 CONFIG_MAIN_STACK_SIZE=1024 CONFIG_SERIAL=y CONFIG_UART_CONSOLE=y CONFIG_PRINTK=y

3.3 设备树配置的关键作用

STM32F103C8T6 最小系统板通常没有对应的官方板级支持包，我们需要基于相近的板子进行适配。创建一个board/目录，复制最接近的板级定义（如 nucleo_f103rb）并进行修改。

关键修改点包括：

闪存和内存大小：STM32F103C8T6 是 64KB Flash, 20KB RAM
时钟配置：通常使用内部 8MHz RC 振荡器倍频到 72MHz
引脚定义：根据实际硬件连接调整 UART、LED 等外设引脚

设备树文件（.dts）示例片段：

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

3.4 编写测试程序

在 src/main.c 中创建一个简单的闪烁 LED 程序：

#include <zephyr/kernel.h> #include <zephyr/device.h> #include <zephyr/drivers/gpio.h> #define LED_NODE... // 根据实际硬件定义 LED 引脚 void main(void) { const struct device *led = device_get_bind(LED_NODE); gpio_pin_configure(led, LED_PIN, GPIO_OUTPUT_ACTIVE); while (true) { gpio_pin_toggle(led, LED_PIN); k_msleep(1000); } }

这个简单程序验证了内核调度、设备驱动和 GPIO 控制的基本功能。

4. 编译、烧录与调试实战

4.1 编译配置与优化

编译时需要注意目标板的选择。由于我们为 STM32F103C8T6 创建了自定义板级支持包，编译命令应为：

west build -b stm32f103c8t6_minimal

编译过程中重点关注：

内存使用报告：确保不会超出芯片限制
警告信息：Zephyr 的配置系统会产生大量警告，需要区分哪些是重要的
设备树编译结果：确认引脚分配和时钟配置正确

4.2 烧录方法选择

STM32F103C8T6 通常通过 ST-Link 或串口进行烧录。Zephyr 支持多种烧录方式：

使用 ST-Link：

west flash --runner stlink

使用 OpenOCD：

west flash --runner openocd

使用 pyOCD：

west flash --runner pyocd

首次烧录建议先使用--erase参数确保芯片完全擦除：

west flash --erase --runner stlink

4.3 串口调试与日志输出

烧录完成后，通过串口查看输出是验证系统运行的关键。STM32F103C8T6 的 USART1 通常连接到 PA9（TX）和 PA10（RX），配置为 115200 波特率。

使用 minicom、picocom 或 PuTTY 连接：

picocom -b 115200 /dev/ttyUSB0

如果看到 Zephyr 的启动日志和应用程序输出，说明系统基本运行正常。

4.4 常见问题排查指南

问题1：编译失败，提示内存不足

检查 prj.conf 中的配置项，禁用不必要的功能
优化应用程序的内存使用
确认设备树中的内存大小设置正确

问题2：烧录失败，无法连接芯片

检查 ST-Link 连接和驱动
确认 BOOT0 和 BOOT1 引脚配置正确
尝试使用--erase参数强制擦除

问题3：程序运行但无输出

检查串口引脚配置和设备树设置
验证时钟配置是否正确
确认终端软件配置匹配（波特率、数据位、停止位）

问题4：程序运行不稳定

检查堆栈大小配置
确认中断优先级设置合理
使用 Zephyr 的内核调试功能分析任务调度

5. 从示例到实战：工程化考量

5.1 项目配置管理

Zephyr 的 Kconfig 系统提供了灵活的配置管理。对于实际项目，建议创建多个配置文件：

prj.conf：基础配置
prj_release.conf：发布版本配置（优化大小和性能）
prj_debug.conf：调试版本配置（启用日志和调试功能）

编译时指定配置：

west build -- -DOVERLAY_CONFIG=prj_debug.conf

5.2 外设驱动集成

Zephyr 提供了丰富的外设驱动，集成时需要注意版本兼容性。以 I2C 读取传感器为例：

#include <zephyr/drivers/i2c.h> const struct device *i2c_dev = device_get_bind("I2C_1"); if (i2c_dev == NULL) { printk("I2C device not found\n"); return; } uint8_t reg = 0x00; uint8_t data[2]; int ret = i2c_burst_read(i2c_dev, sensor_addr, reg, data, sizeof(data));

这种统一的设备接口让驱动代码在不同硬件间具有很好的可移植性。

5.3 多任务与同步机制

Zephyr 提供了完整的 RTOS 功能，包括线程、信号量、消息队列等。创建多任务应用时：

K_THREAD_DEFINE(worker_thread, 1024, worker_function, NULL, NULL, NULL, 5, 0, 0); void worker_function(void *arg1, void *arg2, void *arg3) { while (true) { // 工作任务 k_msleep(100); } }

关键是要合理设置线程优先级和堆栈大小，避免资源冲突。

5.4 电源管理与低功耗优化

对于电池供电的应用，Zephyr 的电源管理功能尤为重要：

#include <zephyr/pm/pm.h> #include <zephyr/pm/policy.h> // 配置低功耗模式 pm_policy_state_lock_get(PM_STATE_SUSPENDED_TO_RAM);

通过合理的电源状态管理，可以显著降低系统功耗。

6. 长期维护与升级策略

6.1 版本控制与依赖管理

Zephyr 项目使用 West 管理依赖，建议将整个 zephyrproject 目录纳入版本控制。但要注意避免提交构建产物和下载的模块。

更好的做法是使用 West 的清单文件（west.yml）固定依赖版本，确保构建的可重复性。

6.2 持续集成自动化

对于团队项目，建议设置 CI/CD 流水线自动验证构建：

# GitHub Actions 示例 jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Build Zephyr Application run: | west init -l . west update west build -b stm32f103c8t6_minimal

6.3 调试与日志系统

Zephyr 提供了强大的日志系统，建议在项目中合理使用：

#include <zephyr/logging/log.h> LOG_MODULE_REGISTER(main, LOG_LEVEL_DBG); LOG_INF("Application started: version %s", APP_VERSION);

通过配置不同的日志级别，可以在开发和发布阶段灵活控制输出信息。

6.4 性能优化与内存管理

长期运行的项目需要关注性能优化：

定期分析内存使用情况，避免碎片化
使用 Zephyr 的性能分析工具监控任务执行时间
合理配置看门狗和系统监控

Zephyr 在 STM32F103C8T6 上的成功运行，验证了这套 RTOS 在资源受限环境下的实用性。但更重要的是，它展示了一种更加工程化的嵌入式开发模式——通过设备树抽象硬件差异，通过配置系统管理功能特性，通过标准接口保证代码可移植性。

这种模式的学习曲线确实比传统的库函数开发要陡峭，但一旦掌握，就能在项目迭代和平台迁移中获得巨大的效率提升。对于需要长期维护的嵌入式产品，这种前期投入是值得的。

资讯详情