1. 四种总线摆在一起先搞清楚它们各自在解决什么问题嵌入式开发干久了你会发现一个很有意思的现象新手选通信接口往往看哪个名字顺眼、哪个例程多就用哪个而老手选接口脑子里过的是一张表——距离、速率、引脚数、拓扑结构、抗干扰能力、协议开销。I2C、I2S、SPI、UART这四个名字经常被放在一起比较但它们其实压根不是同一个维度的东西。把它们硬拉到一张桌子上对比就像拿螺丝刀、扳手、电烙铁、万用表比哪个工具更好用——答案永远是看你要干什么活。我见过太多项目在选型阶段就埋了雷。有人用I2C去驱动需要持续高速采样的ADC结果总线带宽被占满其他传感器全部超时有人用UART去连音频编解码器发现根本对不上时序还有人用SPI接了一堆从设备片选引脚多到GPIO不够用。这些问题的根源都是没有在动手之前把四种总线的本质差异想清楚。这篇文章不打算写成一份协议手册那种东西网上到处都是。我想做的是把四种总线放在真实的工程场景里讲清楚它们各自的设计哲学、适用边界、以及在实际项目中容易踩的坑。无论你是在做传感器采集、音频处理、存储扩展还是设备间通信看完之后应该能形成一个清晰的判断什么场景该用什么总线为什么。关键词里出现了STM32F103、DMA、CubeMX、逻辑分析仪、上拉电阻、片选方式这些具体的技术点说明读者大概率是正在做实际项目的嵌入式工程师或学生。所以下面的内容会尽量贴近实操该给参数给参数该讲原理讲原理该说坑说坑。2. I2C两根线撑起一个传感器网络但别指望它跑得快2.1 开漏输出加外部上拉这个设计到底图什么I2C最让人困惑的一点就是为什么SDA和SCL必须用开漏输出还要外接上拉电阻。很多人照着例程接上4.7k电阻能用就行从来没想过为什么。但一旦遇到上拉电阻小了不通信或者上拉电阻大了波形爬不上去的问题就抓瞎了。开漏输出的本质是引脚只能主动拉低不能主动拉高。拉高这件事交给外部上拉电阻来完成。这个设计带来的第一个好处是多设备共享总线不会短路。假设总线上挂了8个设备如果都用推挽输出一个设备输出高、另一个输出低直接就是电源到地的短路芯片当场冒烟。开漏输出则天然实现了线与逻辑——只要有一个设备拉低总线就是低电平谁也不会烧。第二个好处是电平转换变得极其简单。3.3V的MCU和5V的传感器挂在同一根I2C总线上上拉电阻分别接到各自的电源轨总线电平自然兼容。这也是为什么I2C在混合电压系统里如此受欢迎。上拉电阻的取值是个需要算的活。阻值太大上升沿变缓高速通信时波形还没爬到高电平阈值就被拉低了通信直接失败阻值太小灌电流过大开漏输出的MOS管可能扛不住而且功耗也上去了。经验公式是这样的上升时间Tr约等于0.8473乘以R乘以C其中C是总线电容。标准模式100kHz下Tr要求小于1000ns快速模式400kHz下要求小于300ns。假设总线电容200pF快速模式下R最大约1.77k所以4.7k在400kHz下其实已经偏大了。很多100k I2C信号规格的讨论就是在纠结这个。实操建议标准模式100kHz用4.7k没问题快速模式400kHz建议降到2.2k甚至1.8k高速模式1MHz以上要考虑有源上拉。总线电容超过400pF就得考虑用I2C缓冲器或者分segment了。2.2 时序图里的START、ACK、STOP每个都有讲究I2C的时序图看起来复杂但核心就几个关键点。START条件是SCL为高时SDA从高变低STOP条件是SCL为高时SDA从低变高。注意这两个条件都要求SCL处于高电平这是I2C协议里唯一允许SDA在SCL高电平期间变化的情况其他时候SDA必须在SCL低电平期间改变。ACK应答机制是I2C可靠性的基石。每传输8位数据后接收方必须把SDA拉低一个时钟周期表示应答。如果主机发完地址后没收到ACK说明从设备不在线或者地址错了。这个机制让I2C天然具备设备探测能力——你可以通过扫描地址来发现总线上挂了哪些设备这是SPI和UART都不具备的。数据帧格式上标准I2C传输是START 7位地址 读写位 ACK 8位数据 ACK ... STOP。每次传输的数据字节数没有硬性限制由主机控制。但要注意很多从设备对连续读写有要求比如EEPROM的页写不能跨页超过页边界会回卷覆盖。我当年调I2C读写EEPROM的Verilog代码时就在页边界上栽过跟头写了两天数据发现只有最后一页是完整的。2.3 100k、400k、1M速率上去了问题也跟着来I2C标准模式100kHz、快速模式400kHz、快速模式1MHz、高速模式3.4MHz。速率越高对总线电容和上拉电阻的要求越苛刻。实际项目中400kHz是性价比最高的选择大部分传感器都支持。1MHz以上就要仔细评估PCB走线电容了。I2C最大的短板是半双工和带宽有限。同一时刻只能有一个方向传输而且协议开销大地址、ACK、START、STOP。用它来传大量数据比如从FIFO里连续读几百字节效率很低。所以I2C的定位很明确低速控制总线和传感器网络。温度传感器、加速度计、EEPROM、IO扩展芯片、PMBus电源管理这些场景I2C是首选。PMBus本质上就是基于I2C的电源管理协议加了特定的命令集。还有一个容易忽略的点I2C是多主多从架构支持时钟同步和仲裁。多个主机同时发起传输时通过线与逻辑自动仲裁输的那个自动退出。这个特性在冗余系统里有用但实际项目中很少用到大部分时候都是一个主机带一堆从机。3. SPI速度是王道但引脚数量和片选管理是代价3.1 四根线的全双工为什么能跑到几十兆SPI的设计哲学和I2C完全相反。I2C用最少的线换最大的设备容量SPI用更多的线换更高的速度。四根线SCLK、MOSI、MISO、CS。全双工主机和从机可以同时收发。没有地址概念靠片选信号选设备。没有ACK机制可靠性靠上层协议保证。SPI能跑这么快的原因有几个。首先是推挽输出上升下降沿都很陡不像I2C那样受上拉电阻限制。其次是没有协议开销数据直接移位进出不需要地址、ACK这些额外时钟周期。第三是时钟极性相位可配置CPOL和CPHA组合出四种模式适配不同厂家的从设备。STM32F103的硬件SPI最高能到18MHzAPB2时钟72MHz的4分频实际项目中跑到10MHz以上很常见。SPI Flash、SD卡、显示屏、高速ADC这些需要大数据量传输的场景SPI是绝对主力。像RTL9071CP-VB这类芯片用SPI加载固件就是看中了SPI的速度和简单性。3.2 硬件片选和软件片选选哪个不是拍脑袋SPI的片选信号有两种管理方式。硬件片选是SPI外设自动控制CS引脚传输开始拉低结束拉高。软件片选是GPIO手动控制代码里自己拉低拉高。硬件片选的好处是时序精确不占用CPU干预DMA传输时尤其方便。坏处是片选引脚必须接到SPI外设指定的NSS引脚上不够灵活。软件片选的好处是任意GPIO都能用多个从设备可以灵活管理坏处是每次传输前后要手动操作GPIODMA连续传输多个从设备时比较麻烦。实际项目中如果只有一个从设备硬件片选最省事。如果有多个从设备通常用软件片选每个设备一个GPIO。但要注意软件片选时CS的拉低和拉高时机要精确控制拉低太早或拉高太晚都可能导致数据错误。我见过一个案例SPI通信不生效查了半天发现是CS拉高太早最后一个字节还没移完就被终止了。注意SPI从设备的CS建立时间和保持时间要查数据手册。有些Flash要求CS拉低后至少等100ns才能发时钟有些ADC要求最后一个时钟后CS保持低电平至少50ns。这些参数不满足通信时好时坏很难查。3.3 STM32F103上用DMA驱动SPI读数据CubeMX配置的几个关键项用STM32F103的SPI通过DMA读取芯片数据CubeMX里几个配置项容易搞错。首先是DMA方向SPI接收用DMA1通道2或通道3SPI1_RX发送用通道3或通道2SPI1_TX具体看参考手册的DMA请求映射表。其次是DMA模式单次传输用Normal连续采集用Circular。第三是数据宽度SPI数据寄存器是16位的但实际有效位可能是8位或16位DMA的Memory和Peripheral数据宽度要对应设置。还有一个坑是SPI的TX和RX DMA要同时配置。SPI是全双工的即使你只想接收数据发送DMA也得开否则时钟不会产生。通常做法是发送DMA发一个dummy字节接收DMA同时收数据。或者用SPI的只接收模式BIDIMODE但STM32F103的SPI只接收模式配置起来比较绕不如直接双线全双工加dummy发送来得简单。半双工SPI比如某些单线传感器在STM32上配置更麻烦需要切换BIDIMODE和BIDIOE。我一般建议能用全双工就用全双工省心。3.4 片选一多GPIO就不够用了怎么办SPI最大的痛点就是片选引脚数量。挂8个从设备就要8个GPIO做片选加上SCLK、MOSI、MISO一共11根线。如果MCU的GPIO紧张这就很头疼。解决方案有几个。一是用译码器比如74HC1383根GPIO译出8个片选省5个引脚。二是用SPI扩展芯片比如某些带多路片选输出的专用芯片。三是用菊花链多个从设备串在一起数据依次移位但只适用于支持菊花链的设备比如某些LED驱动和ADC。四是用I2C转SPI的桥接芯片把SPI设备挂到I2C总线上牺牲速度换引脚。选哪种方案取决于你的速率要求和成本预算。译码器最便宜但片选切换有延迟菊花链最省引脚但设备必须支持桥接芯片最灵活但增加成本。4. UART最古老的接口却也是最难用好的接口4.1 异步通信的代价波特率、起始位、停止位UART和I2C、SPI最大的区别是异步。没有时钟线收发双方靠约定的波特率来同步。这就带来一个问题波特率误差。如果发送方和接收方的波特率偏差超过一定范围通常是3%到5%通信就会出错。UART的数据帧是起始位1位低电平 数据位5到9位 校验位可选 停止位1到2位。起始位的作用是告诉接收方数据来了接收方检测到下降沿后开始按波特率采样。停止位的作用是给接收方一个缓冲时间准备接收下一帧。UART的波形分析是调试的基本功。用逻辑分析仪抓UART波形首先要确认波特率对不对。测量一个位的时间宽度取倒数就是波特率。比如位宽8.68微秒波特率就是115200。然后看起始位是不是干净的下降沿数据位是不是稳定的高低电平停止位是不是高电平。如果波形毛刺多可能是线太长、干扰大或者地线没接好。4.2 阻塞、中断、DMA三种收发方式怎么选UART的收发方式直接决定了CPU的占用率。阻塞方式最简单发一个字节等一个字节收一个字节等一个字节。适合低速、数据量小的场景比如调试打印。但如果在主循环里阻塞收数据整个系统就被卡住了。中断方式在收到一个字节或发完一个字节时触发中断CPU在中断里处理数据。比阻塞灵活但数据量大时中断频繁CPU开销也不小。115200波特率下每个字节约87微秒如果连续收数据中断频率约11.5kHz对CPU来说负担不小。DMA方式是数据量大的首选。DMA自动把数据从外设搬到内存或者从内存搬到外设CPU只需要在传输完成后处理。STM32F103的标准库UART DMA中断接收发送通信配置起来有几个关键点DMA接收要用Circular模式配合空闲中断IDLE因为DMA不知道数据什么时候结束空闲中断可以检测总线空闲然后处理已接收的数据。DMA发送用Normal模式发送完成后在中断里做后续处理。实操心得UART DMA接收一定要开IDLE中断。我见过很多人用DMA接收但不开IDLE结果数据收了一半不知道处理的时候长度不对。IDLE中断配合DMA的剩余计数可以精确算出收到了多少字节。4.3 FT231X这类USB转UART芯片驱动装不上怎么办FT231X是FTDI的USB转UART芯片在开发板上很常见。Windows下驱动装不上通常有几个原因。一是系统自动装的驱动版本太老去FTDI官网下最新的VCP驱动。二是芯片的VID/PID被改过需要手动指定驱动。三是USB线质量差枚举都过不了。Linux下一般内核自带ftdi_sio驱动插上就能用。但如果被brltty之类的服务抢占了会看到ttyUSB0出现又消失。解决办法是卸载brltty或者加udev规则屏蔽。还有一点FT231X支持多种电平3.3V、5V接线前确认开发板的UART电平。3.3V的MCU接5V的UART长期用可能损坏IO口。虽然很多人这么干也没事但规范做法是加电平转换或者用支持双电压的转接板。5. I2S音频专用别拿它当普通串口用5.1 和I2C一字之差但完全是两码事I2SInter-IC Sound和I2C名字很像但没有任何关系。I2S是专门为数字音频设计的接口传输PCM音频数据。它至少有三根线SCK位时钟、WS声道选择也叫LRCK、SD数据。有时候还有MCLK主时钟给编解码器提供参考时钟。I2S的时序和I2C完全不同。WS信号指示当前传输的是左声道还是右声道SCK每个脉冲移一位数据。数据通常是MSB先传左对齐或右对齐取决于格式。I2S的标准格式是WS变化后第二个SCK边沿开始传数据但也有很多变种左对齐、右对齐、DSP模式接不同厂家的编解码器时要仔细看数据手册。I2S的速率由采样率和位深决定。比如44.1kHz采样率、16位位深、双声道SCK频率就是44100乘以16乘以2等于1.4112MHz。如果MCLK是SCK的256倍就是36.16MHz。这些时钟关系必须匹配否则音频会变调或者全是噪声。5.2 音频项目里I2S和I2C经常一起出现一个典型的音频系统里I2S传音频数据I2C配编解码器的寄存器。比如WM8960、ES8388这些编解码芯片I2C用来设置采样率、增益、输入输出通道I2S用来传实际的音频流。所以你会看到同一个项目里既有I2C又有I2S它们各司其职。调试I2S最常见的问题是没声音或者噪声大。排查顺序是先确认MCLK有没有输出很多编解码器没有MCLK就不工作再确认I2S的格式对不对左对齐还是右对齐位深是16还是24最后确认I2C配置有没有写进去用逻辑分析仪抓I2C波形看ACK。我遇到过一次声音全是噪声查了半天发现是I2S的WS极性反了左右声道颠倒导致相位抵消。6. 把四种总线放进同一张表选型时不再纠结6.1 关键参数横向对比特性I2CSPIUARTI2S线数2SDA、SCL4SCLK、MOSI、MISO、CS2TX、RX3到4SCK、WS、SD、MCLK双工半双工全双工全双工全双工音频流速率100k到3.4M几M到几十M通常到几M取决于采样率几M拓扑多主多从一主多从点对点点对点寻址7位或10位地址片选无无时钟同步同步异步同步可靠性机制ACK无校验位无典型场景传感器、EEPROM、PMBusFlash、显示屏、ADC调试、模块通信音频编解码6.2 选型决策树从场景倒推接口选接口的时候我习惯按这个顺序问自己几个问题。第一数据量多大如果是几十字节的控制命令I2C和UART都行。如果是几百KB的固件、图像数据SPI是唯一选择。如果是音频流I2S专用。第二设备数量多少一个设备用UART最简单。多个设备用I2C省引脚用SPI速度快但片选多。第三速率要求多高100kHz以下I2C够用1MHz以上考虑SPI。UART的速率取决于波特率和线材质量一般115200到921600是常见范围。第四距离多远板内通信用I2C、SPI、I2S。板间通信UART更合适加个RS485还能跑更远。I2C和SPI不适合长距离电容和干扰会让波形烂掉。第五有没有现成外设STM32F103有2个SPI、2个I2C、3个USART、2个I2SSPI复用。如果外设不够用要么换芯片要么用软件模拟bit-banging但软件模拟速率上不去。6.3 那些看起来能用但实际会坑的场景有些场景看起来随便选个接口都能用但实际做起来会发现只有一个选择是对的。比如用I2C接OLED显示屏。SSD1306支持I2C和SPI两种模式I2C省引脚但刷新率上不去全屏刷新要几十毫秒动画会卡。SPI刷新快但多两根线。如果做静态显示I2C够用如果做动画SPI是必须的。再比如用UART接多个传感器。UART是点对点的多个传感器要么用多个UART要么加多路复用器要么让传感器支持地址像Modbus那样。如果传感器只支持UART且没有地址那就只能一个UART对一个传感器MCU的UART数量很快就不够了。还有用SPI接多个不同速率的设备。SPI的时钟是主机控制的不同从设备支持的最高速率不同。如果总线上挂了一个10MHz的Flash和一个1MHz的传感器要么分时切换时钟要么都降到1MHz。分时切换时钟在代码里要小心处理切换前要确保当前传输完成。7. 调试工具和方法逻辑分析仪是绕不开的7.1 用逻辑分析仪抓I2C、SPI、UART的实战要点逻辑分析仪是调试这四种总线最实用的工具。抓I2C的时候触发条件设成START条件SCL高时SDA下降沿采样率至少是总线速率的10倍400kHz的I2C建议用10MHz以上采样率。解码器选I2C设置好地址位宽就能看到每个字节和ACK。抓SPI的时候触发条件设成CS下降沿采样率要高于SCLK频率的4倍以上。解码器选SPI设置CPOL、CPHA、位序、位宽。如果解码出来的数据不对先检查CPOL和CPHA是不是和从设备匹配。抓UART的时候触发条件设成RX下降沿采样率要足够高以准确测量位宽。解码器选UART设置波特率、数据位、校验位、停止位。如果解码乱码先确认波特率再确认电平极性有些UART是反相的。注意逻辑分析仪的探头地线一定要接好。地线太长或者没接波形全是振铃和毛刺根本没法看。我一般用弹簧地针尽量短。7.2 没有逻辑分析仪时的替代方案不是每个人都有逻辑分析仪替代方案也有几个。示波器可以看波形质量但解码能力弱。有些高端示波器带I2C/SPI解码选件但价格贵。软件层面可以在代码里加打印把收发的数据通过另一个UART打出来。虽然不能看时序但能确认数据内容对不对。还可以用GPIO翻转来标记关键节点配合示波器看时序关系。最土的办法是LED指示。发送前亮灯发送后灭灯虽然信息量少但能确认代码有没有跑到那个位置。我早期调试I2C的时候就是靠LED判断程序卡在哪一步。8. 几个真实项目里的踩坑记录8.1 I2C上拉电阻小了不通信的排查过程有个项目用STM32F103的I2C接一个温湿度传感器原理图上上拉电阻是4.7k但实际焊接的是1k。上电后I2C完全没反应用逻辑分析仪看SCL和SDA都是低电平。一开始怀疑是传感器坏了换了一个还是不行。后来量电阻发现是1k换成4.7k后正常。原因很简单1k上拉电阻太小开漏输出的MOS管灌电流太大可能触发了保护或者压降太大导致低电平不够低。I2C的低电平要求是0.3VDD以下1k上拉时如果MOS管导通电阻不够小低电平可能到不了0.3VDD以下从设备识别不到有效的低电平。这个坑的教训是原理图和实际物料要核对。很多批量生产的问题都是物料替换引起的4.7k换成1k可能是采购觉得1k更常见。8.2 SPI通信不生效最后发现是CS时序问题另一个项目用SPI接一个ADC代码是从另一个项目抄过来的那个项目用的是硬件片选这个项目用的是软件片选。结果SPI时钟和数据都正常但读出来的数据全是0xFF。用逻辑分析仪抓波形发现CS在最后一个时钟上升沿之前就拉高了。ADC要求CS在最后一个时钟后保持低电平至少20ns但代码里是发完数据立刻拉高CS中间没有延时。加了一个几微秒的延时后正常。这个坑的教训是软件片选要手动加延时。硬件片选由外设自动控制时序有保证。软件片选全靠代码容易忽略建立时间和保持时间。8.3 UART DMA接收数据长度不对的解决STM32F103用UART DMA接收不定长数据配置了DMA Circular模式和UART IDLE中断。但发现有时候数据长度不对偶尔多几个字节偶尔少几个字节。排查后发现两个问题。一是IDLE中断里读DMA剩余计数之前没有先清除IDLE标志导致中断重复触发。二是DMA的缓冲区在中断里被读取时DMA可能还在写产生了竞争。解决办法是在IDLE中断里先关DMA读计数处理数据再重新配置DMA。这个坑的教训是DMA和中断的配合要小心竞争条件。DMA是硬件在搬数据CPU读的时候DMA可能还在写必须用适当的方式同步。9. 给正在选型的你几句实在话四种总线没有优劣之分只有合不合适。I2C适合低速传感器网络SPI适合高速数据流UART适合点对点通信和调试I2S专攻音频。选型的时候先想清楚数据量、设备数量、速率要求、距离限制这四个维度答案基本就出来了。实际项目中这四种总线经常混用。一个典型的STM32F103项目可能同时用I2C接EEPROM和传感器SPI接Flash和显示屏UART做调试和模块通信I2S接音频编解码器。关键是每种总线用在它最擅长的地方不要为了省引脚或者图省事把不合适的总线硬塞到不合适的场景里。最后说一个个人习惯每次画原理图的时候把每种总线的上拉电阻、片选引脚、电平匹配都单独检查一遍。这些地方出错调试起来最费时间。硬件的问题软件再怎么改也解决不了。