4. 开发环境搭建

各位做嵌入式的朋友，今天我们来聊聊驱动分层。这个话题，说实话，是很多工程师从「会写驱动」到「会设计驱动」的分水岭。

我刚入行那会儿，写驱动就是对着芯片手册操作寄存器。一个 GPIO 驱动，从寄存器配置到中断处理，全塞在一个文件里。后来换了个平台，好家伙，几乎全部重写。那种痛苦，经历过的人都懂。

后来我慢慢悟出一个道理：驱动分层，本质上是在做「关注点分离」。把「怎么操作硬件」和「硬件挂在哪里」分开，把「通用逻辑」和「芯片特性」分开。这样换平台时，你只需要动最底层那一小块。

今天我们就来拆解这四层：设备驱动、总线驱动、平台驱动、控制器驱动。看看它们各自管什么，怎么配合。

四层模型全景图

先上一张图，让大家有个整体印象。这张图我画了很多遍，每次给团队培训都用它。

从这张图你能看到，越往上越通用，越往下越贴近硬件。设备驱动可以跨平台复用，控制器驱动则跟具体芯片绑定。中间的总线驱动和平台驱动，起到承上启下的作用。

设备驱动层：最接近应用的那一层

设备驱动，说白了就是「让外设干活」的那层代码。它向上对接应用层的 open/read/write/ioctl，向下调用总线或平台驱动提供的接口。

举个例子，一个温度传感器驱动。它不关心传感器是挂在 I²C 总线上还是 SPI 总线上，也不关心 I²C 控制器是 STM32 的还是 NXP 的。它只关心：怎么发命令读温度，怎么解析返回的数据。

我个人习惯，在设备驱动层尽量不写任何跟硬件寄存器直接打交道的代码。全部通过下层接口完成。这样换平台时，设备驱动基本不用动。

总线驱动层：管好「怎么连」这件事

总线驱动，负责管理设备之间的通信协议。I²C、SPI、UART、USB、PCIe，这些都是总线驱动的地盘。

你想想看，一个 I²C 总线驱动要做什么？

• 实现起始条件、停止条件、ACK/NACK 检测
• 管理时钟频率（标准模式 100kHz、快速模式 400kHz）
• 处理多主机仲裁
• 提供统一的收发接口（如 i2c_transfer）

总线驱动的好处是：上层设备驱动不用关心时序细节。你调一个 i2c_master_send()，底层是 GPIO 模拟还是硬件 I²C 控制器，设备驱动完全不用管。

平台驱动层：SoC 内部设备的管家

平台驱动，这个概念在 Linux 内核里很常见。它专门管理 SoC 内部集成的设备——那些不挂在标准总线上，而是直接挂在 SoC 内部总线上的外设。

比如：DMA 控制器、定时器、GPIO 控制器、看门狗、RTC。这些设备没有「插入/拔出」的概念，它们在系统启动时就存在。

平台驱动的典型工作模式是：

1. 在设备树或板级文件中描述设备信息（寄存器地址、中断号、时钟源）
2. 平台驱动根据这些信息进行资源申请和初始化
3. 向上层提供标准化的操作接口

控制器驱动层：直接跟寄存器打交道

控制器驱动，是四层里最底层的。它直接操作硬件寄存器，完成最基础的硬件控制。

比如一个 UART 控制器驱动，它要：

• 配置波特率寄存器
• 设置数据位、停止位、校验位
• 操作发送/接收 FIFO
• 处理中断标志位

这一层的特点是：跟芯片手册一一对应。换一个芯片型号，控制器驱动基本要重写。所以我们的目标是把控制器驱动做得尽可能薄，只做最纯粹的硬件操作。

四层之间的协作关系

光说概念不够，我们来看一个实际的数据流。假设应用层要读取一个 I²C 温度传感器的数据：

层次	做的事情	代码示例（伪代码）
应用层	调用 read() 读取温度	read(fd, buf, 2);
设备驱动	构造 I²C 读命令，调用总线接口	i2c_master_recv(client, buf, 2);
总线驱动	组装 I²C 帧，调用控制器接口	i2c_controller_xfer(ctrl, msg, 1);
控制器驱动	操作寄存器，发送 SCL/SDA 信号	write_reg(I2C_DR, data);
硬件层	物理信号传输	—

你看，每一层只关心自己该做的事。设备驱动不知道 I²C 时序，总线驱动不知道温度怎么换算，控制器驱动不知道数据是温度还是湿度。各司其职，互不干扰。

分层设计的实际收益

说了这么多，分层到底能带来什么好处？我总结了几点：

避坑指南：我踩过的几个坑

最后分享几个实战中容易犯的错误：

• 分层不彻底：设备驱动里直接操作了寄存器。换平台时，这些散落的寄存器操作成了噩梦。
• 接口设计太「薄」：控制器驱动只提供了寄存器读写，上层还得自己拼时序。总线驱动形同虚设。
• 过度抽象：为了「通用」搞了五六层抽象，结果一个简单的 GPIO 翻转要调七八个函数。性能也扛不住。
• 忽略错误传递：底层返回的错误码，上层没有正确处理。我曾经遇到过控制器驱动报超时，设备驱动直接忽略，导致系统死锁。