1. 三种通信协议到底该怎么选嵌入式开发干久了总会遇到同一个问题手头这个传感器或者模块到底该用SPI、UART还是I2C去接。新手往往看哪个引脚少就用哪个或者照着模块手册上的推荐直接抄结果项目做到一半发现速率不够、设备挂不上、通信偶尔丢包回头再改硬件已经来不及了。我自己就踩过这种坑早期做一个多传感器采集板图省事把三个I2C设备挂在同一条总线上结果其中一个设备频繁拉低时钟线导致整条总线锁死排查了整整两天才定位到是上拉电阻阻值不匹配的问题。这篇文章就是想把SPI、UART、I2C这三种最常用的板级通信协议拉出来做一次彻底的横向对比。不光是列参数表格而是从电气特性、协议开销、拓扑结构、实际布线、软件驱动复杂度这几个维度把每种协议的适用边界讲清楚。不管你是刚接触单片机的新手还是做了几年项目想系统梳理一下选型逻辑的老手应该都能从中找到对自己有用的东西。全文会围绕“什么场景下该选谁”这个核心问题展开附带大量实操中的参数计算和避坑经验。2. 三种协议的核心机制拆解2.1 SPI速度优先的“四线制”方案SPI的全称是Serial Peripheral Interface中文叫串行外设接口。它的物理层非常直白四根线SCLK负责时钟MOSI是主机输出从机输入MISO是主机输入从机输出CS是片选。通信的时候主机拉低对应从机的CS线然后在SCLK的每个时钟沿上同时完成一位数据的收发。因为是全双工发送和接收是同步进行的你发一个字节出去的同时也会收到一个字节回来。SPI最核心的优势就是快。理论上速率只受限于器件支持和走线质量做到几十MHz甚至上百MHz都很常见。我实测过某款Flash芯片在SPI模式下跑到50MHz时钟连续读取速率能到6MB/s以上换成I2C的话连十分之一都不到。但代价也很明显每增加一个从机就要多一根CS线引脚消耗大没有硬件级的应答机制主机发了数据从机有没有收到全靠协议层自己保证也没有标准的总线仲裁多主机场景基本不用考虑。从协议开销来看SPI几乎没有额外开销。你发多少位就是多少位没有起始位、停止位、地址帧这些东西。这意味着在需要高速连续传输的场景下SPI的效率是最高的。但反过来因为没有地址机制主机只能通过CS线来区分从机软件上需要为每个从机单独管理CS引脚。2.2 UART最“古老”也最灵活的异步方案UART的全称是Universal Asynchronous Receiver/Transmitter通用异步收发器。注意“异步”两个字这是它和SPI、I2C最本质的区别。UART没有时钟线收发双方靠预先约定好的波特率来同步。一帧数据由起始位、数据位、校验位、停止位组成典型的配置是1位起始位、8位数据位、无校验、1位停止位也就是常说的“8N1”。因为没有时钟线UART只需要两根线TX和RX。如果只需要单向通信一根线就够了。这种极简的连线方式让UART在调试串口、模块通信场景中几乎无处不在。你拿到任何一个开发板上面大概率会有一个UART接口用来打印日志。但异步带来的问题是波特率误差。收发双方的波特率必须足够接近否则在帧末尾采样就会错位。一般要求误差控制在2%以内高速率下要求更严。我遇到过用内部RC振荡器做时钟源跑115200波特率结果因为温漂导致通信偶尔出现乱码的情况后来换成外部晶振就稳定了。所以UART对时钟精度的要求其实比很多人想象的要高。UART的另一个特点是点对点。它没有总线概念两个设备之间直接连。如果要多个设备通信要么用多个UART口要么外挂RS485之类的收发器做总线。软件层面UART的驱动最简单配置好波特率、数据位、停止位就能收发不需要处理地址、片选这些逻辑。2.3 I2C两根线挂一堆设备的“总线型”方案I2C的全称是Inter-Integrated Circuit读作“I方C”或者“I平方C”都行。它的物理层只有两根线SDA是数据线SCL是时钟线。两根线都是开漏输出需要外接上拉电阻。所有设备都并联在这两根线上每个设备有唯一的7位地址也有10位地址的扩展模式。I2C的通信流程比前两者复杂一些。主机发起始条件SCL高时SDA拉低然后发送7位地址加1位读写标志从机如果地址匹配就拉低SDA在第9个时钟周期给出应答。之后就是数据字节的传输每个字节后面跟一个应答位。通信结束时主机发停止条件SCL高时SDA拉高。I2C最大的优势是引脚少、可挂设备多。两根线理论上可以挂128个7位地址的设备实际受电容负载限制一般挂几个到十几个。这在传感器密集的场景下非常香比如一个环境监测节点上挂温湿度、气压、光照三四个传感器用I2C只需要两根线加两根上拉电阻就搞定。但I2C的速率是三者中最低的。标准模式100kHz快速模式400kHz高速模式3.4MHz但实际很少用到。而且因为是开漏输出加外部上拉上升沿的斜率受RC时间常数影响总线电容大了波形就上不去。我实测过在一条挂了8个设备的I2C总线上用4.7kΩ上拉跑400kHz上升沿已经接近1μs勉强能用但余量很小。后来把上拉降到2.2kΩ才把波形修好但功耗也上去了。3. 关键参数横向对比与选型逻辑3.1 速率、引脚数与拓扑结构对照先上一张表把三种协议最核心的几个参数拉齐了看。对比项SPIUARTI2C线数4线SCLK/MOSI/MISO/CS2线TX/RX2线SDA/SCL拓扑一主多从每从机一根CS点对点一主多从地址寻址典型速率10-100MHz9.6k-921.6kbps100k-400kHz双工方式全双工全双工半双工时钟同步主机提供异步双方约定同步主机提供应答机制无无可加校验位有每字节ACK/NACK引脚开销高每从机1低极低多主机不支持不支持支持仲裁这张表里的数据是典型值实际会因器件和布线有出入。比如SPI在长走线或者隔离场景下可能只能跑几MHz而I2C在短距离、低电容负载下也能跑到1MHz以上。但整体趋势是明确的SPI快但费引脚UART简单但只能点对点I2C省引脚但慢且对总线参数敏感。选型的时候我一般按这个优先级来先看速率需求如果单次传输数据量大或者实时性要求高直接上SPI如果只是配置寄存器、读传感器数据这种小数据量场景I2C优先如果是两个设备之间的板间通信或者调试口UART最省事。然后再看引脚资源引脚紧张就尽量用I2C引脚富裕就SPI随便造。最后看拓扑多设备就SPI或I2C点对点就UART。3.2 电气特性与布线约束三种协议的电气特性差异很大这直接决定了PCB布线和线缆选择的策略。SPI是推挽输出驱动能力强上升沿陡峭所以走线可以相对长一些。但高速SPI要注意阻抗匹配和串扰尤其是时钟线。我一般会在SCLK上串一个22Ω到33Ω的电阻来抑制过冲走线尽量等长远离模拟信号。如果SPI速率超过20MHz最好走差分或者至少保证完整的参考地平面。UART也是推挽输出但速率低布线要求最宽松。TTL电平的UART在板内通信基本不用考虑阻抗问题直接连就行。如果要出板子比如通过排线连到另一个设备建议加TVS管做防护线缆长度超过30cm的话考虑用RS232或RS485收发器转一下。I2C是开漏输出这是它布线最麻烦的地方。开漏意味着只能拉低不能拉高高电平全靠外部上拉电阻。总线上的设备越多、走线越长等效电容就越大上升时间就越长。I2C规范里对上升时间有明确要求标准模式不超过1000ns快速模式不超过300ns。上升时间约等于0.847×R×CR是上拉电阻C是总线电容你可以用这个公式反推上拉电阻的最大值。举个例子假设总线电容实测200pF快速模式要求上升时间小于300ns那么R最大约等于300ns/(0.847×200pF)≈1.77kΩ。也就是说上拉电阻不能大于1.77kΩ否则上升沿就超标了。但上拉电阻也不能太小否则低电平时灌电流太大可能超过器件的驱动能力。一般I2C器件的灌电流能力在3mA左右3.3V供电下上拉电阻最小约1.1kΩ。所以实际可选范围很窄常见取值是2.2kΩ到4.7kΩ。注意I2C总线上拉电阻的选型是很多新手容易忽略的点。阻值大了波形上不去阻值小了功耗大且可能烧器件。建议先用示波器实测上升时间再根据公式调整。3.3 协议开销与有效吞吐率计算很多人选型只看标称速率忽略了协议开销结果实际吞吐率差很多。这里我拿实际数据算一下。SPI传1KB数据假设时钟10MHz没有额外开销理论时间约0.82ms有效吞吐率约1.22MB/s。实际因为软件开销和CS切换打个八折大概1MB/s左右。UART传1KB数据波特率1152008N1格式意味着每字节实际传输10位1起始8数据1停止。1KB是1024字节总共10240位时间约88.9ms有效吞吐率约11.5KB/s。如果换成921600波特率时间约11.1ms吞吐率约92KB/s。可以看到UART的协议开销是固定的20%10位传8位数据这个开销无法避免。I2C传1KB数据快速模式400kHz每字节传输需要1个地址字节假设只发一次地址然后连续读 数据字节 每字节1个ACK位。实际每字节9位加上起始停止条件。粗略算下来1KB数据大约需要1024×9/400000≈23ms有效吞吐率约44.5KB/s。如果算上地址帧和重复起始条件还要再低一些。这个计算说明一个问题SPI的有效吞吐率比I2C高一个数量级以上UART在低波特率下更是慢得感人。所以如果你要传图像、音频或者大量日志数据SPI是唯一选择。如果只是读几个传感器寄存器I2C的速率完全够用。4. 实操配置与驱动实现要点4.1 SPI的配置流程与片选管理以常见的STM32系列MCU为例配置SPI的步骤大致如下。首先使能SPI外设时钟和对应GPIO时钟然后配置SCLK、MOSI、MISO为复用推挽输出CS如果由软件控制就配成普通推挽输出。接着设置SPI参数主机模式、时钟极性CPOL和时钟相位CPHA要根据从机手册来定常见的是CPOL0、CPHA0也就是空闲低电平、第一个时钟沿采样。数据位宽一般8位MSB先行。波特率预分频根据系统时钟和目标速率算比如系统时钟72MHz目标10MHz预分频系数取8实际速率9MHz。CS的管理是个容易出问题的地方。如果多个从机共享SPI总线每个从机一根CS软件上要在每次传输前拉低对应CS传输完拉高。注意CS的拉低和拉高之间要留足够的建立时间和保持时间一般从机手册会给出具体数值常见的是几十纳秒。我见过有人CS切换太快导致从机还没准备好就发时钟数据直接错位。// SPI发送一个字节的典型流程 void SPI_WriteByte(uint8_t data) { while(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) RESET); SPI_I2S_SendData(SPI1, data); while(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) RESET); SPI_I2S_ReceiveData(SPI1); // 读走接收寄存器防止溢出 }提示SPI是全双工发送的同时也在接收。如果你只发不收记得把接收寄存器读走否则溢出标志会置位影响后续传输。4.2 UART的波特率计算与中断接收UART的波特率计算是新手最容易出错的地方。以STM32为例波特率寄存器USART_BRR的值等于系统时钟除以波特率。比如系统时钟72MHz目标波特率115200BRR72000000/115200≈625实际波特率72000000/625115200误差0%。如果系统时钟是8MHz内部RCBRR8000000/115200≈69.44取整69实际波特率8000000/69≈115942误差约0.64%在可接受范围内。但如果用内部RC且温漂大误差可能超过2%通信就会不稳定。UART接收建议用中断或者DMA。中断方式下每收到一个字节进一次中断把数据存入环形缓冲区主循环再从缓冲区取数据处理。DMA方式更适合高速率或者大数据量场景配置好DMA通道后UART收到数据自动搬到内存完全不占CPU。// UART中断接收的环形缓冲区实现片段 #define RX_BUF_SIZE 256 uint8_t rx_buf[RX_BUF_SIZE]; volatile uint16_t rx_head 0, rx_tail 0; void USART1_IRQHandler(void) { if(USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { uint8_t data USART_ReceiveData(USART1); uint16_t next (rx_head 1) % RX_BUF_SIZE; if(next ! rx_tail) { // 缓冲区未满 rx_buf[rx_head] data; rx_head next; } USART_ClearITPendingBit(USART1, USART_IT_RXNE); } }4.3 I2C的时序控制与总线恢复I2C的驱动实现比前两者复杂因为要手动处理起始条件、地址帧、应答位、停止条件这些时序。很多MCU有硬件I2C外设但硬件I2C在不同厂商的芯片上表现差异很大有的有已知的勘误问题所以不少老手宁愿用GPIO模拟I2C。GPIO模拟I2C的关键是延时控制。标准模式100kHz意味着每个时钟周期10μs半周期5μs。你需要用精确的延时函数来保证SCL高电平和低电平的时间。延时太短速率上不去延时太长速率不够。我一般用NOP循环或者定时器来做微秒级延时具体循环次数要根据MCU主频实测调整。// GPIO模拟I2C的起始条件 void I2C_Start(void) { SDA_OUT(); SDA_HIGH(); SCL_HIGH(); delay_us(4); SDA_LOW(); delay_us(4); // SCL高时SDA拉低起始条件 SCL_LOW(); delay_us(4); } // 发送一个字节并读取应答 uint8_t I2C_SendByte(uint8_t data) { for(uint8_t i 0; i 8; i) { if(data 0x80) SDA_HIGH(); else SDA_LOW(); data 1; delay_us(2); SCL_HIGH(); delay_us(4); SCL_LOW(); delay_us(2); } SDA_IN(); // 释放SDA准备读应答 SCL_HIGH(); delay_us(4); uint8_t ack SDA_READ(); // 0表示应答 SCL_LOW(); delay_us(4); SDA_OUT(); return ack; }I2C还有一个经典问题总线锁死。如果主机在发送过程中复位而从机还在等待时钟SDA可能被从机拉低不放导致总线无法发起始条件。恢复方法是在SCL上手动发9个时钟脉冲让从机把剩余的数据位发完并释放SDA然后发一个停止条件。这个技巧在实际项目中救过我很多次。注意I2C总线锁死的恢复逻辑建议放在初始化函数里每次上电先执行一次总线恢复避免上次异常复位留下的状态影响本次通信。5. 典型应用场景与选型案例5.1 传感器采集I2C的主场温湿度传感器、气压计、加速度计、陀螺仪、光照传感器这些低速小数据量的器件绝大多数都提供I2C接口。原因很简单它们的数据量小几个到几十个字节更新率低几Hz到几百HzI2C的速率完全够用而且两根线就能挂一堆PCB布局非常清爽。我做过一个环境监测节点上面挂了SHT30温湿度、BMP280气压、BH1750光照三个传感器全部走I2C。三个传感器地址不同挂在同一条总线上MCU只需要两根引脚。初始化的时候依次配置每个传感器的寄存器然后定时轮询读取。整个采集周期100msI2C总线占用率不到5%余量非常大。但这里有个坑不同传感器的I2C时序参数可能不一样。比如SHT30支持时钟拉伸BMP280不支持。如果你的驱动没有正确处理时钟拉伸在某些时序边界上可能读到错误数据。我的做法是在驱动层为每个传感器单独配置超时和重试逻辑读失败就重试三次三次都失败才报错。5.2 存储与显示SPI的天下SPI Flash、SD卡、TFT显示屏、OLED显示屏这些需要高速数据传输的器件基本都是SPI接口。以TFT显示屏为例刷一屏240×320的RGB565图像需要240×320×2153600字节。如果用I2C 400kHz传输光数据就要3.4秒根本没法看。用SPI 40MHz的话153600×8/40000000≈30.7ms刷屏流畅度可以接受。SPI Flash也是类似。固件升级、文件系统、数据日志这些场景需要频繁读写大块数据SPI的速率优势非常明显。我实测过某款SPI Flash在50MHz时钟下连续读取速率能到5MB/s以上写速率受限于Flash的编程时间大概几百KB/s但也比I2C快得多。用SPI接多个器件时CS的管理要特别注意。如果SPI总线上同时挂了Flash和显示屏两个器件的SPI模式可能不同CPOL/CPHA不一样切换器件时需要重新配置SPI外设。我的做法是在每次传输前根据目标器件重新初始化SPI参数虽然有点繁琐但能保证兼容性。5.3 模块通信与调试UART不可替代UART在模块通信领域的地位几乎不可撼动。蓝牙模块、WiFi模块、4G模块、GPS模块、指纹模块这些外接模块绝大多数都是UART接口。原因在于UART简单可靠两根线一接就能通模块厂商不需要在协议层做太多工作。调试串口更是每个嵌入式项目的标配。MCU的UART接一个USB转串口芯片连到电脑上就能看日志、发命令。我习惯在项目初期就把调试串口调通后面所有模块的调试都靠它打印信息。没有调试串口的话排查问题基本靠猜效率极低。UART的坑主要在波特率匹配和流控上。如果模块支持硬件流控RTS/CTS建议接上尤其是在高速率或者大数据量场景下否则接收缓冲区溢出会导致数据丢失。另外UART的TTL电平和RS232电平不一样直接对接可能烧器件中间要加电平转换芯片。6. 常见问题排查与避坑指南6.1 通信失败排查速查表现象可能原因排查方法SPI读回全0或全FFCS未拉低、时钟极性错误、MISO未配置示波器看CS和SCLK波形核对CPOL/CPHASPI高速下数据错位走线过长、无阻抗匹配、时钟过快降低时钟测试SCLK串电阻检查地平面UART乱码波特率不匹配、时钟源精度不够核对双方波特率换外部晶振示波器测位宽UART丢数据接收缓冲区溢出、无流控加大缓冲区启用DMA加RTS/CTS流控I2C无应答地址错误、上拉电阻缺失、器件未供电示波器看SDA/SCL波形确认地址和供电I2C波形上升沿太缓上拉电阻过大、总线电容过大减小上拉电阻缩短走线减少挂载设备I2C总线锁死主机异常复位、从机拉低SDA不放发9个时钟脉冲恢复初始化时加恢复逻辑这张表是我这些年排查通信问题时总结的覆盖了八成以上的常见故障。实际排查时建议先用示波器看波形波形正常再查软件配置波形不正常先查硬件。6.2 实操中踩过的坑与经验第一个坑是SPI的CS引脚初始化顺序。有一次调试SPI Flash发现上电后Flash偶尔进入错误模式。查了半天发现是CS引脚在初始化时默认输出低电平导致Flash在上电瞬间被选中收到了杂乱的时钟信号。后来改成初始化时先把CS拉高再配置SPI外设问题就消失了。这个细节很多教程不会讲但实际项目中很容易遇到。第二个坑是I2C的地址冲突。7位I2C地址里有一些是保留地址比如0000xxx和1111xxx段。如果你买的传感器地址刚好落在保留段可能会和其他器件冲突。更常见的是同一型号的传感器地址固定挂多个就会冲突。解决办法是用I2C多路复用器或者选支持地址配置的型号。我在一个项目里需要挂4个同型号温度传感器最后用了TCA9548A多路复用器一个I2C口扩出8个通道每个通道挂一个传感器完美解决。第三个坑是UART的帧错误。有一次用UART接一个GPS模块数据偶尔出现乱码。用示波器看波形发现停止位偶尔被拉低导致帧错误。排查后发现是GPS模块的波特率是9600而我配置的是115200两者不匹配。但奇怪的是大部分数据居然能正确接收这是因为UART的采样机制在波特率差异不大时能容忍一定误差。但这个容忍度是有限的差异大了就会频繁出错。所以UART通信前一定要确认双方的波特率完全一致。第四个坑是SPI和I2C的引脚复用冲突。有些MCU的SPI和I2C共用同一组引脚配置了一个就不能用另一个。我在选型时没注意这个结果项目做到一半发现SPI和I2C不能同时用只能换MCU。所以选型阶段一定要仔细看引脚复用表确认需要的外设能同时启用。6.3 工具与调试手段推荐调试这三种协议示波器是最重要的工具。一个带宽100MHz以上的数字示波器配上协议解码功能能直接看到SPI的字节内容、I2C的地址和数据、UART的帧结构。没有示波器的话逻辑分析仪是退而求其次的选择价格便宜很多也能做协议解码但看不到模拟特性比如上升沿和过冲。万用表可以查通断和电压但查不了时序。我一般用万用表确认供电和上拉电阻是否正常然后用示波器看波形。如果手头没有示波器可以用MCU的定时器输入捕获功能粗略测量波特率和时钟频率虽然精度不高但能判断有没有信号。软件层面建议在驱动里加详细的错误计数和日志。比如SPI传输失败次数、I2C无应答次数、UART帧错误次数这些计数器在排查问题时非常有用。我习惯在调试串口上定期打印这些统计信息一旦某个计数异常增长就能快速定位到对应的通信链路。7. 选型决策的实战建议回到最开始的问题SPI、UART、I2C到底怎么选。我的经验是不要试图找一个万能方案而是根据具体需求做权衡。如果速率是第一优先级选SPI如果引脚资源紧张且速率要求不高选I2C如果是点对点通信或者调试用途选UART。还有一个容易被忽略的点是软件生态。SPI和I2C的驱动通常需要自己写或者移植而UART的驱动几乎所有MCU厂商都会提供完善的库。如果你的项目周期紧、软件人力有限UART可能是更稳妥的选择。反过来如果项目对性能有极致要求SPI的驱动虽然复杂但值得投入。最后分享一个我在多个项目中验证过的做法在PCB设计阶段就把三种接口的测试点都预留出来。SPI留SCLK和MOSII2C留SDA和SCLUART留TX和RX。这样调试阶段不管用哪种协议都能方便地接示波器或逻辑分析仪。测试点成本几乎为零但能省下大量调试时间。这个习惯我保持了七八年每次新项目都会在原理图评审时检查一遍测试点是否齐全。
1. 三种通信协议到底该怎么选嵌入式开发干久了总会遇到同一个问题手头这个传感器或者模块到底该用SPI、UART还是I2C去接。新手往往看哪个引脚少就用哪个或者照着模块手册上的推荐直接抄结果项目做到一半发现速率不够、设备挂不上、通信偶尔丢包回头再改硬件已经来不及了。我自己就踩过这种坑早期做一个多传感器采集板图省事把三个I2C设备挂在同一条总线上结果其中一个设备频繁拉低时钟线导致整条总线锁死排查了整整两天才定位到是上拉电阻阻值不匹配的问题。这篇文章就是想把SPI、UART、I2C这三种最常用的板级通信协议拉出来做一次彻底的横向对比。不光是列参数表格而是从电气特性、协议开销、拓扑结构、实际布线、软件驱动复杂度这几个维度把每种协议的适用边界讲清楚。不管你是刚接触单片机的新手还是做了几年项目想系统梳理一下选型逻辑的老手应该都能从中找到对自己有用的东西。全文会围绕“什么场景下该选谁”这个核心问题展开附带大量实操中的参数计算和避坑经验。2. 三种协议的核心机制拆解2.1 SPI速度优先的“四线制”方案SPI的全称是Serial Peripheral Interface中文叫串行外设接口。它的物理层非常直白四根线SCLK负责时钟MOSI是主机输出从机输入MISO是主机输入从机输出CS是片选。通信的时候主机拉低对应从机的CS线然后在SCLK的每个时钟沿上同时完成一位数据的收发。因为是全双工发送和接收是同步进行的你发一个字节出去的同时也会收到一个字节回来。SPI最核心的优势就是快。理论上速率只受限于器件支持和走线质量做到几十MHz甚至上百MHz都很常见。我实测过某款Flash芯片在SPI模式下跑到50MHz时钟连续读取速率能到6MB/s以上换成I2C的话连十分之一都不到。但代价也很明显每增加一个从机就要多一根CS线引脚消耗大没有硬件级的应答机制主机发了数据从机有没有收到全靠协议层自己保证也没有标准的总线仲裁多主机场景基本不用考虑。从协议开销来看SPI几乎没有额外开销。你发多少位就是多少位没有起始位、停止位、地址帧这些东西。这意味着在需要高速连续传输的场景下SPI的效率是最高的。但反过来因为没有地址机制主机只能通过CS线来区分从机软件上需要为每个从机单独管理CS引脚。2.2 UART最“古老”也最灵活的异步方案UART的全称是Universal Asynchronous Receiver/Transmitter通用异步收发器。注意“异步”两个字这是它和SPI、I2C最本质的区别。UART没有时钟线收发双方靠预先约定好的波特率来同步。一帧数据由起始位、数据位、校验位、停止位组成典型的配置是1位起始位、8位数据位、无校验、1位停止位也就是常说的“8N1”。因为没有时钟线UART只需要两根线TX和RX。如果只需要单向通信一根线就够了。这种极简的连线方式让UART在调试串口、模块通信场景中几乎无处不在。你拿到任何一个开发板上面大概率会有一个UART接口用来打印日志。但异步带来的问题是波特率误差。收发双方的波特率必须足够接近否则在帧末尾采样就会错位。一般要求误差控制在2%以内高速率下要求更严。我遇到过用内部RC振荡器做时钟源跑115200波特率结果因为温漂导致通信偶尔出现乱码的情况后来换成外部晶振就稳定了。所以UART对时钟精度的要求其实比很多人想象的要高。UART的另一个特点是点对点。它没有总线概念两个设备之间直接连。如果要多个设备通信要么用多个UART口要么外挂RS485之类的收发器做总线。软件层面UART的驱动最简单配置好波特率、数据位、停止位就能收发不需要处理地址、片选这些逻辑。2.3 I2C两根线挂一堆设备的“总线型”方案I2C的全称是Inter-Integrated Circuit读作“I方C”或者“I平方C”都行。它的物理层只有两根线SDA是数据线SCL是时钟线。两根线都是开漏输出需要外接上拉电阻。所有设备都并联在这两根线上每个设备有唯一的7位地址也有10位地址的扩展模式。I2C的通信流程比前两者复杂一些。主机发起始条件SCL高时SDA拉低然后发送7位地址加1位读写标志从机如果地址匹配就拉低SDA在第9个时钟周期给出应答。之后就是数据字节的传输每个字节后面跟一个应答位。通信结束时主机发停止条件SCL高时SDA拉高。I2C最大的优势是引脚少、可挂设备多。两根线理论上可以挂128个7位地址的设备实际受电容负载限制一般挂几个到十几个。这在传感器密集的场景下非常香比如一个环境监测节点上挂温湿度、气压、光照三四个传感器用I2C只需要两根线加两根上拉电阻就搞定。但I2C的速率是三者中最低的。标准模式100kHz快速模式400kHz高速模式3.4MHz但实际很少用到。而且因为是开漏输出加外部上拉上升沿的斜率受RC时间常数影响总线电容大了波形就上不去。我实测过在一条挂了8个设备的I2C总线上用4.7kΩ上拉跑400kHz上升沿已经接近1μs勉强能用但余量很小。后来把上拉降到2.2kΩ才把波形修好但功耗也上去了。3. 关键参数横向对比与选型逻辑3.1 速率、引脚数与拓扑结构对照先上一张表把三种协议最核心的几个参数拉齐了看。对比项SPIUARTI2C线数4线SCLK/MOSI/MISO/CS2线TX/RX2线SDA/SCL拓扑一主多从每从机一根CS点对点一主多从地址寻址典型速率10-100MHz9.6k-921.6kbps100k-400kHz双工方式全双工全双工半双工时钟同步主机提供异步双方约定同步主机提供应答机制无无可加校验位有每字节ACK/NACK引脚开销高每从机1低极低多主机不支持不支持支持仲裁这张表里的数据是典型值实际会因器件和布线有出入。比如SPI在长走线或者隔离场景下可能只能跑几MHz而I2C在短距离、低电容负载下也能跑到1MHz以上。但整体趋势是明确的SPI快但费引脚UART简单但只能点对点I2C省引脚但慢且对总线参数敏感。选型的时候我一般按这个优先级来先看速率需求如果单次传输数据量大或者实时性要求高直接上SPI如果只是配置寄存器、读传感器数据这种小数据量场景I2C优先如果是两个设备之间的板间通信或者调试口UART最省事。然后再看引脚资源引脚紧张就尽量用I2C引脚富裕就SPI随便造。最后看拓扑多设备就SPI或I2C点对点就UART。3.2 电气特性与布线约束三种协议的电气特性差异很大这直接决定了PCB布线和线缆选择的策略。SPI是推挽输出驱动能力强上升沿陡峭所以走线可以相对长一些。但高速SPI要注意阻抗匹配和串扰尤其是时钟线。我一般会在SCLK上串一个22Ω到33Ω的电阻来抑制过冲走线尽量等长远离模拟信号。如果SPI速率超过20MHz最好走差分或者至少保证完整的参考地平面。UART也是推挽输出但速率低布线要求最宽松。TTL电平的UART在板内通信基本不用考虑阻抗问题直接连就行。如果要出板子比如通过排线连到另一个设备建议加TVS管做防护线缆长度超过30cm的话考虑用RS232或RS485收发器转一下。I2C是开漏输出这是它布线最麻烦的地方。开漏意味着只能拉低不能拉高高电平全靠外部上拉电阻。总线上的设备越多、走线越长等效电容就越大上升时间就越长。I2C规范里对上升时间有明确要求标准模式不超过1000ns快速模式不超过300ns。上升时间约等于0.847×R×CR是上拉电阻C是总线电容你可以用这个公式反推上拉电阻的最大值。举个例子假设总线电容实测200pF快速模式要求上升时间小于300ns那么R最大约等于300ns/(0.847×200pF)≈1.77kΩ。也就是说上拉电阻不能大于1.77kΩ否则上升沿就超标了。但上拉电阻也不能太小否则低电平时灌电流太大可能超过器件的驱动能力。一般I2C器件的灌电流能力在3mA左右3.3V供电下上拉电阻最小约1.1kΩ。所以实际可选范围很窄常见取值是2.2kΩ到4.7kΩ。注意I2C总线上拉电阻的选型是很多新手容易忽略的点。阻值大了波形上不去阻值小了功耗大且可能烧器件。建议先用示波器实测上升时间再根据公式调整。3.3 协议开销与有效吞吐率计算很多人选型只看标称速率忽略了协议开销结果实际吞吐率差很多。这里我拿实际数据算一下。SPI传1KB数据假设时钟10MHz没有额外开销理论时间约0.82ms有效吞吐率约1.22MB/s。实际因为软件开销和CS切换打个八折大概1MB/s左右。UART传1KB数据波特率1152008N1格式意味着每字节实际传输10位1起始8数据1停止。1KB是1024字节总共10240位时间约88.9ms有效吞吐率约11.5KB/s。如果换成921600波特率时间约11.1ms吞吐率约92KB/s。可以看到UART的协议开销是固定的20%10位传8位数据这个开销无法避免。I2C传1KB数据快速模式400kHz每字节传输需要1个地址字节假设只发一次地址然后连续读 数据字节 每字节1个ACK位。实际每字节9位加上起始停止条件。粗略算下来1KB数据大约需要1024×9/400000≈23ms有效吞吐率约44.5KB/s。如果算上地址帧和重复起始条件还要再低一些。这个计算说明一个问题SPI的有效吞吐率比I2C高一个数量级以上UART在低波特率下更是慢得感人。所以如果你要传图像、音频或者大量日志数据SPI是唯一选择。如果只是读几个传感器寄存器I2C的速率完全够用。4. 实操配置与驱动实现要点4.1 SPI的配置流程与片选管理以常见的STM32系列MCU为例配置SPI的步骤大致如下。首先使能SPI外设时钟和对应GPIO时钟然后配置SCLK、MOSI、MISO为复用推挽输出CS如果由软件控制就配成普通推挽输出。接着设置SPI参数主机模式、时钟极性CPOL和时钟相位CPHA要根据从机手册来定常见的是CPOL0、CPHA0也就是空闲低电平、第一个时钟沿采样。数据位宽一般8位MSB先行。波特率预分频根据系统时钟和目标速率算比如系统时钟72MHz目标10MHz预分频系数取8实际速率9MHz。CS的管理是个容易出问题的地方。如果多个从机共享SPI总线每个从机一根CS软件上要在每次传输前拉低对应CS传输完拉高。注意CS的拉低和拉高之间要留足够的建立时间和保持时间一般从机手册会给出具体数值常见的是几十纳秒。我见过有人CS切换太快导致从机还没准备好就发时钟数据直接错位。// SPI发送一个字节的典型流程 void SPI_WriteByte(uint8_t data) { while(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) RESET); SPI_I2S_SendData(SPI1, data); while(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) RESET); SPI_I2S_ReceiveData(SPI1); // 读走接收寄存器防止溢出 }提示SPI是全双工发送的同时也在接收。如果你只发不收记得把接收寄存器读走否则溢出标志会置位影响后续传输。4.2 UART的波特率计算与中断接收UART的波特率计算是新手最容易出错的地方。以STM32为例波特率寄存器USART_BRR的值等于系统时钟除以波特率。比如系统时钟72MHz目标波特率115200BRR72000000/115200≈625实际波特率72000000/625115200误差0%。如果系统时钟是8MHz内部RCBRR8000000/115200≈69.44取整69实际波特率8000000/69≈115942误差约0.64%在可接受范围内。但如果用内部RC且温漂大误差可能超过2%通信就会不稳定。UART接收建议用中断或者DMA。中断方式下每收到一个字节进一次中断把数据存入环形缓冲区主循环再从缓冲区取数据处理。DMA方式更适合高速率或者大数据量场景配置好DMA通道后UART收到数据自动搬到内存完全不占CPU。// UART中断接收的环形缓冲区实现片段 #define RX_BUF_SIZE 256 uint8_t rx_buf[RX_BUF_SIZE]; volatile uint16_t rx_head 0, rx_tail 0; void USART1_IRQHandler(void) { if(USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { uint8_t data USART_ReceiveData(USART1); uint16_t next (rx_head 1) % RX_BUF_SIZE; if(next ! rx_tail) { // 缓冲区未满 rx_buf[rx_head] data; rx_head next; } USART_ClearITPendingBit(USART1, USART_IT_RXNE); } }4.3 I2C的时序控制与总线恢复I2C的驱动实现比前两者复杂因为要手动处理起始条件、地址帧、应答位、停止条件这些时序。很多MCU有硬件I2C外设但硬件I2C在不同厂商的芯片上表现差异很大有的有已知的勘误问题所以不少老手宁愿用GPIO模拟I2C。GPIO模拟I2C的关键是延时控制。标准模式100kHz意味着每个时钟周期10μs半周期5μs。你需要用精确的延时函数来保证SCL高电平和低电平的时间。延时太短速率上不去延时太长速率不够。我一般用NOP循环或者定时器来做微秒级延时具体循环次数要根据MCU主频实测调整。// GPIO模拟I2C的起始条件 void I2C_Start(void) { SDA_OUT(); SDA_HIGH(); SCL_HIGH(); delay_us(4); SDA_LOW(); delay_us(4); // SCL高时SDA拉低起始条件 SCL_LOW(); delay_us(4); } // 发送一个字节并读取应答 uint8_t I2C_SendByte(uint8_t data) { for(uint8_t i 0; i 8; i) { if(data 0x80) SDA_HIGH(); else SDA_LOW(); data 1; delay_us(2); SCL_HIGH(); delay_us(4); SCL_LOW(); delay_us(2); } SDA_IN(); // 释放SDA准备读应答 SCL_HIGH(); delay_us(4); uint8_t ack SDA_READ(); // 0表示应答 SCL_LOW(); delay_us(4); SDA_OUT(); return ack; }I2C还有一个经典问题总线锁死。如果主机在发送过程中复位而从机还在等待时钟SDA可能被从机拉低不放导致总线无法发起始条件。恢复方法是在SCL上手动发9个时钟脉冲让从机把剩余的数据位发完并释放SDA然后发一个停止条件。这个技巧在实际项目中救过我很多次。注意I2C总线锁死的恢复逻辑建议放在初始化函数里每次上电先执行一次总线恢复避免上次异常复位留下的状态影响本次通信。5. 典型应用场景与选型案例5.1 传感器采集I2C的主场温湿度传感器、气压计、加速度计、陀螺仪、光照传感器这些低速小数据量的器件绝大多数都提供I2C接口。原因很简单它们的数据量小几个到几十个字节更新率低几Hz到几百HzI2C的速率完全够用而且两根线就能挂一堆PCB布局非常清爽。我做过一个环境监测节点上面挂了SHT30温湿度、BMP280气压、BH1750光照三个传感器全部走I2C。三个传感器地址不同挂在同一条总线上MCU只需要两根引脚。初始化的时候依次配置每个传感器的寄存器然后定时轮询读取。整个采集周期100msI2C总线占用率不到5%余量非常大。但这里有个坑不同传感器的I2C时序参数可能不一样。比如SHT30支持时钟拉伸BMP280不支持。如果你的驱动没有正确处理时钟拉伸在某些时序边界上可能读到错误数据。我的做法是在驱动层为每个传感器单独配置超时和重试逻辑读失败就重试三次三次都失败才报错。5.2 存储与显示SPI的天下SPI Flash、SD卡、TFT显示屏、OLED显示屏这些需要高速数据传输的器件基本都是SPI接口。以TFT显示屏为例刷一屏240×320的RGB565图像需要240×320×2153600字节。如果用I2C 400kHz传输光数据就要3.4秒根本没法看。用SPI 40MHz的话153600×8/40000000≈30.7ms刷屏流畅度可以接受。SPI Flash也是类似。固件升级、文件系统、数据日志这些场景需要频繁读写大块数据SPI的速率优势非常明显。我实测过某款SPI Flash在50MHz时钟下连续读取速率能到5MB/s以上写速率受限于Flash的编程时间大概几百KB/s但也比I2C快得多。用SPI接多个器件时CS的管理要特别注意。如果SPI总线上同时挂了Flash和显示屏两个器件的SPI模式可能不同CPOL/CPHA不一样切换器件时需要重新配置SPI外设。我的做法是在每次传输前根据目标器件重新初始化SPI参数虽然有点繁琐但能保证兼容性。5.3 模块通信与调试UART不可替代UART在模块通信领域的地位几乎不可撼动。蓝牙模块、WiFi模块、4G模块、GPS模块、指纹模块这些外接模块绝大多数都是UART接口。原因在于UART简单可靠两根线一接就能通模块厂商不需要在协议层做太多工作。调试串口更是每个嵌入式项目的标配。MCU的UART接一个USB转串口芯片连到电脑上就能看日志、发命令。我习惯在项目初期就把调试串口调通后面所有模块的调试都靠它打印信息。没有调试串口的话排查问题基本靠猜效率极低。UART的坑主要在波特率匹配和流控上。如果模块支持硬件流控RTS/CTS建议接上尤其是在高速率或者大数据量场景下否则接收缓冲区溢出会导致数据丢失。另外UART的TTL电平和RS232电平不一样直接对接可能烧器件中间要加电平转换芯片。6. 常见问题排查与避坑指南6.1 通信失败排查速查表现象可能原因排查方法SPI读回全0或全FFCS未拉低、时钟极性错误、MISO未配置示波器看CS和SCLK波形核对CPOL/CPHASPI高速下数据错位走线过长、无阻抗匹配、时钟过快降低时钟测试SCLK串电阻检查地平面UART乱码波特率不匹配、时钟源精度不够核对双方波特率换外部晶振示波器测位宽UART丢数据接收缓冲区溢出、无流控加大缓冲区启用DMA加RTS/CTS流控I2C无应答地址错误、上拉电阻缺失、器件未供电示波器看SDA/SCL波形确认地址和供电I2C波形上升沿太缓上拉电阻过大、总线电容过大减小上拉电阻缩短走线减少挂载设备I2C总线锁死主机异常复位、从机拉低SDA不放发9个时钟脉冲恢复初始化时加恢复逻辑这张表是我这些年排查通信问题时总结的覆盖了八成以上的常见故障。实际排查时建议先用示波器看波形波形正常再查软件配置波形不正常先查硬件。6.2 实操中踩过的坑与经验第一个坑是SPI的CS引脚初始化顺序。有一次调试SPI Flash发现上电后Flash偶尔进入错误模式。查了半天发现是CS引脚在初始化时默认输出低电平导致Flash在上电瞬间被选中收到了杂乱的时钟信号。后来改成初始化时先把CS拉高再配置SPI外设问题就消失了。这个细节很多教程不会讲但实际项目中很容易遇到。第二个坑是I2C的地址冲突。7位I2C地址里有一些是保留地址比如0000xxx和1111xxx段。如果你买的传感器地址刚好落在保留段可能会和其他器件冲突。更常见的是同一型号的传感器地址固定挂多个就会冲突。解决办法是用I2C多路复用器或者选支持地址配置的型号。我在一个项目里需要挂4个同型号温度传感器最后用了TCA9548A多路复用器一个I2C口扩出8个通道每个通道挂一个传感器完美解决。第三个坑是UART的帧错误。有一次用UART接一个GPS模块数据偶尔出现乱码。用示波器看波形发现停止位偶尔被拉低导致帧错误。排查后发现是GPS模块的波特率是9600而我配置的是115200两者不匹配。但奇怪的是大部分数据居然能正确接收这是因为UART的采样机制在波特率差异不大时能容忍一定误差。但这个容忍度是有限的差异大了就会频繁出错。所以UART通信前一定要确认双方的波特率完全一致。第四个坑是SPI和I2C的引脚复用冲突。有些MCU的SPI和I2C共用同一组引脚配置了一个就不能用另一个。我在选型时没注意这个结果项目做到一半发现SPI和I2C不能同时用只能换MCU。所以选型阶段一定要仔细看引脚复用表确认需要的外设能同时启用。6.3 工具与调试手段推荐调试这三种协议示波器是最重要的工具。一个带宽100MHz以上的数字示波器配上协议解码功能能直接看到SPI的字节内容、I2C的地址和数据、UART的帧结构。没有示波器的话逻辑分析仪是退而求其次的选择价格便宜很多也能做协议解码但看不到模拟特性比如上升沿和过冲。万用表可以查通断和电压但查不了时序。我一般用万用表确认供电和上拉电阻是否正常然后用示波器看波形。如果手头没有示波器可以用MCU的定时器输入捕获功能粗略测量波特率和时钟频率虽然精度不高但能判断有没有信号。软件层面建议在驱动里加详细的错误计数和日志。比如SPI传输失败次数、I2C无应答次数、UART帧错误次数这些计数器在排查问题时非常有用。我习惯在调试串口上定期打印这些统计信息一旦某个计数异常增长就能快速定位到对应的通信链路。7. 选型决策的实战建议回到最开始的问题SPI、UART、I2C到底怎么选。我的经验是不要试图找一个万能方案而是根据具体需求做权衡。如果速率是第一优先级选SPI如果引脚资源紧张且速率要求不高选I2C如果是点对点通信或者调试用途选UART。还有一个容易被忽略的点是软件生态。SPI和I2C的驱动通常需要自己写或者移植而UART的驱动几乎所有MCU厂商都会提供完善的库。如果你的项目周期紧、软件人力有限UART可能是更稳妥的选择。反过来如果项目对性能有极致要求SPI的驱动虽然复杂但值得投入。最后分享一个我在多个项目中验证过的做法在PCB设计阶段就把三种接口的测试点都预留出来。SPI留SCLK和MOSII2C留SDA和SCLUART留TX和RX。这样调试阶段不管用哪种协议都能方便地接示波器或逻辑分析仪。测试点成本几乎为零但能省下大量调试时间。这个习惯我保持了七八年每次新项目都会在原理图评审时检查一遍测试点是否齐全。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
