设备驱动核心数据结构：从结构体到实战

好，咱们今天来啃硬骨头。设备驱动模型里最核心的四个数据结构——struct device、struct driver、API结构体、设备配置与数据。说实话，我刚接触Zephyr那会儿，也被这些结构体绕得头晕。但后来我发现，只要搞懂了它们之间的关系，整个驱动模型就像一张清晰的地图。

1. struct device：设备的身份证

每个设备在Zephyr里都有一个struct device实例。你可以把它想象成设备的身份证——记录了设备的名字、状态、以及它和底层硬件的连接方式。

struct device {
    const char *name;        // 设备名称，比如"uart0"
    const void *config;      // 指向设备配置结构体
    const void *data;        // 指向设备运行时数据
    const void *api;         // 指向API结构体
    const struct device *parent; // 父设备（总线设备）
    void *driver_data;       // 驱动私有数据
    uint8_t state;           // 设备状态
    uint8_t pm_state;        // 电源管理状态
};

嗯，这里要注意config和data的区别。我见过不少新手把两者搞混，结果调试到崩溃。

核心区别：

  • config：编译时就确定的静态信息，比如寄存器基地址、中断号、GPIO引脚。这些在运行时不会变。
  • data：运行时动态变化的数据，比如当前波特率、缓冲区状态、错误计数。

我的习惯：写驱动时，我会把config声明为const并放在ROM区，data放在RAM区。这样既省内存，又避免误修改配置。

2. struct driver：驱动的行为描述

struct driver描述的是驱动本身的行为。它不像struct device那样每个设备都有一个实例，而是同一类设备共享一个驱动实例。

struct driver {
    const char *name;        // 驱动名称
    int (*init)(const struct device *dev); // 初始化函数指针
    const void *api;         // 指向API结构体
    const struct device *devices; // 该驱动管理的设备链表
};

说白了，struct driver就是告诉系统：我这个驱动叫什么名字，怎么初始化，支持哪些API。我刚开始写驱动时，总以为每个设备都要单独写一个struct driver，后来才发现——同一类设备（比如两个UART）可以共用同一个驱动实例。

我曾经踩过的坑：在初始化函数里，我试图通过dev->config直接修改配置参数。结果系统跑着跑着就挂了。后来才意识到，config是const的，应该用data来存运行时状态。

3. API结构体：设备操作的接口契约

API结构体是驱动模型里最优雅的设计之一。它定义了一组函数指针，作为设备操作的接口契约。比如UART设备的API结构体：

struct uart_driver_api {
    int (*poll_in)(const struct device *dev, unsigned char *p_char);
    void (*poll_out)(const struct device *dev, unsigned char out_char);
    int (*configure)(const struct device *dev, const struct uart_config *cfg);
    int (*tx)(const struct device *dev, const uint8_t *buf, size_t len);
    int (*rx)(const struct device *dev, uint8_t *buf, size_t len);
};

你想想看，为什么要把API单独抽出来？因为这样上层应用就可以通过统一的接口调用不同厂商的UART驱动。我参与过一个项目，需要同时支持NXP和ST的UART，只要它们都实现了struct uart_driver_api，上层代码一行都不用改。

API结构体成员 说明 典型实现
poll_in 轮询方式接收一个字节 读取数据寄存器
poll_out 轮询方式发送一个字节 写入数据寄存器
configure 配置UART参数 设置波特率、数据位等
tx 发送数据缓冲区 DMA或中断方式
rx 接收数据缓冲区 DMA或中断方式

4. 设备配置与数据：静态与动态的分离

这是Zephyr驱动模型里最值得称道的设计哲学。配置（config）是静态的，数据（data）是动态的。为什么要这么分？

我举个例子。假设你有一个I2C设备，它的I2C地址是0x50，这个地址在硬件设计时就定死了，不会变。这就是配置。但设备当前的状态——比如是否处于低功耗模式、上次通信是否成功——这些是运行时数据。

// 设备配置（静态，放在ROM）
struct i2c_device_config {
    uint16_t addr;           // I2C地址
    uint32_t speed;          // 通信速率
    uint8_t flags;           // 标志位
};

// 设备数据（动态，放在RAM）
struct i2c_device_data {
    uint32_t current_speed;  // 当前实际速率
    uint8_t error_count;     // 错误计数
    bool is_suspended;       // 是否挂起
};

为什么这样设计？

  • 节省RAM：配置数据通常很大（比如寄存器配置表），放在ROM里不占宝贵的RAM空间。
  • 安全性：配置数据是只读的，不会被意外修改。
  • 可移植性：同一份驱动代码，通过不同的config实例，可以驱动不同配置的硬件。

5. 它们如何协同工作？

好，现在我们把四个结构体串起来。当一个设备被注册到系统时，会发生这些事情：

  1. 编译时：通过宏定义（比如DEVICE_DEFINE）生成struct device实例，并关联config、data、api。
  2. 系统启动时：内核遍历所有设备，调用driver->init函数进行初始化。
  3. 初始化函数：通过dev->config读取硬件配置，通过dev->data初始化运行时状态。
  4. 运行时：上层应用通过dev->api中的函数指针调用驱动功能。

我记得有一次调试一个SPI Flash驱动，发现读出来的数据全是0xFF。折腾了半天，最后发现是config里的SPI模式配置错了——应该配成Mode 0，我配成了Mode 3。这就是config的重要性，一个字节的差异，整个设备就不工作。

避坑指南：写驱动时，一定要在初始化函数里校验config的合法性。我曾经遇到过config里填了一个不支持的时钟频率，结果设备初始化成功但运行时随机崩溃。后来我加了一段校验代码：

if (cfg->freq > MAX_SUPPORTED_FREQ) {
    return -EINVAL;
}

6. 实战中的小技巧

最后分享几个我在实际项目中积累的经验：

  • 命名规范：config结构体用_config后缀，data结构体用_data后缀。这样一看代码就知道哪个是静态的，哪个是动态的。
  • API结构体要稳定：一旦发布，尽量不要修改API结构体的成员顺序。否则所有实现该接口的驱动都要重新编译。
  • 善用DEVICE_DEFINE宏：这个宏会自动帮你生成struct device实例，并关联config、data、api。手动写的话容易出错。
  • 调试时打印config和data的地址：如果设备初始化失败，先看看dev->config和dev->data是不是指向了正确的内存区域。我遇到过链接脚本配置错误，导致config指针指向了未初始化的内存。

好了，关于设备驱动的核心数据结构，今天就聊到这里。这些结构体就像乐高积木——单个看很简单，但组合起来就能搭建出复杂的系统。下一节我们会深入具体的驱动开发流程，到时候我会带着大家手写一个完整的GPIO驱动。

← 上一章 📖 返回目录 下一章 →