2、传感器驱动框架：Zephyr 传感器子系统架构、Sensor Driver 模型、设备树（Devicetree）与传感器绑定

好，我们进入第二章。这一章，咱们要啃一块硬骨头——Zephyr 的传感器驱动框架。

说实话，我第一次接触 Zephyr 的传感器子系统时，也被它的分层结构绕晕过。但用熟了之后你会发现，这套设计其实非常优雅。它把硬件细节藏得死死的，让你写应用层代码时，根本不用关心底层是 I2C 还是 SPI。

2.1 Zephyr 传感器子系统架构

Zephyr 的传感器子系统，说白了就是一套「标准化接口」。它定义好了传感器该有哪些操作，比如采样、读取、配置。你想想看，如果每个传感器厂商都搞一套自己的 API，那工程师不得疯掉？

整个架构分三层：

• 应用层：你写的业务代码，调用 sensor_sample_fetch() 和 sensor_channel_get()。
• 驱动层：每个传感器芯片自己的驱动实现，负责和硬件寄存器打交道。
• 内核层：提供设备模型、电源管理、中断处理等基础设施。

我个人习惯把这三层想象成一个「汉堡」：应用层是面包顶，驱动层是肉饼，内核层是面包底。肉饼好不好吃，决定了整个汉堡的质量。

2.2 Sensor Driver 模型

驱动模型这块，我建议你重点关注两个结构体：sensor_driver_api 和 sensor_device。

sensor_driver_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 负责把采样结果读出来。这两个函数是成对出现的，缺一不可。

我在项目中遇到过一个问题：有个同事在 sample_fetch 里直接返回了缓存的数据，没有真正去读硬件寄存器。结果就是，每次读到的数据都一样。排查了半天才发现是驱动实现偷懒了。

2.3 设备树（Devicetree）与传感器绑定

设备树，这是 Zephyr 里最让我头疼也最让我佩服的部分。头疼是因为它的语法有点绕，佩服是因为它真的把硬件配置和代码分离得干干净净。

简单来说，设备树就是用文本文件描述硬件。比如你的传感器接在哪个 I2C 总线上，地址是多少，中断引脚是哪个，都在设备树里定义。

一个典型的传感器设备树节点长这样：

/ {
    i2c0: &i2c0 {
        status = "okay";
        clock-frequency = <400000>;

        bme280: bme280@76 {
            compatible = "bosch,bme280";
            reg = <0x76>;
            label = "BME280";
        };
    };
};

你看，compatible 属性告诉系统这个设备是 bosch 的 BME280，reg 是 I2C 地址 0x76。驱动就是靠 compatible 字符串来匹配设备的。

为什么要有设备树？你想想看，如果没有设备树，你要改个 I2C 地址就得改 C 代码，重新编译。有了设备树，改个 dts 文件就行，代码完全不用动。这在产品开发中太重要了。

2.4 传感器绑定（Sensor Binding）

绑定，说白了就是让驱动知道「我该操作哪个硬件」。Zephyr 通过设备树生成宏定义，驱动里直接用这些宏来访问硬件资源。

比如，驱动里获取 I2C 总线设备：

#define DT_DRV_COMPAT bosch_bme280

#include <zephyr/drivers/i2c.h>
#include <zephyr/device.h>

struct bme280_data {
    const struct device *i2c_dev;
    uint16_t i2c_addr;
};

static int bme280_init(const struct device *dev)
{
    const struct bme280_config *config = dev->config;
    struct bme280_data *data = dev->data;

    data->i2c_dev = device_get_binding(config->i2c_dev_name);
    if (!data->i2c_dev) {
        return -ENODEV;
    }

    return 0;
}

这里 DT_DRV_COMPAT 宏告诉系统，这个驱动对应的是 bosch,bme280 这个 compatible。系统会自动把设备树里的配置信息填充到 dev->config 里。

我个人习惯在驱动初始化时，先打印一下配置信息，确认设备树解析正确。这招帮我抓出过好几次设备树写错的问题。

2.5 实践建议

最后，给你几个实战中的小建议：

1. 先读设备树，再写驱动：我每次写新传感器驱动，都会先花半小时把设备树文件理清楚。硬件资源怎么分配的，心里要有数。
2. 用好 sensor_value 结构体：这个结构体包含一个整数部分和一个小数部分。别直接拿 float 去算，精度会丢。
3. 测试驱动时，先跑 sample 例程：Zephyr 官方提供了很多传感器的 sample 代码。先跑通 sample，再改自己的应用，效率高很多。
4. 注意电源管理：很多传感器有休眠模式。如果你的产品要低功耗，记得在驱动里实现 pm_control 回调。

下一章，我们会深入一个具体的传感器驱动实现，手把手带你写一个完整的驱动。到时候，你会更深刻地理解今天讲的这些概念。