1. Zephyr传感器驱动框架概述
各位同学，咱们今天聊聊Zephyr的传感器驱动框架。说实话，我第一次接触Zephyr时，也被它这套分层设计绕晕过。但用顺手之后，你会发现——嗯，这套框架确实是为嵌入式工程师量身定做的。
1.1 传感器子系统架构
Zephyr的传感器子系统，说白了就是一套标准化的“传感器接入规范”。它把不同厂商、不同接口的传感器，统一成一套API。你想想看，如果没有这个抽象层，每换一个传感器就得重写一套驱动，那移植工作得多痛苦？
整个架构分三层：
- 应用层：你写的业务代码，调用
sensor_sample_fetch()拿数据 - 驱动层：每个传感器具体的初始化、配置、数据读取逻辑
- 内核层：I2C/SPI/UART等总线通信，以及设备树解析
我个人习惯把这三层想象成“点菜-做菜-买菜”的关系。应用层只管点菜，驱动层负责做菜，内核层去采购原材料。各司其职，互不干扰。
1.2 Sensor Driver Model
Zephyr的传感器驱动模型，核心就两个结构体：struct sensor_driver_api 和 struct sensor_device。
先看API结构体——它定义了驱动必须实现的函数指针：
struct sensor_driver_api {
int (*sample_fetch)(const struct device *dev,
enum sensor_channel chan);
int (*channel_get)(const struct device *dev,
enum sensor_channel chan,
struct sensor_value *val);
int (*attr_set)(const struct device *dev,
enum sensor_channel chan,
enum sensor_attribute attr,
const struct sensor_value *val);
int (*attr_get)(const struct device *dev,
enum sensor_channel chan,
enum sensor_attribute attr,
struct sensor_value *val);
};这里我提醒大家注意一点：sample_fetch 和 channel_get 是必须实现的，而 attr_set/attr_get 是可选的。我在项目中遇到过好几次，有人偷懒没实现 attr_set，结果上层配置采样率时直接返回 -ENOSYS，排查了半天才发现是驱动没写完。
再看设备实例结构体。每个传感器设备在运行时，都会对应一个 struct sensor_device：
struct sensor_device {
const struct device *dev;
const struct sensor_driver_api *api;
void *driver_data;
};这个结构体把设备句柄、API函数表、私有数据绑在一起。你调用 sensor_sample_fetch() 时，底层其实就是通过这个结构体找到对应的驱动函数。
api 指针是否为空。如果为空，说明设备树绑定没成功，驱动根本没注册上。这个坑我踩过不止一次。
1.3 设备树与驱动绑定
设备树（Device Tree）是Zephyr里连接硬件描述和驱动代码的桥梁。说白了，它就是一份“硬件配置清单”。
一个典型的传感器设备树节点长这样：
/ {
i2c0: &i2c0 {
status = "okay";
clock-frequency = <I2C_BITRATE_FAST>;
bme280: bme280@76 {
compatible = "bosch,bme280";
reg = <0x76>;
label = "BME280";
};
};
};这里的关键字段：
| 字段 | 含义 | 我踩过的坑 |
|---|---|---|
compatible |
驱动匹配字符串，驱动里用 DT_DRV_COMPAT 宏定义 |
拼写不一致，驱动加载失败 |
reg |
I2C地址或SPI片选号 | 地址写错，通信一直超时 |
label |
设备名称，应用层通过它找到设备 | 命名冲突，两个传感器用了同一个label |
status |
设备使能标志，必须为 "okay" |
忘了写status，设备根本没初始化 |
驱动绑定的核心宏是 DT_INST_FOREACH_STATUS_OKAY。它会遍历所有状态为 okay 的设备树实例，为每个实例生成一个设备实例。我曾经调试一个三轴加速度计，怎么都读不到数据，最后发现是设备树里把I2C地址写成了0x18，而芯片实际地址是0x19——差一个bit，折腾了一整天。
west build -t menuconfig 确认配置生效。我曾经以为改了dts文件就万事大吉，结果编译时根本没包含进去，白白浪费了两个小时。
1.4 整体流程梳理
咱们把整个流程串起来看看：
从这张图可以看得很清楚：数据从应用层发起请求，经过驱动层解析，通过设备树找到对应的硬件配置，最终由内核层完成总线通信。每一层各司其职，这也是Zephyr能支持上百种传感器的原因。