硬件接口基础：PCIe、USB、I2C/SPI 与选型实战
大家好，我是老张。做驱动开发这些年，我最大的感触就是——不懂硬件接口，写出来的驱动就像在盲人摸象。今天咱们就聊聊驱动开发绕不开的四个接口：PCIe、USB、I2C 和 SPI。我会结合自己踩过的坑，把每个接口的核心要点讲透。
核心观点：接口选型决定了驱动开发的复杂度。选对了，事半功倍；选错了，后面全是坑。
一、PCIe 接口协议：驱动开发者的硬骨头
PCIe 是我工作中打交道最多的接口。说白了，它就是电脑内部的高速公路。从显卡到 NVMe 固态硬盘，全指着它跑数据。
核心要点：
- 拓扑结构：树形结构，根复合体（Root Complex）下面挂交换器（Switch），再挂端点设备（Endpoint）。
- 通道概念：x1、x4、x8、x16。每个通道（Lane）是一对差分信号，收发独立。
- 版本演进：Gen1 2.5GT/s → Gen2 5GT/s → Gen3 8GT/s → Gen4 16GT/s → Gen5 32GT/s。
我的经验：有一次调试 NVMe 驱动，死活跑不到 Gen3 的速度。查了半天，发现是 PCB 走线长度不匹配，导致信号时序偏移。嗯，硬件设计上的小问题，驱动层根本看不出来。所以做 PCIe 驱动，一定要先确认链路训练状态——用 lspci -vvv 看 LinkSta 字段。
驱动开发关注点：
- 配置空间访问：通过 CFG 读写寄存器，获取 BAR 地址、中断号等。
- DMA 传输：使用 Scatter-Gather 列表，避免大块连续物理内存的申请。
- MSI/MSI-X 中断：比传统 INTx 更高效，支持多队列。
// 读取 PCIe 配置空间中的 Vendor ID 和 Device ID
uint16_t read_pci_config(uint8_t bus, uint8_t dev, uint8_t func) {
uint32_t addr = (1 << 31) | (bus << 16) | (dev << 11) | (func << 8) | 0x00;
outl(0xCF8, addr);
return (uint16_t)(inl(0xCFC) & 0xFFFF);
}注意：PCIe 热插拔不是所有平台都支持。我曾经在某个嵌入式平台上做热插拔测试，结果系统直接挂了。后来发现是根复合体不支持 Surprise Remove。所以，量产前一定要做热插拔压力测试。
二、USB 接口协议：即插即用背后的复杂世界
USB 看起来简单——插上就能用。但背后的协议栈其实相当复杂。我个人习惯把 USB 协议分成三层看：物理层、协议层、应用层。
协议层次：
- 物理层：差分信号 D+ / D-，速度由端接电阻决定。
- 协议层：令牌包、数据包、握手包。主机控制一切，设备只能被动响应。
- 应用层：通过端点（Endpoint）和管道（Pipe）传输数据。每个设备最多 16 个端点。
传输类型：
| 类型 | 特点 | 典型应用 |
|---|---|---|
| 控制传输 | 可靠，双向，用于枚举和配置 | 设备描述符获取 |
| 批量传输 | 可靠，但延迟不确定 | U盘、打印机 |
| 中断传输 | 保证延迟，但带宽有限 | 键盘、鼠标 |
| 等时传输 | 无重传，带宽保证 | 音频、摄像头 |
避坑指南：我曾经调试一个 USB 摄像头驱动，发现图像偶尔花屏。查了三天，最后发现是等时传输的缓冲区没有对齐到 512 字节边界。USB 控制器对缓冲区对齐有严格要求，驱动里必须用 dma_alloc_coherent 来分配。
驱动开发要点：
- 枚举过程：获取设备描述符 → 配置描述符 → 接口描述符 → 端点描述符。
- URB（USB Request Block）：驱动通过 URB 与 USB 核心层交互。
- 电源管理：USB 支持挂起/唤醒，驱动要处理设备状态切换。
三、I2C 与 SPI：嵌入式系统的左膀右臂
这两个接口在嵌入式领域太常见了。I2C 适合接传感器、EEPROM 这类低速设备；SPI 适合接 ADC、LCD、Flash 这类需要高速传输的器件。
I2C 协议
I2C 只有两根线：SCL（时钟）和 SDA（数据）。所有设备挂在总线上，通过地址区分。标准模式 100kHz，快速模式 400kHz，高速模式 3.4MHz。
通信流程：
- 主机发送起始条件（SCL 高时 SDA 从高变低）。
- 发送 7 位从机地址 + 读写位。
- 从机应答 ACK。
- 传输数据，每字节后跟 ACK。
- 主机发送停止条件（SCL 高时 SDA 从低变高）。
我的经验：I2C 最坑的地方是总线锁死。有一次从机没释放 SDA 线，导致整个总线卡住。解决办法是在驱动里加超时复位机制——如果 SCL 线连续 9 个时钟周期没有变化，就强制产生停止条件。
SPI 协议
SPI 有四根线：SCLK（时钟）、MOSI（主出从入）、MISO（主入从出）、CS（片选）。全双工通信，速度可以跑到几十 MHz。
四种模式：
| 模式 | CPOL（时钟极性） | CPHA（时钟相位） |
|---|---|---|
| 模式 0 | 0（空闲低） | 0（第一个边沿采样） |
| 模式 1 | 0（空闲低） | 1（第二个边沿采样） |
| 模式 2 | 1（空闲高） | 0（第一个边沿采样） |
| 模式 3 | 1（空闲高） | 1（第二个边沿采样） |
注意：SPI 没有标准的应答机制。我曾经遇到过从机芯片的 CS 片选时序要求很苛刻——CS 必须在时钟开始前至少 100ns 拉低。驱动里如果没加这个延时，数据就会错位。所以，读芯片手册的时序图，比什么都重要。
四、硬件接口选型：驱动开发者的决策指南
选型这件事，说白了就是权衡。我见过太多项目因为接口选型失误，导致驱动开发周期翻倍。下面是我总结的选型决策树：
选型维度：
- 带宽需求：超过 1Gbps 选 PCIe；100Mbps~1Gbps 选 USB 3.0；低于 10Mbps 考虑 I2C/SPI。
- 通信距离：板内通信用 I2C/SPI；机箱内用 PCIe；机箱外用 USB。
- 设备数量：I2C 支持 127 个从机（实际受电容限制）；SPI 每个 CS 一个设备；PCIe 通过 Switch 扩展。
- 开发复杂度：I2C/SPI 驱动最简单；USB 中等；PCIe 最复杂。
我的建议：如果项目周期紧，优先选 USB。Linux 内核里 USB 驱动框架非常成熟，你只需要实现 probe 和 disconnect 回调，加上几个 urb 处理函数就行。PCIe 驱动虽然性能好，但调试起来真的很痛苦——我有个项目光链路训练就调了两周。
实际案例：去年做一个数据采集卡项目，需要 500MB/s 的持续吞吐。一开始想用 USB 3.0，但实测发现批量传输的延迟抖动太大，影响数据完整性。后来换成 PCIe Gen2 x4，用 DMA 加环形缓冲区，问题就解决了。所以，理论带宽是一回事，实际表现是另一回事——一定要做原型验证。
好了，接口基础就聊到这儿。记住一句话：驱动开发，七分靠硬件，三分靠代码。把接口协议吃透了，写驱动就是水到渠成的事。