串行通信协议对比：UART/SPI/I2C/I2S选型与调试要点

说个挺常见的事很多人拿到一块开发板看到原理图上面标着 I2C、I2S、SPI、UART 好几路接口第一反应是“这几个东西到底有什么区别能不能随便换”去年我帮朋友调试一块带音频编解码器和 24 位 ADC 的板子主控是 STM32音频走 I2S传感器挂 I2CADC 又想跑 SPI最后还要留一路 UART 打印日志。那一次我算是彻底把这四兄弟的脾气摸清楚了。这四种协议都是串行通信但诞生年代、设计目标、硬件开销和应用场景完全不同。这篇放在一起对比的主要目的是让你在选型、读时序图、调驱动、量波形的时候能快速定位“该关注的信号到底是哪根线”而不是对着逻辑分析仪的一堆波形一头雾水。内容覆盖物理层、时序、效率、常见坑外加逻辑分析仪实测要点适合刚入门的嵌入式新手也适合手里正在做多外设方案的老哥当速查手册用。1. 为什么嵌入式领域会出现这四种串行总线1.1 先搞清楚它们被发明出来是为了解决什么很多人把 I2C、SPI、UART 放在一起比却忽略了它们并不是同一代产物也不是为了干同一件事而生的。UART 是最老牌的它的本质是“异步串行”不需要时钟线只需要一根 TX、一根 RX。当年电脑的串口、鼠标、Modem都是靠它。设计的核心诉求很简单低成本、长距离、两端只要有共同的波特率约定就能干活。代价是速度慢、没有时钟同步所以误码率和波特率强相关。SPI 是摩托罗拉在 MC68000 时代搞出来的为了“快”而生。它带一根时钟线 SCK主从通过片选 CS 来选定通信对象。数据线至少两根MOSI 和 MISO主从可以同时互发数据全双工。代价是引脚多而且严格依赖主设备提供时钟天生就是一主多从。I2C 是飞利浦为了家电内部互联开发的核心理念是“省引脚、多设备”。只用一根 SDA 和一根 SCL靠地址选设备7 位地址最多能挂 128 个设备。因为它用开漏输出通信要靠上拉电阻和 ACK 应答机制速度天然上不去。I2S 则是飞利浦当年为了让数字音频设备互连搞出来的。它长得很像 SPI——有 BCLK、WS 和 SD 三根线但其实更关心“连续音频流的左右声道同步”所以它是流式协议不是以寄存器为中心的读写字协议。把这四条线摊开你会发现一个规律每一代新总线都在上一代基础上补短板也都在牺牲一些东西。你不可能要求一个协议又快、又省线、又支持多设备、又能长距离物理世界就是有取舍。1.2 共同点是“串行”差异点是“怎么对齐数据”所有串行通信的本质都是约定一套“收发双方怎么把 0 和 1 变成可识别的电平变化”的规则。这里的核心有四个要素时钟、帧头、数据位、应答。UART没有时钟全靠两边各自内部振荡器对齐波特率靠起始位做帧同步。SPI有时钟线每个时钟周期收发一位靠 CS 拉低标记一帧事务的开始。I2C有时钟线但数据的有效性由时钟高电平期间 SDA 不能变化来约束靠 START/STOP 条件界定一帧。I2S有时钟线但又多一个声道选择线 WS左右声道的帧边界由 WS 翻转确定。只要你把“时钟从哪来、帧怎么算、数据线怎么流”这三个问题想清楚看任何协议的时序图都会轻松很多。这也解释了为什么大家经常把“spi、i2c、i2s、uart、gpio、sdio、can 时序图”放在一起搜——因为本质上都是在看同样的四要素在波形上怎么体现。2. 逐个拆解UART、SPI、I2C、I2S 的物理层与时序2.1 UART——异步协议的老大哥UART 的物理层最简单两根线TXD 和 RXD交叉连接。没有时钟因此双方必须先约定一个波特率比如 9600、115200、460800。收发双方各自用自己的时钟源采样采样点一般取位宽的中间位置。为了保证帧同步空闲时 TX 线保持高电平要发数据时先拉低一个位宽作为一个起始位让接收方知道“要开始了”。一帧典型结构是起始位 1 位 数据位 5~8 位 校验位可选 停止位 1~2 位。以 8N1 为例8 个数据位、无校验、1 个停止位实际有效载荷是 8 bit但完整一帧要占 10 bit。算下来 115200 波特率的有效吞吐只有 115200 × 8 / 10 92160 bit/s差不多 11.5 KB/s。UART 的时序图很好认空闲高、起始位低、LSB 先行后面跟着数据位和停止位。逻辑分析仪上你只要把波特率设置正确它会自动把波形解码成十六进制。这里我得专门提一个热词里常见的“uart阻塞和非阻塞”。在 STM32 这类 MCU 上你可以用轮询、中断、DMA 三种方式处理 UART 收发。轮询就是阻塞式的CPU 一直在等 RX 标志位中断是每来一个字节打断一次DMA 则是数据在内存和串口之间自动搬运CPU 只需在收完一帧后处理一次。真正的非阻塞收发一定是 DMA 串口空闲中断的组合这一点在《stm32f103 标准库 uart dma 中断接收发送通信》这类老代码里体现得最明显。老工程师的做法是用 IDLE 中断判断一帧数据结束用 DMA 把环形缓冲区里的数据搬到内存。这样哪怕一次来 100 个字节CPU 也只中断两次效率完全不一样。踩过的坑是标准库和 HAL 库对“空闲中断后如何清标志位”的处理略有区别标准库要先读 SR 再读 DRHAL 库则要操作 HIS 寄存器很多人在这里翻车。2.2 SPI——最直白的全双工主从SPI 只需要四个信号SCK、MOSI、MISO、CS。主设备产生 SCKCS 低电平选中从设备时钟的每个边沿传输一位数据。它有极强的可配置性最典型的是四种模式由 CPOL 和 CPHA 决定。CPOL 决定空闲时时钟是低还是高CPHA 决定数据是在第一个边沿还是第二个边沿采样。这四种模式叫 SPI Mode 0、Mode 1、Mode 2、Mode 3。我也见过不少新手把 Mode 0 当成“默认模式”结果从设备需要 Mode 3读回来的数据永远错位。解决办法很简单把从设备数据手册里的时序图找出来看它标的是“数据在上升沿采样”还是“下降沿采样”再去对照模式。永远不要靠猜。SPI 的波形也很容易认CS 先拉低SCK 开始翻转MOSI/MISO 在 SCK 边沿附近变化。用逻辑分析仪抓 SPI主要关注三件事第一CS 有没有毛刺第二时钟极性是否和从设备一致第三MOSI 和 MISO 的数据是否与命令字对齐。SPI 的另一个特色是硬件片选和软件片选之争。硬件片选由 SPI 外设自动控制 NSS 引脚响应快但有些芯片的硬件 NSS 时序并不好调软件片选则就是拿一个普通 GPIO 去控制 CS灵活、想拉多久拉多久却可能因为 GPIO 翻转速度限制在高频下产生瓶颈。“cs最小能做到多少 us”这个问题本质就是在问片选脉冲宽度和连续传输间隔能压缩到多小。MCU 上用 GPIO 模拟片选我实际测过从判断条件到写引脚哪怕只跑 72 MHz 主频也有几十纳秒到一两百纳秒的延迟这种延迟放在 10 MHz 以上的 SPI 传输里就很要命所以高频场景优先用硬件片选。SPI 也非常强调半双工用法。很多传感器为了省一根线把 MOSI 和 MISO 合并成一根双向数据线比如某些磁编码器和 ADC。stm32 的半双工 SPI 模式就是为这种情况准备的配置成 1 根数据线主机先发命令再从设备回数据。实际调试时要注意方向切换的时钟周期往往会多出一个或者半个周期的无效位千万别把这一位算进有效数据里。2.3 I2C——两根线组成的一条街I2C 是我见过“看着简单用起来最磨人”的协议。SDA 和 SCL 都是开漏输出外部要接上拉电阻。线路空闲时两根线都被上拉电阻拉高主机要发起通信时先把 SDA 从高拉低此时 SCL 还是高这就是 START 条件。停止条件是 SCL 高电平期间 SDA 从低变高。每一个数据位上SCL 低电平期间 SDA 允许变化SCL 高电平期间 SDA 必须保持稳定接收方要回复 ACK就是把 SDA 拉低一个时钟。I2C 的地址机制是它和 SPI 不一样的地方不需要片选线每个从设备自带一个地址。一个 7 位地址的总线上理论上最多 128 个设备但同一地址就会冲突。所以 I2C 扩展芯片才会那么流行TCA9548A 这类多路复用器可以把一条 I2C 总线扩成 8 路每组再挂 8 个同地址设备实际工程里的 i2c 多路复用就是这么干的。I2C 的速度档位大家熟知的包括标准模式 100 kbit/s、快速模式 400 kbit/s、快速模式 1 Mbit/s、高速模式 3.4 Mbit/s。热词里的“100k i2c 信号规格”其实讲的是标准模式下对上升沿和下降沿时间的要求100 kHz 模式下SCL 和 SDA 的上升时间一般不超 1000 ns下降时间不超 300 ns。这直接决定上拉电阻怎么选总线电容越大上拉电阻就得越小。很多人只知道 I2C 要接上拉却不去算阻值结果 100 kHz 时波形上升沿太缓从设备完全收不到数据。实测经验是电平 3.3 V、总线电容在 200 pF 左右时4.7 kΩ 凑合能用但 2.2 kΩ 更稳。I2C 的时序图是四兄弟里最不容易看懂的因为它不是一根 CS 拉低就能框住整个事务而是靠 SCL 高电平期间 SDA 的跳变来定义边界。抓波形时你要重点观察 ACK 位地址发送后第 9 个时钟SDA 有没有被从设备拉低。没有 ACK就是地址错误、设备没上电、或者总线被拉死。还有一个从热词里冒出来的概念叫“i2c 自由数据模式”我理解这通常指一些 I2C 调试工具支持直接收发任意字节序列不按寄存器读写格式来组织数据。比如你想手工构造一个特殊时序先发送 START再发几个任意字节再 STOP逻辑分析仪看不到寄存器语义。这在调试新芯片时很有用因为很多芯片的私有命令并不符合“地址寄存器数据”的常规套路。2.4 I2S——专门为音频流的“时钟同步总线”I2S 是这四个里面最特殊的一个它不是一个通用数据传输总线而是一个音频流总线。标准 I2S 有三根线BCLK位时钟、WS声道选择/帧同步、SD串行数据。此外有时还会有 MCLK 主时钟用于给音频编解码器提供内部时钟。WS 信号很有意思它低电平通常是左声道高电平是右声道每次翻转代表一个采样帧的开始。BCLK 的频率等于采样率 × 位深 × 通道数。比如 48 kHz、24 bit、双声道BCLK 就是 48 k × 24 × 2 2.304 MHz。看 I2S 逻辑分析仪波形的时候你首先应该数一个 WS 周期内有多少个 BCLK这个数决定了采样位深是否配置正确。如果配置成 32 bitBCLK 就是 48 k × 32 × 2 3.072 MHz。很多人拿 SPI 的思维去看 I2S以为 WS 是片选其实不准确。WS 和 CS 最大的差别是CS 拉低表示一整包事务开始而 WS 是周期性翻转的没有“空闲”状态因为音频流必须连续不断。所以 I2S 一旦开启就必须持续给数据否则会出现咔哒声或音调漂移。调试 I2S 时最常见的问题就是“BCLK 有了WS 有了SD 上就是没数据”这时候多半是 DMA 没有配置好或者环形缓冲区的刷写频率跟不上采样率。3. 四个协议的硬核对比3.1 一张表看清核心参数对比维度UARTSPII2CI2S时钟线无SCKSCLBCLK、MCLK数据线TX、RX2 根MOSI、MISO2 根SDA1 根双向SD1 根通常单向帧同步方式起始位CS 片选START/STOP 地址WS 声道翻转通信模式全双工全双工半双工流式单向多设备支持点对点为主一主多从多主多从地址区分点对点为主典型速率115200 bps ~ 几 Mbps几 Mbps ~ 几十 Mbps100k / 400k / 1M / 3.4M取决于采样率和位深硬件开销低中低但需上拉中抗干扰一般一般一般一般适合板级近距离应用场景日志、调试、GPS、蓝牙模块Flash、ADC、LCD、编码器传感器、RTC、EEPROM、GPIO 扩展音频编解码器、麦克风阵列这张表基本回答了你平时选型时 80% 的问题。如果你要的是“简单的点对点交互又允许用两根线”优先 UART如果你要“高速搬运大量数据”SPI如果你要“一根总线上挂一堆低速传感器”I2C如果是数字音频流只能用 I2S。3.2 引脚与拓扑对布局的影响板级硬件设计上这几位的差距也非常明显。UART 是点对点或者菊花链的 RS-485都要额外加收发器点对点最省心。SPI 每加一个从设备就要多一个 CS所以从设备多了以后GPIO 资源很紧张。I2C 则完全靠地址区分只要地址不冲突总线可以挂几十个器件但总线电容也会跟着涨频率和上拉电阻就得重新算。我需要提醒一点I2C 是唯一允许总线上有多个主机的协议。支持多主意味着两个主设备可以在不同时间占用总线甚至通过仲裁机制避免冲突。但真正用多主模式的项目很少因为仲裁逻辑、重发机制写起来麻烦我见过最多的情况还是“一个主机 一堆从机”所以这部分知道有这个概念就够了。I2S 则基本是点对点结构一个音频主控对一个 codec除非用 TDM 模式或者菊花链否则不支持多个编解码器简单挂同一条线。这也是 I2S 和 SPI 的很大区别——SPI 可以靠 CS 选择同一总线上的不同设备I2S 没有这种“按 CS 区分”的能力。3.3 速度是纸面的效率要看“有效吞吐”举个例子。同样传 8 位数据I2C 至少要START 1 位 7 位地址 1 位 R/W 1 位 ACK 8 位数据 1 位 ACK STOP 1 位总共至少 20 个时钟周期实际有效数据只有 8 位效率不到 40%。这也是 I2C 明明标称 400 kHz实际连续写 EEPROM 却快不起来的原因。SPI 则没有起始位、停止位、地址和应答只要 CS 拉低SCK 就开始跑8 bit 数据就是 8 个时钟周期开销几乎为零。再加上可以全双工主从同时发数据所以同样 10 MHz 的时钟SPI 的实际吞吐比 I2C 高出好几倍。UART 的有效率取决于帧格式8N1 是 80%。I2S 则比较特殊它没有地址和数据包开销但存在“对齐延迟”标准 I2S 数据在 WS 翻转后延迟一个 BCLKJIS 模式则延迟半个周期不同芯片的时序要求能差出半个时钟周期这也是跨平台移植 I2S 配置时容易出问题的地方。如果你正在“fpga spi adc”这类高速采集项目里选型我直接说结论优先 SPI。典型的逐次逼近型 ADC 都是 SPI 接口比如 AD7980、ADS 系列转换完成后通过 SPI 把 16~24 位数据读走。如果你用 I2C 读 ADC速度会被地址、ACK、寄存器寻址吃掉一大截在高采样率下根本跑不过来。4. 实际项目从时序图到逻辑分析仪的实测记录4.1 逻辑分析仪怎么看波形我自己的调试习惯是凡是新板子回来先抓一遍波形确认物理层正常再谈驱动代码。很多人一上来就写代码驱动调不通还不知道是硬件问题还是软件问题。手里 16 通道以上的逻辑分析仪最好便宜型号也够用核心是采样率至少要比协议时钟快 4 倍。抓 UART通道接 TX、RX设置波特率后解码器会自动标出起始位和停止位。重点看空闲电平是否稳定有没有杂波把整包数据拖乱。抓 SPI把 CS、SCK、MOSI、MISO 四根接全设置 CPOL/CPHA。重点看 CS 拉低之前 SCK 是否已经稳定CS 释放时最后一个数据位是否完整。抓 I2C接 SCL、SDA。如果波形上升沿明显变缓八成是上拉电阻太大或总线电容太大。还要观察有没有“总线忙”的情况也就是 SDA 长期为低、SCL 还能翻。抓 I2S接 BCLK、WS、SD。重点数一个 WS 周期里 BCLK 的数量以及 WS 跳变沿和第一个有效数据位的位置。我实测过程中的结论是I2C 最值得先用逻辑分析仪看一遍因为它最容易出电平时序问题I2S 则最容易出“帧结构配置错误”问题SPI 最容易出模式不匹配问题UART 是这四个里最容易用串口助手直接验证的。4.2 STM32 开发板上的实战组合说一个我最近做过的组合STM32F103 用标准库驱动一路 UART DMA 接收 GPS 数据一路 SPI DMA 读外部 Flash一路 I2C 轮询读温湿度传感器。UART 的配置要点在 DMA 和空闲中断。我不会只开一个字节接收中断因为那样 CPU 会被高速数据打满。做法是DMA 配置成循环模式把数据一直搬进环形缓冲区USART 空闲中断置位时说明一帧结束再去解析缓冲区。这个方案在 115200 波特率、每秒上百包数据的场景下CPU 占用率非常低。SPI 的配置要点是 DMA 和片选配合。读外部 Flash 时必须先发命令字节再连续读数据。如果用 STM32 HAL 库的HAL_SPI_Receive_DMA我踩过坑它在片选软件控制时要求你手动把 CS 拉低等 DMA 传输完全结束后再拉高。不然 DMA 还在搬运CS 已经释放了读回来的最后几个字节全是 0xFF。I2C 轮询读传感器要特别注意超时判断。某些传感器在内部 EEPROM 烧写时会拉低时钟扩展也就是 SCL 保持低电平等待数据准备好。代码里不能死等必须加超时否则总线一旦被卡住整个系统就挂在那里。4.3 FPGA 场景用 Verilog 写 I2C EEPROM 和 SPI ADC 接口FPGA 和 MCU 不一样没有现成外设库时序全靠自己写状态机。这里有两条经典路线。I2C EEPROM 控制器比如读写 AT24C 系列内部逻辑就是一个状态机START、地址、寄存器地址、数据、STOP、ACK 检测。这里最容易被忽略的是 ACK 等待。EEPROM 擦写需要时间写完一页如果立刻发下一个写命令从设备可能还处于内部写周期不会 ACK。所以“i2c 读写 eeprom 代码 verilog”这类代码里最关键的是在每次写操作后加一个 ACK 轮询发一个伪写命令只等从设备回 ACK不回就重试直到它准备完成。SPI ADC 接口则简单些难点在时序裕量。高速 ADC 采样时钟和 SPI 读取时钟可能来自不同时钟域FPGA 里要用异步 FIFO 或者双口 RAM 做缓冲。还有一个分频采样问题采样率为 1 MHz每个采样 16 bit那么 SPI 读出的时钟至少要 16 MHz 以上才能在一个采样周期内完成读取。用全局时钟分频时要保证 SCK 的占空比和建立/保持时间都符合 ADC 数据手册要求。很多人在仿真里没问题上板就跑飞原因就是时序约束没做或者 IO 延时导致数据采样沿偏了。4.4 Linux 用户空间与 Python 模拟 SPI/I2C在 Linux 上访问 SPI 和 I2C绕不开/dev/spidevB.C和/dev/i2c-N。每次调试我都会先确认三点内核有没有编译对应驱动、设备树有没有分配节点、用户权限够不够。比如 RK3588 的 SPI 接口设备树里要定义spi...配置pinctrl、dma-names、cs-gpios。如果你要用 GPIO 做软件片选就要让cs-gpios指向某个普通 GPIO这种做法在一个板子上接多个 SPI 设备时很常见因为每个设备需要不同的片选极性或片选时序。Python 调用 USB 模拟 SPI 接口我常用 FT2232H 或 CH341 这类工具。FT2232H 通过 pyftdi 库可以很方便地虚拟出 SPI 主机直接把 PC 当 SPI 主机去调试 Linux 板卡或者传感器比反复烧录固件快得多。注意 pyftdi 的时钟频率是分频得到的不是任意值都能精确达到。实测想要 10 MHz 时实际上可能得到 12.5 MHz要看分频表。Linux 里还有一个很冷门但值得提的用法某些 PHY 芯片不用 MDIO 管理接口而是把 MDIO 映射到 I2C 上。这种情况下你只需要在设备树里配置i2c-mux或者 mdio-i2c 桥接驱动就能通过 I2C 总线上读 PHY 的寄存器。我以前在老项目里用过这种方案寄存器读上来全是 0xFFFF 时先查总线地址对不对再查主控侧是不是没有使能上拉。关于 USB 转 UART 驱动FT232R 和 FT231X 这两个芯片非常经典。Windows 下装上官方 VCP 驱动后设备管理器里会显示 COM 端口。常见的问题是装完驱动后识别不到多半是驱动的强制签名、USB 线质量、芯片供电三件事。还有一次是差分线没接对TX 接到 TX结果对面设备完全收不到。USB 转 UART 绝对不是随便接交叉连接 RX/TX 永远是第一检查项。4.5 音频项目的 I2S 时序实测音频板的 I2S 调试我总结过一套检查顺序先量 MCLK 有没有再量 BCLK 频率对不对再看 WS 周期对不对最后看 SD 上数据是否对齐。比如某 codec 要求 256×fs 的 MCLK48 kHz 采样率下 MCLK 就要 12.288 MHz。如果你板子上 MCLK 没有或者频率不对codec 直接不工作。还有一种是 codec 的 I2S 格式默认 32 bit 帧长但主控配置成了 24 bit数据也能跑但声道会出现相位偏移听着像超声一样很难排查。这个就属于“i2s 逻辑分析仪波形”能帮上忙的典型场景直接看 WS 高电平期间有几个 BCLK一目了然。5. 常见问题速查与排查思路5.1 I2C总线挂死、NACK、从机“主动”更新I2C 最大的噩梦是“总线挂死”SDA 被某个设备拉低不放SCL 可以正常翻转但主机发 START 没用因为 SDA 已经是低了。这时候最快的方法是让主机多翻转几次 SCL把 SDA 释放或者直接给设备复位。硬件上我建议每个人都在 I2C 的 SCL 和 SDA 上预留测试点方便夹逻辑分析仪也方便短路释放总线。第二个经典问题是 NACK。地址发完了、从设备不回 ACK原因按概率排序是地址写错、从设备没上电、总线上拉电阻缺失、从设备被复位拉住了引脚。GT911 这类触摸屏 I2C 通信失败最常见的是触摸屏的 I2C 地址随复位状态变化或者它的中断引脚必须接对不然芯片不进入正常工作模式。还有一个大家爱问的“i2c 从机主动更新主机寄存器”这在原版 I2C 协议里并不存在。I2C 是主设备主动发起的协议从设备不可能像中断那样直接往总线上说话。要实现类似效果要么用 SMBus 的 ARP/ALERT 机制要么从设备先拉一个中断引脚通知主机来读要么做多主模式从设备在总线上抢主控权。我的建议是别折腾多主中断引脚通知主机读是工程上最稳妥的。5.2 SPI片选竞争、半双工、最小片选宽度SPI 调试最常见的问题是“CS 拉低了但设备没反应”。先排除一件事CS 极性反了。不是所有设备都是低有效片选个别芯片是高有效你在代码里拉低反而把它禁用了。硬件片选和软件片选之争再次出现在这里。我用 STM32 的硬件 NSS 时必须要设置SSOE位、处理NSS引脚模式否则片选时序不受控。软件片选更灵活但如果 CS 拉高太快会导致连续传输中的从设备内部状态没复位。数据手册里“cs minimum pulse width”指的就是这个比如某些 Flash 要求 CS 高电平至少持续 30 ns 才能进行下一次操作你如果连续操作间隔太短就偶发失败。半双工 SPI 也有一个常见坑方向切换后第一笔数据可能多出半个时钟周期的“空位”。比如磁编码器 MT6701 这类芯片SSI 模式其实就是 SPI 的变种发完命令后方向切换返回数据会延迟一个时钟才能稳定。逻辑分析仪上你会看到第一个采样点可能采到 0 或者前一位的尾巴这时要把第一个数据位丢弃从第二个位开始读。5.3 UART 乱码、丢字节、DMA 中断拼接UART 乱码最直接的原因是波特率不匹配。我遇到过好几次以为是 115200结果设备实际跑 57600波形完全能解码但内容乱得一塌糊涂。代码里和串口调试工具里各自配置一套很容易忽略。第二个常见原因是两边电平不匹配3.3 V 的 MCU 直接接 5 V 的 USB 转 TTL高电平会互相拉扯严重时会烧引脚。UART 丢字节问题和接收方式强相关。轮询接收时如果 main 循环里在处理其他耗时任务一个字节来了没来得及读就被下一个字节覆盖了。中断接收方式好一些但高波特率下中断频繁还是可能丢。可靠做法是 DMA 环形缓冲区。如果 DMA 模式下还丢字节优先检查缓冲区大小和空闲中断里是否错误地关闭了 DMA而且要注意 DMA 传输计数是“还剩多少字节”不是“已经传了多少字节”。阻塞和非阻塞的选择我再说一句日志打印用阻塞没所谓但通信协议解析一定要非阻塞。阻塞接收等于把整个 MCU 的命运绑在串口上一帧数据永远收不完整其他所有任务都得跟着等。哪怕是简单的传感器查询也建议写成状态机而不是在一个 while 循环里死等返回。5.4 Windows 下 I2C HID 驱动与资源冲突热词里那个“i2c hid 该设备找不到足够资源可以使用 (代码 12)”是 Windows 系统里 HID over I2C 设备在设备管理器里报错的问题。常见于笔记本触摸屏、触摸板或者指纹模块。原因是设备被 ACPI 认出来但驱动需要的 I2C 控制器资源被占用了或者 BIOS 里没有开启相关功能。排查顺序是先去 BIOS 看触摸屏和 I2C 控制器是否开启再看设备管理器中“系统设备”里有没有 ACPI 虚拟 I2C 控制器如果资源冲突可以试试在设备管理器里禁用再启用 I2C HID 设备或者卸载驱动重扫。不要一上来就重装系统这个问题九成是资源分配而不是驱动程序文件损坏。我在修一台老笔记本时就是因为某次 Windows 更新把 I2C 控制器的资源分配弄乱了更新 BIOS 之后才彻底恢复。5.5 PMBus 和 I2C 的区别再补充一个很多人搜过的问题PMBus 和 I2C 的区别。PMBus 是在 I2C 基础上针对电源管理芯片定义的一套命令集和电气要求。它复用 I2C 的物理层协议但规定了一些额外时序比如在某些命令之间必须等待tBUF时间而且有标准化的命令编码比如 VOUT_MODE、READ_IOUT。所以从协议层面看“PMBus 设备”依然是 I2C 从设备只是必须按照 PMBus 的命令格式去访问不能随意用裸 I2C 读写。如果你用 Linux 的 i2c-tools 直接去操作 PMBus 芯片很多寄存器读不出来就是因为没按 PMBus 命令集走。最好用专用驱动比如 PMBus 内核子系统它会在标准 I2C 访问上封装命令字节和 PEC 校验。6. 到底怎么选从需求出发的决策思路6.1 按外设类型快速锁定协议我给自己定的选型流程很简单你先看设备类型再看速度要求最后看引脚预算。如果是 GPIO 扩展、温度传感器、EEPROM、实时钟用 I2C。这类设备数据量小、速度要求低I2C 的地址机制让你一根总线挂几十个都没问题。如果是大容量 Flash、高分辨率 ADC、LCD 屏用 SPI。SPI 的速度、全双工、无地址开销特别适合搬数据。如果是调试日志、定位模块、蓝牙模组用 UART。这些模块普遍自带串口UART 一根线全搞定。如果是音频编解码器直接用 I2S。没有别的选择。如果是板卡内部和外部的低速率命令控制I2C 和 UART 都能干。此时看生态很多传感器模块默认 I2C 地址很多无线模块默认 UART 指令。一个容易忽略的考虑是“你手里有多少 GPIO 可以浪费”。如果一个传感器既有 I2C 接口又有 SPI 接口我多半选 I2C因为省引脚。但如果这个传感器要高速连续采样比如 5 kHz 以上的加速度计或者音频级 ADCI2C 的带宽会把你卡死这时候哪怕要多接两根线也要用 SPI。6.2 总线扩展和一些邻域协议I2C 扩展需求最早来自地址冲突和总线电容限制。我常用的扩展方案是 I2C 多路复用器 TCA9548A一组上游总线分成 8 路下游总线每一路可以再挂 8 个同地址设备。调试这种树状拓扑时要注意逻辑分析仪只能抓其中一路最好在每一路上预留测试点不然定位哪一路出错非常费劲。I2C 还能扩展出 GPIO。PCF8574、PCA9555 这类 I/O 扩展芯片一个 I2C 地址就能换 8 到 16 个 GPIO对于引脚吃紧的 MCU 是救星。不过这种方案的引脚翻转速度很慢实测 PCF8574 在 100 kHz 下翻转频率也就几百赫兹级别控制 LED 和继电器没问题做高速接口绝对不行。邻域协议里CAN 和 SDIO 也经常和这四位一起出现。CAN 是差分信号、带仲裁和错误重发的总线协议适合车上、工控这种强干扰环境。SDIO 则是给 SD 卡这类存储设备用的时钟频率能到几十 MHz协议栈和 SPI 完全不同。如果只是控制一张 SD 卡多数 MCU 的 SDIO 外设比 SPI 模式读卡速度快得多但如果只是偶尔存日志SPI 模式更省事。GPIO 根本不是协议而是最原始的电平控制经常配合这些协议做片选、复位、中断检测。6.3 混合使用方案的现实案例我最后用两个真实案例收一下。第一个是 RK3588S 混合存储方案SPI NOR 放引导PCIe NVMe SSD 放系统数据。这个方案里 SPI NOR 承担了启动阶段的高可靠性引导因为 SPI 接口简单、时序可控、NOR 上电即可读而 PCIe 通道承担高速大数据量。很多人问为什么不用 SPI 直接挂 SSD因为 SPI 的带宽对于 NVMe 系统盘完全不够看SPI 更适合小容量代码存储。主控上多个接口配合不是替代关系而是分工关系。第二个是电机编码器方案。很多编码器芯片比如 MT6701同时支持 SPI、I2C、ABI、UVW 多种输出。我实际用下来如果只是低速角度读取I2C 就够接线少如果要高精度、高频率的实时角度SPI 才能保证低延迟。同一颗芯片不同接口读出来的数据更新率完全不一样选型时要看控制环路的需求而不是看芯片宣传页面的“分辨率位数”。这四个协议我从来没有当成分立的世界来看。一个成熟的嵌入式系统往往同时存在好几种总线I2C 管传感器UART 管日志SPI 管 Flash 或 ADCI2S 管音频。每一路接口选型的判断标准其实是一致的数据怎么流、速度够不够、引脚花多少、调试难不难。把这些判断标准装进脑子里下次看原理图或写设备树时你就不会再纠结某种芯片“该用哪个口”因为答案每次都很明确。