驱动开发

前言 如果你长期写 STM32、ESP32 或 Linux 驱动，第一次接触 Zephyr RTOS 时，最容易卡住的地方通常不是线程、信号量这些传统 RTOS 概念，而是三个看起来“有点绕”的基础设施：Devicetree、Kconfig 和驱动模型。很多人会问：为什么点一个 LED、读一个 I2C 传感器，不能像裸机工程那样直接写寄存器地址？为什么配置宏要分散在 prj.conf、Kconfig、*.overlay、*.yaml 和生成目录里？ 原因很简单：Zephyr 面向的不是单个芯片或单块板子，而是“同一套应用可以在不同板级硬件上复用”。它把硬件描述、功能裁剪、驱动实例化、应用逻辑拆开，让应用尽量不关心底层板子的管脚、总线地址和外设差异。这个思路非常适合产品化嵌入式开发：今天样机用 nRF52，明天量产版换 STM32；今天传感器挂在 i2c0，明天板子改版挪到 i2c1；应用层最好只写一次。 本文不做“概念堆砌”，而是以一个虚构但贴近真实项目的 I2C 温湿度传感器 xyz123 为例，完整走一遍 Zephyr 驱动开发链路：如何写 Devicetree overlay，如何写 binding，如何通过 Kconfig 打开驱动，如何用 DEVICE_DT_INST_DEFINE() 生成设备实例，如何在应用中调用标准 sensor API，最后再给出调试和移植时最常见的坑。 一、为什么 Zephyr 要把硬件描述放到 Devicetree 在传统裸机工程里，硬件信息经常散落在 C 代码中：I2C 地址写成宏，GPIO 管脚写成宏，时钟频率写在 board.h，中断优先级写在初始化函数里。项目小的时候这很直观；项目一旦有多块板、多种传感器、多套 SKU，维护成本会很快上升。 Zephyr 借鉴 Linux 的 Devicetree 思路，把“板上有什么硬件、硬件挂在哪里、默认参数是什么”写成树状描述。比如一个 I2C 传感器可以描述为：它挂在 i2c1 控制器下面，地址是 0x44，中断脚连接到 gpio0 的第 12 脚，采样周期默认 1000 ms。驱动代码不直接写死这些值，而是在编译期从 Devicetree 生成的头文件中取。 这种方式有三个直接好处：...