嵌入式开发绕不开的一个话题就是总线选型。你打开任何一块开发板的原理图几乎都能看到 I2C、SPI、UART 这三种接口的身影做音频的还会碰到 I2S。很多人初学的时候是哪个能跑通就用哪个等到项目做大了、板子画密了、出问题了才发现当初选型时偷的懒全变成了后期调试的债。这篇内容就是把我这些年在这四种总线上踩过的坑、做过的取舍、以及一些不太会在官方手册里写出来的经验系统地梳理一遍。不管你是刚接触单片机的新手还是正在做 RK3588、ESP32-C3 这类平台方案的老手应该都能从中找到对自己有用的部分。1. 四种总线的本质差异先搞清楚它们各自在解决什么问题1.1 从谁说了算看总线拓扑I2C、SPI、UART、I2S 这四者最根本的区别其实在于时钟信号的归属和设备角色的划分方式。UART 是典型的异步通信收发双方没有共享时钟线靠事先约定好的波特率来对齐每一位数据。这意味着两端的时钟精度必须足够接近否则累积误差会在帧尾导致采样错位。UART 的拓扑是点对点的一个 TX 对一个 RX天生只支持两个设备互通。I2C 和 SPI 都是同步通信有一根明确的时钟线SCL / SCK由主机驱动。区别在于 I2C 是半双工、多主多从的架构两根线SDA、SCL上可以挂一堆设备每个从机靠唯一的地址区分SPI 则是全双工、单主多从四根线MOSI、MISO、SCK、CS每个从机独占一根片选线。I2S 可以理解为SPI 的音频特化版。它也是同步串行但它的时钟体系更复杂——除了位时钟 BCK还有帧时钟 LRCK也叫 WS字选择专门用来区分左右声道。I2S 不关心地址也不关心片选它关心的是音频数据的连续性和时序精度。一句话总结UART 靠约定I2C 靠地址SPI 靠片选I2S 靠帧同步。1.2 速率、距离与线数的三角权衡选型时最常被拿出来比较的三个维度是速率、传输距离和引脚开销。我把它们整理成一张表方便你快速对照总线典型速率可靠传输距离引脚数单设备拓扑UART9.6k~921.6k bps高速可到数 Mbps板内几米RS-485 可到千米级2TX/RX点对点I2C100k/400k/1M/3.4M Hz板内几十厘米长线需缓冲2SDA/SCL多主多从SPI几 MHz 到上百 MHz板内十几厘米高速时更短4含 CS单主多从I2SBCK 通常 1~12 MHz板内越短越好3~4点对点为主这张表里有个容易被忽略的点SPI 的速率上限和走线长度是强相关的。你在 1MHz 下能跑通的 20cm 排线到了 50MHz 可能连第一个字节都读不对。原因在于高速下走线的寄生电容和反射会严重破坏信号完整性SCK 边沿一糊从机采样就全乱了。所以做高速 SPI 时走线尽量短、尽量等长、尽量远离干扰源这不是玄学是实打实的信号完整性要求。1.3 为什么不能一种总线打天下经常有人问既然 SPI 最快为什么不全用 SPI答案在于引脚成本和设备数量的矛盾。假设你要挂 8 个传感器。用 I2C两根线搞定地址不冲突就行。用 SPI每个设备一根 CS加上共享的 SCK/MOSI/MISO总共需要 3811 根线。如果你的 MCU 引脚本来就紧张这个差距是致命的。反过来如果这 8 个设备里有 ADC 需要高速采样I2C 的 400kHz 就完全不够看了这时候 SPI 的高速率优势又无可替代。UART 的价值则在于简单和通用。它不需要地址、不需要片选、不需要复杂的时序协商两根线接上就能通。调试串口、GPS 模块、一些老式传感器用 UART 是最省心的。而且 UART 经过电平转换后可以走很长的线工业现场的 RS-485 就是基于 UART 的差分版本。I2S 则是音频场景的刚需。你用 SPI 去传音频数据理论上也行但 SPI 没有帧同步信号左右声道的区分、采样率的对齐都得靠软件额外处理实时性和音质都没法保证。I2S 把这些硬件化了DMA 一挂CPU 几乎不用管。2. I2C 的深水区地址、上拉与那些让人抓狂的锁死2.1 地址冲突与 7 位/10 位寻址I2C 最让人头疼的问题之一就是地址冲突。标准 7 位地址空间理论上能挂 112 个设备去掉保留地址但实际上市面上大量传感器的地址是固定的比如很多 EEPROM 是 0x50很多温湿度传感器是 0x48。你挂两个同型号的芯片地址就撞了。解决办法通常有三个一是选带地址配置引脚的型号通过拉高拉低 ADDR 引脚改变地址二是用 I2C 多路复用器比如 TCA9548A把总线分成 8 路每路挂一个冲突设备三是用软件模拟 I2C把设备分到不同的 GPIO 组上。关于 7 位和 10 位寻址这里有个细节值得说清楚。7 位地址在传输时实际发送的是 8 位——高 7 位是地址最低位是读写标志位0 写 1 读。所以你在代码里写0x50实际线上看到的是0xA0写或0xA1读。很多新手对着逻辑分析仪抓出来的波形一脸懵就是因为没搞清楚这个移位关系。10 位寻址则是用两个字节传地址第一个字节的高 5 位是固定的11110用来和 7 位寻址区分。2.2 上拉电阻的计算不是拍脑袋I2C 是开漏输出SDA 和 SCL 都必须接上拉电阻才能输出高电平。这个电阻选多大是有计算依据的不是随便找个 4.7k 就完事。上拉电阻的上限由上升时间决定。I2C 规范要求标准模式100kHz上升时间不超过 1000ns快速模式400kHz不超过 300ns。上升时间约等于0.847 × R × CC 是总线总电容包括走线、引脚和器件电容。假设总线电容 200pF快速模式下R ≤ 300ns / (0.847 × 200pF) ≈ 1.77kΩ下限则由灌电流能力决定。I2C 器件拉低时能承受的最大电流一般是 3mA所以R ≥ (VDD - VOL) / 3mA3.3V 系统下VOL 取 0.4V则R ≥ 2.9V / 3mA ≈ 967Ω。所以 3.3V、400kHz、200pF 的场景下上拉电阻的合理区间大约是 1k~1.7k。实际选 2.2k 或 4.7k 也能跑但波形上升沿会变缓长走线或高容性负载下就容易出错。我见过太多I2C 时好时坏的案例最后查出来都是上拉电阻偏大加上走线太长。经验如果总线上挂了多个设备电容会累加上拉电阻要相应减小。但也不能太小否则功耗上去了而且有些器件的灌电流能力有限会拉不低。2.3 总线锁死的成因与恢复I2C 最经典的故障是总线锁死从机在发送数据时被复位或干扰导致它一直把 SDA 拉低主机无法发起新的传输。这时候你重启主机都没用因为从机还在占着线。根本原因是 I2C 的状态机在传输中途被打断从机停在某个中间状态。恢复的标准做法是手动发送 9 个时钟脉冲把 SCL 配置成普通 GPIO手动翻转 9 次让从机把剩余的位发完然后发一个 STOP 条件总线就释放了。// 伪代码I2C 总线恢复 void i2c_bus_recover(void) { gpio_set_output(SCL); gpio_set_output(SDA); gpio_write(SDA, 1); for (int i 0; i 9; i) { gpio_write(SCL, 0); delay_us(5); gpio_write(SCL, 1); delay_us(5); } // 发送 STOP 条件SCL 高时 SDA 由低变高 gpio_write(SDA, 0); delay_us(5); gpio_write(SCL, 1); delay_us(5); gpio_write(SDA, 1); delay_us(5); // 恢复 I2C 外设配置 i2c_reinit(); }这个恢复函数建议直接放进你的驱动初始化流程里每次上电先跑一遍能省掉大量偶发不通信的排查时间。另外GT911 这类触摸芯片在 I2C 通信失败时特别容易锁死复位时序没做对的话上电就挂。3. SPI 的实战细节模式、片选与高速走线3.1 CPOL 和 CPHA 组合出的四种模式SPI 有四种工作模式由时钟极性CPOL和时钟相位CPHA组合而成模式CPOLCPHA采样边沿空闲电平Mode 000第一个边沿上升低Mode 101第二个边沿下降低Mode 210第一个边沿下降高Mode 311第二个边沿上升高新手最容易犯的错是模式配错。现象通常是读出来的数据全是 0xFF 或者 0x00或者数据整体移位。因为采样边沿不对采到的全是无效位。排查方法很简单查从机手册确认它支持哪种模式然后主机配成一样的。如果手册没写清楚就四种模式挨个试能读出正确 ID 的那个就是对的。这里有个细节模式 0 和模式 3 最常用因为它们在空闲时 SCK 都是低电平很多器件默认就支持这两个。模式 1 和模式 2 相对少见。3.2 硬件片选与软件片选的取舍SPI 的片选CS有两种实现方式。硬件片选是 MCU 的 SPI 外设自动控制 CS 引脚传输开始拉低、结束拉高时序精准。软件片选则是用普通 GPIO 手动控制传输前后自己拉低拉高。硬件片选的好处是时序精确、CPU 负担小尤其在 DMA 传输时硬件 CS 能保证整个传输过程中 CS 稳定。软件片选的好处是灵活你可以用任意 GPIO而且可以在一次 CS 有效期内穿插多个操作比如先发命令再读数据中间不释放 CS。但软件片选有个坑CS 的建立时间和保持时间。有些器件要求 CS 拉低后要等一段时间才能开始 SCKCS 拉高前也要等最后一个时钟沿稳定。如果你用软件片选但没加延时高速下就可能出错。我一般会在 CS 拉低后加 1~2 个微秒的延时拉高前也加一点虽然牺牲了一点点速度但稳定性提升明显。关于CS 最小能做到多少纳秒这个问题其实取决于从机器件的要求和你的走线质量。理论上 CS 的有效宽度只要覆盖整个传输过程即可但实际中要考虑从机的建立/保持时间要求以及信号完整性。高速场景下CS 走线最好和 SCK 等长避免时序偏差。3.3 高速 SPI 的走线与阻抗问题当 SPI 速率上到几十 MHz它就不再是随便连根线就能通的低速信号了。这时候要把它当传输线来看待。几个关键点走线尽量短最好控制在几厘米以内SCK 和 MOSI/MISO 尽量等长减少时序偏差远离高频干扰源比如开关电源、晶振必要时在源端串一个 22~33Ω 的电阻做阻抗匹配抑制反射。我做过一个 RK3588 的项目SPI 接一块高速 ADC初期用 10MHz 跑没问题提到 50MHz 就疯狂出错。后来用示波器一看SCK 的上升沿有明显的振铃过冲都快到 4V 了。串了 27Ω 电阻、缩短走线之后50MHz 稳定运行。所以高速 SPI 出问题先看波形别急着改代码。4. UART 与 I2S一个求稳一个求准4.1 UART 的波特率误差与帧格式UART 没有时钟线全靠波特率对齐。接收方通常在每位数据的中间采样如果双方波特率有偏差采样点会逐渐偏移偏差累积到半个位宽时就采错了。一般要求波特率误差控制在2% 以内实际工程中最好做到 1% 以内。误差来源有两个一是晶振本身的精度二是分频系数取整带来的误差。比如你用 8MHz 晶振想产生 115200 波特率分频系数是8000000 / 115200 ≈ 69.44取整成 69 后实际波特率是8000000 / 69 ≈ 115942误差约 0.64%可以接受。但如果晶振是 7.3728MHz 这种专门为串口设计的频率分频就是整数误差为零。帧格式方面标准是 1 位起始位、8 位数据位、无校验、1 位停止位俗称 8N1。起始位是下降沿接收方检测到这个下降沿就开始采样。这里有个细节接收方通常会过采样比如 16 倍波特率采样在起始位中间确认有效后再对齐到数据位中间这样抗干扰能力更强。STM32 用 DMA 做 UART 收发时有个经典坑是DMA 接收不知道数据什么时候结束。因为 UART 是异步的DMA 只知道搬数据不知道帧边界。解决办法是用空闲中断IDLE一帧数据接收完后总线会空闲触发 IDLE 中断在中断里处理这一帧。这个组合DMA IDLE是 STM32 串口接收的标准姿势。4.2 I2S 的三线制与音频时序I2S 的核心是三根线BCK位时钟、LRCK帧时钟/字选择、SD数据。BCK 的频率等于采样率 × 位宽 × 声道数。比如 48kHz、16 位、立体声BCK 48000 × 16 × 2 1.536MHz。LRCK 的频率等于采样率它用高低电平区分左右声道。通常 LRCK 低电平是左声道高电平是右声道具体看器件定义。LRCK 的跳变发生在一个位时钟之前也就是说数据在 LRCK 变化后的第二个 BCK 边沿才开始有效这个提前一位的规则是 I2S 标准的一部分很多新手在这里栽跟头。用 ESP32-C3 做 I2S 输出时要注意它的 I2S 外设支持多种模式包括标准 I2S、左对齐、右对齐等。配置的时候要确认你的 DAC 或功放支持哪种格式格式不匹配的话声音会失真或者左右声道颠倒。另外ESP32-C3 的 I2S 引脚是可以矩阵映射的不是固定的这点比很多 MCU 灵活。用逻辑分析仪抓 I2S 波形时重点看三个东西BCK 是否连续稳定、LRCK 的占空比是否接近 50%、SD 上的数据在 BCK 的哪个边沿变化。如果 LRCK 占空比严重偏离 50%说明配置有问题如果数据在错误的边沿变化说明采样边沿配反了。5. 选型决策拿到一个需求该怎么选5.1 按数据速率和实时性筛选选型的第一步是看数据速率需求。我一般这样划分低速、少量数据传感器配置、EEPROM 读写、寄存器操作优先 I2C省引脚。中高速、大数据量ADC 采样、显示屏、Flash优先 SPI。点对点、简单可靠调试、GPS、模块通信优先 UART。音频流只能用 I2S。这里有个容易忽略的点实时性。I2C 是半双工一次传输要经历起始、地址、应答、数据、应答、停止等多个阶段开销大。如果你需要频繁读取一个小数据I2C 的实际吞吐可能远低于标称速率。SPI 全双工没有地址和应答开销连续传输效率高得多。5.2 按引脚预算和设备数量权衡引脚紧张的时候I2C 的优势就体现出来了。两根线挂一堆设备这是 SPI 做不到的。但要注意 I2C 的总线电容限制规范要求总线电容不超过 400pF每个器件的引脚电容大概 10pF 左右走线也有电容。挂太多设备或者走线太长电容超标波形就烂了。SPI 挂多设备时片选线的数量是线性增长的。如果设备超过 4~5 个引脚开销就很可观了。这时候可以考虑用译码器比如 74HC138来扩展片选用 3 根 GPIO 控制 8 个片选能省不少引脚。5.3 一张决策流程图文字版拿到需求后我通常这样走是音频数据吗是 → I2S。需要挂多个设备且速率要求不高吗是 → I2C。需要高速传输或全双工吗是 → SPI。只是点对点简单通信吗是 → UART。以上都不满足考虑组合使用或者用 CAN、SDIO 等其他总线。实际项目中一块板子上同时用这几种总线是常态。比如主控用 I2C 接传感器、SPI 接 Flash、UART 接调试口、I2S 接音频编解码器各司其职互不干扰。6. 调试工具与常见故障速查6.1 逻辑分析仪的正确用法调试这四种总线逻辑分析仪是必备工具。但很多人买了分析仪却不会用抓一堆波形看不懂。几个要点采样率要足够高。根据奈奎斯特定理采样率至少是信号最高频率的 2 倍实际建议 5~10 倍。抓 50MHz 的 SPI采样率至少要 250MHz 以上否则波形全是锯齿根本看不出边沿。触发条件要设对。抓 I2C 可以设 SDA 下降沿触发起始条件抓 SPI 可以设 CS 下降沿触发抓 UART 可以设 RX 下降沿触发。设好触发才能抓到你想看的那一帧。协议解码要用起来。现在的逻辑分析仪软件基本都支持 I2C、SPI、UART、I2S 的协议解码把波形直接翻译成地址、数据、应答比你自己数位快得多。但要注意解码器的参数要设对比如 I2C 的地址位数、SPI 的模式、UART 的波特率设错了解码结果就是错的。6.2 常见故障对照表现象可能原因排查方向I2C 无应答地址错、上拉缺失、器件未上电查地址、量上拉电压、查供电I2C 时好时坏上拉偏大、走线长、电容超标减小上拉、缩短走线、加缓冲I2C 总线锁死从机状态机卡死发 9 个时钟脉冲恢复SPI 读全 0/全 FF模式错、CS 未拉低、MISO 未接查模式、查 CS、查接线SPI 高速出错走线长、无匹配、干扰缩短走线、串匹配电阻、看波形UART 乱码波特率不匹配、晶振误差大核对波特率、换晶振UART 丢数据无流控、中断优先级低加 DMAIDLE、提优先级I2S 无声/失真格式不匹配、LRCK 反相查格式、查 LRCK 极性这张表里的每一条我基本都在实际项目中遇到过。尤其是 I2C 的时好时坏和 SPI 的高速出错这两类问题最耗时间因为它们在实验室常温下可能完全正常一到现场或者一上高温就出问题。所以做产品的时候一定要在极限条件下测试总线通信别只在舒适的实验环境里验证。6.3 一些不太会写在手册里的经验最后分享几个零散但很实用的点I2C 的自由数据模式。有些器件支持一种非标准的 I2C 变体不遵循标准的起始-地址-数据-停止格式而是用自定义的时序。遇到这种器件标准 I2C 外设可能搞不定得用 GPIO 模拟。PMBus 就是基于 I2C 的一个例子它有自己的命令集和时序要求和标准 I2C 有区别。SPI 的菊花链。多个 SPI 从机可以串成菊花链数据从主机发出依次穿过每个从机。这种方式只需要一根 CS能省引脚但要求从机支持菊花链模式而且数据要按顺序组织。ADC 阵列常用这种方式。UART 转其他接口。FT232R、FT231X 这类 USB 转 UART 芯片驱动装好后在系统里就是一个虚拟串口。用 Python 的 pyserial 库可以直接操作做自动化测试很方便。但要注意这类芯片的驱动在不同系统上安装方式不同Linux 下一般内核自带Windows 下要装厂商驱动。I2C 从机主动更新主机寄存器。标准 I2C 是主机发起、从机响应但从机不能主动发起传输。如果从机有事件要通知主机比如传感器检测到阈值只能靠主机轮询或者用一根额外的中断线。有些器件支持 SMBus Alert 机制算是 I2C 的一个扩展。FPGA 接 SPI ADC。FPGA 没有固定的 SPI 外设通常用 Verilog 写状态机实现。好处是时序完全可控可以做到很高的速率坏处是什么都要自己写包括时钟分频、边沿检测、数据对齐。写的时候一定要注意跨时钟域处理ADC 的采样时钟和 FPGA 的系统时钟往往不同源直接采样会有亚稳态风险。Linux 下 I2C 与 MDIO 的复用。有些网络 PHY 芯片的 MDIO 接口可以复用成 I2C但需要配置正确的寄存器。RK3588 这类平台在设备树里配置的时候要注意 pinmux 的设置别把功能搞混了。总线这东西说到底就是在约束下找最优解。没有哪种总线是万能的关键是搞清楚你的需求边界在哪里然后选那个最不别扭的方案。我个人的习惯是能用 I2C 就用 I2C引脚实在不够或者速率实在上不去再换 SPIUART 留给调试和简单外设I2S 只在音频场景出现。这个优先级不是绝对的但大多数项目里都挺好使。