第3章 驱动层设计：设备驱动模型、分离策略、中断处理与轮询机制
驱动层，说白了就是硬件和上层软件之间的翻译官。我做了这么多年嵌入式，见过太多人一上来就写寄存器操作，结果项目后期改个硬件平台，代码几乎要重写。这一章，我们就聊聊怎么把驱动层设计得既灵活又可靠。
3.1 设备驱动模型：从混乱到有序
早期我做项目时，驱动代码都是散落在各个文件里的。LED 控制、按键读取、串口收发，全都混在一起。后来维护成本越来越高，我才意识到——驱动也需要一个清晰的模型。
一个成熟的设备驱动模型，通常包含三层：
| 层次 | 职责 | 典型文件 |
|---|---|---|
| 设备抽象层 | 定义统一的操作接口（open/close/read/write/ioctl） | device.h, device.c |
| 硬件适配层 | 封装具体芯片的寄存器操作、时序控制 | stm32_gpio.c, imx_uart.c |
| 驱动实例层 | 管理具体设备实例的配置、状态、资源 | led_drv.c, key_drv.c |
我个人习惯把设备抽象层的接口定义成结构体，里面放函数指针。这样换硬件平台时，只需要重新实现硬件适配层的函数，上层代码完全不用动。
核心思想：驱动模型的核心是「接口不变，实现可变」。你想想看，如果每个驱动都自己定义一套接口，那应用层得写成什么样？
3.2 分离策略：把变化和不变分开
分离策略，其实就是「高内聚、低耦合」在驱动层的具体落地。我把它拆成两个维度：
3.2.1 硬件分离
把与具体芯片相关的代码抽出来。比如 GPIO 操作，不同 MCU 的寄存器地址、位操作方式都不一样。但上层需要的只是「设置引脚为输出」「输出高电平」这样的抽象操作。
// 硬件抽象接口
typedef struct {
void (*init)(gpio_port_t port, gpio_pin_t pin, gpio_mode_t mode);
void (*write)(gpio_port_t port, gpio_pin_t pin, uint8_t level);
uint8_t (*read)(gpio_port_t port, gpio_pin_t pin);
} gpio_ops_t;
// STM32 实现
static void stm32_gpio_init(gpio_port_t port, gpio_pin_t pin, gpio_mode_t mode) {
// 操作 STM32 的寄存器
}
// 上层使用
const gpio_ops_t *gpio = get_gpio_ops();
gpio->init(PORTA, PIN0, GPIO_MODE_OUTPUT);
gpio->write(PORTA, PIN0, 1);我曾经在一个项目里，因为没做硬件分离，换 MCU 时改了整整两周的驱动代码。后来重构后，同样的接口，换平台只花了三天。
3.2.2 功能分离
把不同功能的驱动拆成独立模块。比如一个传感器驱动，可以拆成：
- 通信层：负责 I2C/SPI 总线读写
- 协议层：解析传感器寄存器格式
- 应用层：提供温度、湿度等业务数据
这样拆的好处是，如果换了一个同样用 I2C 的传感器，通信层可以复用，只需要改协议层。
3.3 中断处理：别让 CPU 空等
中断是嵌入式系统的核心机制。没有中断，CPU 就得一直轮询，效率极低。但中断处理也有不少坑。
3.3.1 中断处理的原则
我总结了几条铁律：
- 快进快出：中断服务函数里只做最紧急的事，比如读数据、清标志位。耗时操作放到任务里做。
- 避免阻塞：不要在中断里调用延时函数、等待信号量、打印日志。
- 保护共享数据：中断和主循环共享的变量，要用 volatile 修饰，必要时关中断访问。
避坑指南：我曾经在一个产品里，中断服务函数里调用了 printf，结果串口输出时又触发了中断，导致死循环。从那以后，我规定所有中断里只做「搬数据」的工作，绝不碰任何可能阻塞的操作。
3.3.2 中断与任务的衔接
中断处理完数据后，怎么通知任务？常用的方式有：
| 方式 | 适用场景 | 注意事项 |
|---|---|---|
| 信号量 | 任务等待中断事件 | 中断中只能 give，不能 take |
| 消息队列 | 中断传递数据给任务 | 队列长度要足够，防止溢出 |
| 事件标志组 | 多个中断触发同一个任务 | 注意事件位的冲突 |
| 直接函数调用 | 极简系统，无 RTOS | 注意可重入性 |
我个人偏爱消息队列。因为它既能传递事件，又能传递数据，而且天然具有缓冲能力。你想想看，如果中断频率很高，信号量可能会丢失事件，但消息队列可以暂存多条数据。
3.4 轮询机制：简单但别滥用
轮询，就是 CPU 不停地检查某个状态。它简单、可靠，但效率低。什么时候该用轮询？
- 查询频率很低：比如每秒检查一次按键状态
- 实时性要求不高：比如温度采集，几秒一次也没关系
- 硬件不支持中断：有些简单外设只有状态寄存器
但轮询有个大问题——它会阻塞 CPU。如果轮询里加了延时，整个系统都会被拖慢。
优化技巧：用「状态机 + 非阻塞延时」代替纯轮询。比如按键消抖，不要用 delay(20ms)，而是记录上次状态变化的时间，在主循环里判断是否超过 20ms。这样 CPU 可以去做其他事。
3.5 中断 vs 轮询：怎么选？
这个问题没有标准答案。我一般按这个原则判断：
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 高频数据采集（>1kHz） | 中断 + DMA | CPU 几乎不参与，效率最高 |
| 低频事件（<10Hz） | 轮询 | 实现简单，不需要配置中断 |
| 紧急事件（如掉电检测） | 中断 | 必须立即响应，不能等轮询 |
| 简单状态查询 | 轮询 | 中断资源有限，没必要浪费 |
嗯，这里要注意：中断不是万能的。中断太多会导致 CPU 频繁进出中断上下文，反而降低整体效率。我见过一个项目，把所有外设都配成中断，结果中断嵌套把栈空间撑爆了。
3.6 驱动层整体架构图
下面这张图，是我在项目中实际使用的驱动层架构。它把设备模型、分离策略、中断/轮询统一在了一起。
这张图的核心逻辑是：上层依赖抽象，下层提供实现，中间用接口隔离。每一层只关心自己的事，不越界。这样设计出来的驱动，换平台、加功能、修 bug，都轻松得多。
3.7 实战建议
最后，给你几个我在项目中踩过坑后总结的建议：
1. 先画图，再写代码。 驱动层的架构图一定要先画出来。哪怕只是手绘的草图，也能帮你理清模块之间的关系。
2. 接口定义要稳定。 设备抽象层的接口一旦确定，尽量不要改。因为上层代码和测试用例都依赖它。我习惯在项目初期花两天时间专门打磨接口。
3. 中断优先级要规划好。 我曾经在一个多中断项目里，把定时器中断优先级设得比串口中断还高，结果串口数据频繁丢失。后来按「实时性要求越高，优先级越高」的原则重新分配，问题才解决。
驱动层设计，说到底就是「分」和「隔」两个字。分得清楚，隔得干净，后面的开发就会顺畅很多。嗯，这一章的内容就到这里，希望对你有所帮助。