1. 先用一张出行方式的图看懂四种串行协议我做了这么多年硬件发现一个挺有意思的现象很多刚入行的朋友一听到 I2C、SPI、UART、I2S 这四个名字第一反应是又要背协议了然后就是拿着数据手册啃时序图越啃越晕。其实换个角度把这四种协议想象成四种城市交通方式瞬间就好记多了。I2C 是公交车两根线SDA 数据线、SCL 时钟线一条线路挂很多站点设备有地址上下车要遵守规则起始/停止条件速度不快但胜在布线省。SPI 是高速专线小巴四根线MOSI、MISO、SCLK、CS专车接送一对一或一对几跑得快实时性好但每接一个新设备通常要占一根片选线。I2S 是音频专用车道三根线BCLK、LRCLK、SDATA专门用来传输数字音频左右声道轮流上流水线一样别拿它传别的数据。UART 是打电话就两根线TX、RX没有时钟线全靠双方提前约定好语速波特率一对接一通简单、通用、方便调试。这四种协议本质都是串行通信也就是按位挨个传输数据但它们面向的场景完全不同。在实际项目中我经常看到的情况是一个板子上既有 I2C 挂在传感器和 EEPROM又有 SPI 连着 ADC 或 FlashUART 接到调试串口或蓝牙模块音频部分再用 I2S 连解码芯片。所以理解它们之间的边界和取舍比死记协议细节更重要。这篇文章我就结合自己调板子的实际经历把这四种协议掰开揉碎讲清楚重点放在它们的设计思路差异、时序图上到底看什么、以及选型时最容易忽略的几个坑上。不管是做单片机开发、Linux 驱动还是 FPGA 逻辑这篇都值得先收藏再慢慢看。提示这篇文章不教你每一个寄存器的配置而是帮你建立选型 → 看时序 → 定位问题的完整思路。参数我尽量给出典型值和推导过程方便你对照自己的硬件去延伸。2. I2C两根线走天下但每一处细节都在暗处2.1 为什么两条线就能挂一堆设备I2C 的全称是 Inter-Integrated Circuit1982 年由飞利浦提出。它最核心的设计是一根数据线 SDA、一根时钟线 SCL所有设备并联在总线上通过地址区分彼此。SDA 和 SCL 都是开漏输出需要外部接上拉电阻到 VCC。开漏 上拉这个设计非常聪明。为什么不用推挽输出因为如果两个设备同时往总线上写相反的电平推挽输出会直接短路。开漏输出只会把线拉低不会主动拉高拉高全靠上拉电阻这样即使多个设备同时操作总线也不会打架。通信流程简单归纳一下起始条件SCL 为高电平时SDA 从高变低。地址字节主机先发送 7 位设备地址 1 位读写方向位0 写、1 读。ACK从机收到地址匹配后在第 9 个时钟周期拉低 SDA 表示应答。数据阶段每个字节 8 位MSB 先行每字节后跟一个 ACK/NACK。停止条件SCL 为高电平时SDA 从低变高。实际用起来你会发现标准模式 100kHz、快速模式 400kHz、高速模式 1MHz这些速率对应的上升时间要求完全不同。比如 100kHz 时 SDA 和 SCL 上升时间最大 1000ns400kHz 时就只有 300ns。这也是为什么总线长度不能太长、上拉电阻不能乱选的原因。2.2 上拉电阻不是随便焊一个 4.7k 完事很多板子默认放 4.7k 上拉但如果你做了两块板子一块是 5V 供电、挂 3 个设备另一块是 1.8V 供电、挂 8 个设备还都用 4.7k大概率会出现如下诡异现象电平拉不低某些从机的输入阈值偏高电阻太大导致低电平不够低通讯时好时坏。波形边沿太缓上升时间超标从机采样到的时钟沿位置不对数据偶尔错位。上拉电阻的选择其实是个物理计算题不是我瞎猜。最小值的限制来自器件能灌入的电流IOL 最大灌电流一般是 3mAVOL低电平最大值在 3.3V 系统中通常是 0.4V那么最小电阻Rmin (VCC - VOL) / IOL (3.3 - 0.4) / 0.003 ≈ 967Ω最大值的限制来自总线电容。总线等效电容约 50pF~100pF如果需要上升时间不超过 300ns400kHz 模式那么从 RC 充电模型可以估算出Rmax Trise / (0.8473 × Cbus) 300ns / (0.8473 × 100pF) ≈ 3.5kΩ所以 400kHz 下 4.7k 在某些走线较长、容性负载较重的板子上就显得临界。我的习惯是低速短走线用 4.7k高速长走线用 1k~2.2k低功耗应用在允许上升沿不那么陡的前提下用 10k。别嫌这事琐碎很多I2C 偶尔挂死的玄学问题最后都查到电阻上去了。2.3 常见的三个 I2C 老坑第一坑地址冲突。一个 I2C 总线上两个设备默认地址相同又没有地址脚去改那读写就乱套了。市面上常见的做法是给芯片加 A0/A1/A2 引脚组合出多个地址。但总设备数超过地址组合上限时就得用多路复用器比如 TCA9548A硬分总线。第二坑I2C 从机把 SDA 拉死不放开。这往往发生在从机内部时钟没跑起来、或者额外复位逻辑有缺陷时。表现形式是主机发起始位后SDA 一直被拉低ACK 永远等不到。处理方式一般是在硬件上给 SCL 多打几个时钟让从机状态机跳出来严重的就要断电复位。我碰到过 GT911 触摸屏在固件异常时把 I2C 总线钳死的情况排查了整整一个下午最后是硬件复位脚解决。第三坑I2C 速率不是越高越好。很多传感器数据手册写支持 1MHz但实际布线上拉阻容极限摆在那里1MHz 下上升时间余量很小。稳定的 400kHz 往往比看似快的 1MHz 可靠得多。尤其像 Linux 下 i2c-dev 或嵌入式 RTOS 里别把一个设备速率调高结果导致整条总线上别的从机都不稳定。2.4 热搜词里说的 PMBus 和 I2C 是什么关系顺带提一下 PMBus。现在服务器电源管理芯片很流行 PMBus它本质上就是 I2C 的延伸物理层沿用 I2C但约定了一组标准的电源管理命令字读电压、读电流、设置余量等。所以你在电源芯片的数据手册里看到的 SDA/SCL/地址位时序核心还是 I2C 那套只是命令格式换了。理解 I2C 的底层PMBus 只是换了一本字典而已。3. SPI全双工的高速专线片选信号才是灵魂3.1 四根线如何做到收发同时进行SPISerial Peripheral Interface由 Motorola 提出四根线SCLK主机输出的时钟。MOSIMaster Out Slave In主机输出、从机输入。MISOMaster In Slave Out从机输出、主机输入。CS/SS片选低有效一条线通常对应一个从机。SPI 是环形移位寄存器结构主机和从机各自有一个移位寄存器每个时钟周期同时移出一位、移入一位所以一个时钟周期内收发各一位天然全双工。比如主机写 0xA5 的同时从机可能把 0x3C 挪回来这就是 SPI 和 I2C 最大的差异——I2C 读数据时必须先发地址、再切方向、再读回半双工SPI 想读想写同一时刻都在做全双工。速度方面SPI 没有上限标准完全看器件的极限。常见的 Flash 或 ADC 跑 10MHz~50MHz 很常见FPGA 和 MCU 之间跑到 66MHz 甚至更高也可以。做高速采样、图片传输、固件更新这类任务时SPI 几乎是默认选项。3.2 CPOL 和 CPHA四种模式区别在哪这是很多人第一次接触 SPI 时最容易懵的地方。四种模式由两个参数组合而来CPOLClock Polarity空闲时 SCLK 是高电平还是低电平。CPHAClock Phase数据采样沿是第一个边沿还是第二个边沿。组合下来就是表里这样模式CPOLCPHA采样沿典型器件Mode 000上升沿绝大多数 Flash、传感器Mode 101下降沿部分 ADCMode 210下降沿部分 LCD 控制器Mode 311上升沿很多 SPI NOR Flash我建议你入手任何新器件时第一件事就是看数据手册里的时序图数一下数据在哪个边沿稳定、哪个边沿采样然后对着寄存器设 CPOL/CPHA。永远不要凭经验默认 Mode 0。我之前调一个 ADS 系列的 ADC数据手册要求 Mode 2我用了 Mode 0结果读回来的数据高几位偶尔跳变特征就是大部分数据对但顶位偶发错误——这种情况排查有多头疼懂得都懂。3.3 硬件片选和软件片选怎么选关于片选网上每天都在讨论硬件片选和软件片选的取舍。我的实践结论是维度硬件片选软件片选响应速度由外设自动拉低拉高响应快依赖 CPU 操作 GPIO有延迟多设备轮询每个从机一根线天然理解现在轮到谁需要软件管理状态容易出错CPU 占用几乎为零每次传输都要操作 GPIO典型场景高速采集、传感器以固定频率上报低速调试、Linux 下 GPIO 模拟实际项目里硬件片选更省心。尤其是 Linux 下的 spi-dev 或 SPI-NOR 驱动设备树里 cs-gpios 只要配好内核自己管理拉高拉低。但要注意硬件片选的高电平恢复时机CS hold time得符合从机要求尤其是 Flash 在读状态寄存器时。有些 Flash 在 CS 拉高的瞬间还希望 SCLK 保持稳定若干 ns如果你在 FPGA 里实现的 SPI 主机没留这口气偶尔就会遇到状态读错。软件片选则更灵活适合走线紧张、多个从机共用一根片选线再加 GPIO 译码的情形但速率上来之后片选的 GPIO 反转时间反而成了瓶颈。所以我的做法是时钟速率超过 20MHz尽量用硬件片选低速且只有两三个从机软件片选也够用。3.4 SPI 的进阶玩法半双工和 DMASPI 表面上四线全双工但很多器件只用部分线比如只读数据、只发命令、甚至用 MOSI 和 MISO 短接做半双工单总线。STM32 的半双工 SPI 模式就是把 MOSI 变成双向数据线适合一些节省引脚的传感器。另一个高频话题是 SPI DMA。如果没有 DMACPU 每一字节都要等待 SPI 中断高速传输时 CPU 占用率极其难看。用 DMA 后比如 STM32 SPI Flash 刷固件可以把 CPU 几乎完全解放出来。配置时注意一个细节DMA 的传输长度要和处理的数据量严格对应尤其 SPI 全双工时DMA 的 TX 和 RX 要一起启动RX 空数据时及时关闭不然最后多读出来几个字节校验失败。另外FPGA 与 MCU 之间用 SPI 通信尤其热门。FPGA 端可以做 SPI 从机MCU 端用 SPI 主机互补协作。这里最常见的坑是时序约束FPGA 逻辑里采样时钟边沿要留出足够的建立保持时间不然高速传输时偶尔丢数据。你在网上一搜FPGA SPI ADC几乎一大半问题都出在采样沿选错了。4. I2S只为音频而生的流水线协议4.1 为什么音频非要单独一个协议很多人第一次看到 I2S 会问I2C 和 SPI 不是挺通用吗为什么音频芯片要用专门协议原因在于数字音频有几个固有的痛采样率固定、左右声道各一路、位深明确而且必须严格等时传输——声音只要卡一下或错位人耳立刻能听出来。I2SInter-IC Sound由飞利浦在 1986 年制定总线就三根BCLK也叫 SCK 或 WCLK位时钟每个 bit 对应一个脉冲。LRCLK也叫 WS声道选择时钟低电平左声道高电平右声道Philips 标准。SDATA串行数据二进制补码MSB 先出。所以 I2S 本质上就是一个极简的串行协议但它把时钟关系安排得明明白白LRCLK 的频率就是采样率如 44.1kHzBCLK 的频率是采样率 × 位深 × 通道数。比如 44.1kHz/16bit/双声道就是BCLK 44100 × 16 × 2 1.4112MHz这套关系意味着音频系统中所有设备必须共用同一个时钟域不然 LRCLK 和 BCLK 无法对齐声音就撕裂。你看到的那些发烧友整天说的时钟抖动“jitter”就是围绕 BCLK 的稳定性在较劲。4.2 I2S 时序图怎么看用逻辑分析仪抓 I2S 波形时你会看到BCLK 是连续且等间隔的方波没有任何停歇。LRCLK 翻转一次代表一个声道完成翻转频率等于采样率。SDATA 在每个 BCLK 周期里送一个 bit数据的首位MSB与 LRCLK 边沿大概延迟一个 BCLK 周期后出现。这最后一个延迟一个 BCLK是 I2S 标准的经典设计。为什么故意延迟一拍因为要让接收方能在时钟边沿稳定采样到最高位。有些 DAC 芯片也支持左对齐或DSP 模式等变体那时序就和标准 I2S 不太一样了。所以我抓到波形后第一步永远是拿标准 I2S 的时序图对一下 SDATA 的首位到底和 LRCLK 对齐还是偏了一拍。逻辑分析仪使用建议采样率至少比 BCLK 高 10 倍以上不然边沿位置量化误差太大看不出延迟。比如 1.4112MHz 的 BCLK分析仪至少要设 16MHz 以上采样率如果测 24bit/192kHzBCLK 到 11.2896MHz采样率就得开 100MHz 往上。4.3 主从时钟关系谁是老板是关键I2S 通信里主从关系决定谁产生时钟。常见两种接法MCU 做主机MCU 产生 BCLK 和 LRCLKDAC 被动接收。这种接法最简单MCU 内部音频外设直接输出。DAC 做主机DAC 自己产生时钟MCU 只读数据。这常见于一些高精度音频方案因为时钟源离 DAC 近抖动更小。问题来了如果两边的时钟不是同一个源头而系统中又同时有 MCU 产生的其他时钟就可能出现采样率不一致最终表现为音频慢慢变调。所以设计上我建议音频相关系统尽量保证 MCLK主时钟统一供给MCU、DAC、音频 PLL 共用一个晶振或时钟芯片。MCLK 本身又是另一个容易遗漏的引脚。有些 DAC 需要 MCLK典型是采样率 × 256 或 × 512有些内置 PLL 不需要。如果你用的是需要 MCLK 的芯片而代码里没初始化对应引脚解码器会一直静音但 I2S 数据波形是正常的——这种波形正常但不响的问题排查起来相当的绕。4.4 I2S 和 PDM/TDM 的扩展现代音频系统里还冒出来两个兄弟PDM 和 TDM。PDM 用一根数据线把一个 bit 当密度调制送出来适合麦克风阵列因为走线少。但 PDM 不是 I2S时序上它只有一根时钟一根数据数据处理也是在 MCU 内部做滤波而不是直接解码成 PCM。做低成本的语音采集方案时很多 MEMS 麦克风都是 PDM 输出这时你的 MCU 得自带 PDM 接口或者外挂解码芯片。TDM 则可以理解为多声道的 I2S一条数据线上分时隙跑 4 个、8 个甚至 16 个声道。汽车音响、多声道 DSP 方案里非常常见。如果你看到芯片手册上写TDM512或者I2S/TDM 共享引脚其实就是这个意思。有了 TDM 之后I2S 那套 LRCLK 的含义变成了帧同步信号不再简单对应左右声道。5. UART没时钟还能稳定通信凭的是性能预留5.1 靠波特率约定好语速UARTUniversal Asynchronous Receiver/Transmitter是四种协议里物理层最朴素的就一根 TX、一根 RX双方没有共享时钟必须在通信前约定好波特率每秒传输的码元数即 bit/s。为什么没有时钟还能通信因为 UART 是一帧一帧异步传输的。发送方在每个字节前发一个起始位拉低接收方在这个下降沿触发采样然后按约定波特率在后续位中心点持续采样。只要两边的时钟误差不超过一定范围就能在窗口内正确读到位。帧格式通常是空闲高电平。起始位1 个低电平。数据位5~8 位常见 8 位。校验位可选偶校验/奇校验/无校验。停止位1 或 2 个高电平。两台设备之间要在波特率误差多少才不会乱码上留余量。UART 的位中心采样有容差经验上总误差要小于 4%-8%。两个设备各自晶振误差 2%看似轻微累计起来在数据连续发送 10 位时误差就会被放大。举一个实际例子曾经有一个项目主机用内部 RC 振荡器跑 115200从机用外部晶振结果接收端偶尔收到 0x00 或 0xFF 这类明显异常的字节。用频率计一量主机实际波特率 114500误差约 0.6%按理说不算大但那个劣质内部 RC 温漂严重一发热就掉到 112000误差逼近 3%自然就随机乱码了。后来的做法是换成外部晶振或选择支持自动波特率检测的芯片。5.2 TTL、RS232、RS485同一个协议三种电压语言UART 的协议是逻辑层的电气层可以完全不同这一点经常有人混淆电气标准电压范围传输距离典型应用TTL UART高 3.3V/5V低 0V小于 1 米MCU 之间、板级通信RS232负逻辑±12V 左右15 米左右老式工业设备、PC 串口RS485差分 A/B2~5V 差模1200 米工业总线、多机联网你拿 USB 转 TTL 模块和一台工控机通信如果工控机是 RS232 电平直接接上去烧不烧取决于模块的耐压但大概率读不到数据。正确姿势是用带 RS232 电平的转接线或者加一颗 MAX3232 电平转换芯片。RS485 则是差分传输抗干扰能力强适合远距离多点组网。但是 RS485 是半双工的发送和接收要切换方向这在代码里经常忘了拉高 DE方向使能导致发送完不切换回接收对方回的数据就丢了。之前有读者问过我用了 RS485 后只能发不能收十有八九是 DE 引脚没控制好。5.3 中断、DMA、阻塞和非阻塞怎么选热搜词里有uart 阻塞和非阻塞“STM32F103 标准库 uart DMA 中断接收发送通信”这都是 UART 工程化的经典话题。简单区分阻塞式调用发送函数后一直等待发送完毕期间 CPU 不能干别的。适合裸机简单任务。非阻塞式发送函数开启中断或 DMA 后立即返回CPU 继续跑主逻辑发完由中断通知。中断接收每收到一个字节触发一次中断适合短报文但高速大数据下中断频繁CPU 压力大。DMA 接收硬件自动把一串数据搬进内存到达指定量后中断一次适合大量接收比如 OTA 升级、文件传输。空闲中断IDLE很多 MCU 的 UART 外设支持总线空闲检测配合 DMA 可以等到线空了就知道一帧收完了这是实现不定长帧接收非常舒服的方式。我个人的实战建议是凡是报文长度不确定的AT 指令、自定义帧、串口命令行优先DMA 空闲中断或逐字节中断 超时判断凡是定长小帧传感器每 100ms 上报 8 字节逐字节中断就够了没必要上 DMA。非要用 DMA 接定长帧反而要小心超长和错位的边界处理。之前调一个 STM32F103 的标准库工程想实现 DMA 接收不定长帧网上大部分教程都是修改 DMA 缓冲大小其实更省心的是开 IDLE 中断。IDLE 中断标志在收到起始位后总线空闲时置位DMA 已经把数据存好你只要在中断里读 DMA 剩余计数就知道这一帧有多长。这套组合下来稳定性和 CPU 占用比老式逐字节中断好太多。5.4 UART 调试时最实用的排查顺序如果你遇到 UART 完全不通我建议按下面的顺序排查基本不会两手空空量 TX/RX 电平空闲是高电平吗如果一直是低可能芯片引脚被强制拉低或者波特率太高导致示波器看不出变化。用逻辑分析仪抓起始位和停止位确认帧格式1 起始 8 数据 无校验 1 停止是否两端一致。量实际波特率抓一个字节用两个下降沿之间的时间反推波特率对照配置。检查交叉连接MCU 的 TX 要接对端的 RX很多人两根线接反了。查看地线两个设备之间必须有共地否则电平参考不一致偶发乱码。6. 四种协议到底怎么选从参数表到决策逻辑6.1 一张表看全对比对比维度I2CSPII2SUART引脚数2SDA/SCL4 及以上3 或 42TX/RX时钟线有有有无异步数据方向半双工全双工单向数据流发射/TX 侧全双工独立 TX/RX多设备一套地址总线挂多个一主多从片选线较多通常点对点点对点RS485 可多机典型速率100k~1M10M~100MBCLK 由采样率决定9600~3M 不等抗干扰一般一般一般RS232/RS485 形式可变典型应用传感器、EEPROM、PMBusFlash、ADC、LCD、FPGA音频 DAC/ADC、蓝牙音频调试口、GPS、蓝牙模块、RS485CPU 负载中低配 DMA 极低中中高配 DMA 低6.2 选型判断路径每当我在新项目里定通信接口我脑子里是有一套决策树的先看传输距离和抗干扰。超过 1 米环境又嘈杂直接考虑 RS485/UART 方案。板内通信再谈 I2C/SPI。看数据量和实时性。大数据量、高速、连续Flash 刷写、图像SPI。低频、小数据、要省引脚I2C。看有多少设备需要挂。设备多且允许低速I2C 的多点拓扑最省引脚。设备多但都要求高速可以用 SPI 多片选但引脚和冲突管理要谨慎。看是否需要全双工。传感器上报数据为主主从一问一答I2C 够用。双向大数据流果断 SPI。看数据格式是否天然是音频流。采样率 左/右声道 高位宽直接 I2S别拿 SPI 硬凑。看调试便捷性。UART 绝对是拿来调试的第一选择几乎所有 MCU 都有串口printf 一挂问题就少一半。这些顺序不是绝对的但按这个思路走很少会选错。6.3 混合使用才是常态一个复杂产品里四种协议同时存在的例子非常多。比如 RK3588 平台的混合存储方案SPI NOR 存引导程序PCIe NVMe 存系统中间调试靠 UART传感器的状态回传用 I2C音频语音助理模块走 I2S。这种设计不是因为某一种协议万能而是每一种协议都在自己最适合的位置上发挥优势。所以我不太建议问哪个协议最好这个问题本身就问错了。更好的问法是我的应用场景里数据速率是高是低节点多少距离远不远实时性要求多高把这几个参数列清楚答案自然浮现。7. 个人调试心得与常用工具位最后再分享几个掏心窝子的经验这些都是在项目里被折磨过之后攒下来的第一I2C 时序图上的 ACK/NACK 不只是 0 和 1 的问题。调试带 I2C 的屏或者触摸时如果主机发完寄存器地址后一直收不到 ACK不要只怀疑硬件连接先确认你发的 7 位地址写的对不对。有些芯片默认地址末尾带了 R/W 位配置地址计算错一位就能让整个总线找不到设备。第二SPI 的 CS 时序一定要用示波器看。很多人在软件里以为 CS 拉低后立刻就能传数据但某些器件的 CS 下降沿到第一个 SCLK 上升沿之间有最小的 tsu建立时间要求不满足时偶尔第一字节丢失。你用逻辑分析仪抓波形一看 CS 和 SCLK 的距离就能判断到底是软件发早了还是硬件片选配置慢了。第三I2S 波形看着没问题绝不代表音频正常。之前调一块音频板I2S 三根线波形完美但就是没声音。查到最后发现 MCLK 没有初始化解码芯片 PLL 没锁定。I2S 协议管的是数据链路MCLK 管的是音频时钟的源头两个维度都要检查。第四UART 调试时先送一长串 0x5501010101方便看波形边沿。0x55 这样的交替位能让逻辑分析仪自动测量每 bit 宽度直接反推出实际波特率比猜快得多。关于工具我常用的配置是USB 转 TTL基于 FT232R 或 CH340 逻辑分析仪至少 8 通道 示波器。USB 转 TTL 看 UART 通不通最快逻辑分析仪抓 I2C/SPI/I2S 时序和总线电平最直观示波器用来量边沿和时序余量。程序上SPI/I2C 的抓包用 PulseView 这类开源软件就够它带协议解码器直接标出地址、ACK、数据帧比盯着裸波形脑补要省事得多。这些工具不需要多贵但你折腾完一遍四种协议后会发现收益远超那几百块钱。希望这篇文章能帮你把 I2C、SPI、I2S、UART 这四种串行语言串起来看懂它们的设计哲学、会用它们各自的优势、避开那些藏在细节里的坑。到了真调板子的那天你会发现脑子里有这张图比记住哪本数据手册都管用。