嵌入式必知：SPI、UART、I²C三大通信接口选型与调试实战

做硬件调试这些年我有个很深的感触SPI、UART、I²C这三种通信接口是嵌入式系统里用得最多的“三兄弟”但也是把新手虐得最惨的“三兄弟”。刚入职那会儿我调一块用SPI读传感器的板子读回来的数据全是0xFF折腾了一下午最后发现是MISO和MOSI接反了后来调I²C总线又把整条总线拉死整个系统卡住不动查资料才知道是上拉电阻选大了。这些经历让我明白一件事接口选型不是拍脑袋调试也不是拿个示波器乱戳而是要把物理层特性、协议时序、软件配置和排查方法串起来理解。这篇文章就把我的选型判断和调试经验完整分享出来主要面向正在用STM32这类MCU做项目的硬件工程师和嵌入式开发者刚入行的朋友也能把它当一份避坑清单看。1. 三种接口的本质区别先搞懂物理层再谈选型设计电路之前首先要弄清楚这三兄弟在物理层各是什么脾气。很多人一上来就查手册选接口结果做出来的板子不是信号乱掉就是设备偶尔失联根本原因就是对接口特性理解太浅。我习惯把每个接口想象成一个通信场景这样很多参数就自然记住了。1.1 UART两点之间的异步对话UART叫通用异步收发器它只有两根数据线一根发送TX、一根接收RX两个设备之间再共地就完事了。所谓异步就是通信双方不需要额外的时钟线而是各自按约定的波特率来采样数据。这句话怎么理解你可以想象两个人在打电话电话线就只有一根但双方必须按同样的语速说话一个说快了另一个就听不清。UART就是这样发送方按一个波特率把数据位的宽度定下来接收方按同样的速率去采样才能把0和1正确还原。这里有几个关键点必须注意。首先是电平标准MCU的UART引脚是TTL电平通常0V代表逻辑03.3V或5V代表逻辑1两个MCU之间直连没问题。但如果要接电脑串口、接工业设备就要经过电平转换比如USB转UART芯片我常用FT231X这类、RS232收发器或RS485收发器。RS232用正负电压表示逻辑RS485用差分信号抗干扰能力完全不同。所以选UART之前先想清楚你是板级通信还是跨机柜通信这决定了你要不要加收发器。其次是数据帧格式。一个UART帧包含起始位、数据位、校验位、停止位比如常见的8N1就是8个数据位、无校验、1个停止位这些参数通信双方必须完全一致否则一帧出去就是乱码。调试时遇到串口数据不对第一反应应该查波特率、数据位、停止位、校验位这四件套而不是马上怀疑硬件坏了。最后是共地问题UART是单端信号参考的是地平面两个设备必须共地否则电平参考点不同。我见过不少新手把两个板子串口一接就去读数据结果全是乱码把引脚也烧了原因就是没共地。1.2 SPI抢占时钟边缘的高速通道SPI的全称是串行外设接口它跟UART完全是另一种思路。SPI是同步通信主机主动产生时钟信号数据线上的每一位都由时钟的边沿来标记所以它不需要波特率这种约定想多快就多快只要双方能跟上。标准SPI有四根线SCLK时钟、MOSI主机输出从机输入、MISO主机输入从机输出、CS片选。为什么比UART多两根因为SPI要支持全双工通信主机发数据的同时也在收数据MOSI和MISO分开一个负责进场一个负责出场互不干扰。再加上时钟线和片选线四根线构成一个主从通信的最小系统。时钟信号是SPI的灵魂。SPI有四种工作模式由CPOL时钟极性和CPHA时钟相位两个参数决定。CPOL决定空闲时时钟线是高还是低CPHA决定数据是在第一个边沿采样还是第二个边沿采样。这两个参数如果没配好数据读出来就是错位或错电平。我在实际项目里见过最多的SPI故障一半以上都是模式配错了。比如常见的W25Q64 SPI Flash它支持Mode 0和Mode 3但我见过有人配成Mode 1结果读ID时数据全是乱的。片选信号也是特容易出问题的地方尤其要区分硬件片选和软件片选。硬件片选由MCU的NSS引脚硬件控制比如STM32的SPI模块可以自动拉低CS并在通信结束后拉高好处是时序精确、CPU负担小适合大块数据不间断传输。软件片选就是随便拿一个GPIO来控制优点是可以随便选引脚、布局灵活但CS拉低到第一个时钟沿之间的建立时间要自己保证。很多高速外设对这个建立时间有明确要求比如某些SPI Flash要求CS拉低后至少等几百纳秒才能给时钟如果你用软件片选又没做延时外设根本不响应读出来的数据全是垃圾。SPI适合什么场景速率高、数据量大、读写方向明确的外设比如SPI Flash、SD卡、显示屏、高速ADC、磁编码器之类的。我最近在用MT6701磁编码器就是通过SPI接口读角度数据几千赫兹的轮询频率下UART和I²C都会比较吃力SPI配合DMA就很舒服。1.3 I²C双线串起一堆设备的省线专家I²C和UART、SPI最大的不同是它可以在两根线上挂一串设备通过地址来区分谁是谁。两根线中一根是SCL时钟线一根是SDA数据线但SDA是双向的既能发也能收所以I²C是半双工通信同一时刻只能一个方向传输。I²C的电气特性很特殊SCL和SDA都是开漏输出加上外部上拉电阻才能工作。什么叫开漏你可以理解成每个设备只能把线拉低不能主动拉高拉高全靠上拉电阻。这种设计的好处是多个设备可以共享一根线而不会互相打架谁想发0就拉低想发1就松手让电阻把线拉回高电平。如果两个设备同时拉低也不会短路这就是线或逻辑也是I²C能支持多设备挂载的物理基础。I²C的时序核心是起始条件、停止条件、ACK应答。SCL在高电平期间SDA从高跳变到低表示起始SCL在高电平期间SDA从低跳变到高表示停止。每次传输8位数据后接收方需要在第9个时钟周期拉低SDA表示应答。如果主机读取一个不存在的设备地址从机不会应答主机的ACK/NACK标志就会暴露问题这是排查外设是否在线的好方法。I²C速率比SPI慢标准模式100kbps快速模式400kbps再往上1Mbps甚至3.4Mbps也有但在MCU里面用得最多的还是100k和400k两档。速度快了以后对走线和电容要求高一般来说I²C总线上的设备不要太多上拉电阻也要同步调整。板级小系统挂个EEPROM、温度传感器、RTC时钟这些低速设备I²C是最合适的。1.4 一张表看清三者差异把三个接口放一起对比选型思路会清晰很多。我整理了一张压箱底的对比表每次画原理图前都会看一眼。对比项UARTSPII²C引脚数量2根TX、RX4根以上SCLK、MOSI、MISO、CS2根SCL、SDA上拉电阻通信方式异步同步同步全/半双工全双工全双工半双工时钟控制无外部时钟靠波特率对齐主机提供时钟主机提供时钟多设备支持点对点为主一主多从每从一片选多设备靠地址区分典型速率9600bps到几Mbps数Mbps到数十Mbps100kbps到几Mbps抗干扰TTL一般RS485强板内短距离板内短距离调试难度简单工具多中等需要看时序稍复杂易卡死注意表格里的“典型速率”只是常规范围实际速率取决于MCU和外设的能力。比如STM32F103的SPI最高能跑到18Mbps左右而I²C标准配置下可能只能到400kbps。选型的时候别光看协议理论值还要落到具体芯片上查手册这个后面实操章节会细讲。2. 选型判断项目里到底该用哪个接口很多工程师画原理图的时候随手拉个接口等PCB打样回来调不通才后悔。其实选型这个动作非常讲究它不是技术偏好问题而是系统工程权衡问题。下面我按几个实际维度来讲。2.1 先看速度和数据量需求选接口第一件事是想清楚你要传的数据到底有多快、多大。温湿度传感器这种几秒采一次的UART和I²C都够用EEPROM读写几百字节配置400kbps的I²C没问题但如果要刷一张JPEG图片到彩屏上或者持续录制音频、高速采集角度数据I²C就明显不够了得上SPI或者更快的接口。举个实际例子我前阵子做的一个项目需要以1kHz的频率读取一个16位磁编码器的角度值数据量是16kbps理论上I²C也能跑但I²C每8位后面要跟一个ACK位加上寄存器地址这些开销实际有效带宽要打个七折而且还要考虑总线上其他设备的占用。最后我还是用了SPI加DMAMCU几乎零负担读回来的数据也稳定。所以我的习惯是只要速率需求超过100kbps或者数据是持续大批量的优先考虑SPI而不是硬挤I²C。2.2 再看引脚多少和板子空间MCU的引脚是稀缺资源。一个功能齐全的板子传感器、存储、屏幕、按键、LED都要占IO选接口时必须精打细算。比如你用一个28脚的小封装MCU要接一个OLED屏和一个Flash还有一个传感器如果都用SPI光片选就要三根加上时钟和数据线总共九根以上IO资源直接爆炸。但如果屏和Flash用SPI传感器走I²C几个低速设备再共享一条I²C总线引脚数量能省出一大截。这里有个细节容易被忽视SCL、SDA两根线可以挂多个设备但每挂一个设备总线电容就会增大一点波形边沿会变缓速率太高就出错。所以省引脚也要有度板级I²C挂三五个设备没问题挂十个以上就要慎重了尤其是跑高速I²C模式的时候。2.3 多设备场景片选扩展与地址规划如果你要接很多同类型的外设选型逻辑又不一样了。SPI的多设备是靠片选一个设备一条CS线设备多了CS引脚就多。我见过一个项目挂了四片SPI Flash一个片选分时复用导致其中一片Flash的数据只能在另三片空闲时才能读写软件复杂度陡增。这种情况可以考虑用3-8译码器来扩展片选但硬件上又多了几根控制线要权衡。有人问CS最小能做到多少其实取决于译码器传播延时和从机的建立时间算清楚就行不要拍脑袋定。I²C那边则是靠地址。同样的芯片型号通常可以通过地址引脚拨码来区分不同的地址比如AT24C02这类EEPROM有A0/A1/A2引脚可以组合出8个不同地址一根总线上挂8片没问题。所以在多设备、低速、同型号芯片的场景下I²C的地址机制比SPI的片选机制灵活得多。这就是为什么很多板子上会看见一排EEPROM或者温度传感器都挂在I²C上的原因。2.4 距离、干扰和电平转换不能忽略通信接口最终能不能稳定工作距离和干扰是很现实的问题。TTL电平的UART、SPI、I²C都是为板内短距离设计的几十厘米以内没问题太远了信号就会劣化尤其是I²C两根线在长距离下极易受干扰。工业现场经常要几十米甚至几百米通信那就得放弃TTL UART改用RS485的差分UART或者直接上CAN总线。电平转换也是选型的一部分。比如你的主控是3.3V外设是5V的SPI Flash直接连接的话引脚电平可能不兼容轻则读不到数据重则烧毁IO。要么选支持宽电压的外设要么加电平转换芯片。我在设计时会把所有通信引脚的电压域写进原理图注释里防止板子回来以后才发现某个外设电平不匹配。当然有时候也会遇到多个接口都合适的局面那就看团队最熟哪个、调试工具最趁手是哪个。我最常跟人说的一个原则是能力余量留30%但不要为了炫技去上更复杂的接口。通信接口这种东西越简单越不容易出错。3. 实操经验STM32上把三种接口调稳理论讲完了该上手了。现在MCU项目里用STM32的人非常多我就以STM32F103和CubeMX环境为例把三种接口的实际配置和调试经验讲一遍。下面的细节都是我实际调板时踩过坑之后沉淀下来的不是照着手册抄的。3.1 CubeMX初始化与时钟树配置用STM32CubeMX生成工程第一步先把时钟树搞定。很多新手忽略这一步直接用默认时钟配置SPI结果速率上不去或者波形不对。以STM32F103为例外部晶振设为8MHzPLL倍频到72MHz系统时钟这时APB1总线时钟36MHzAPB2总线时钟72MHz。SPI1挂在APB2上SPI2挂在APB1上时钟频率不同最后SPI波特率计算结果也不一样。CubeMX配置SPI时界面里有Prescaler分频系数、CPOL、CPHA、数据大小、首字节MSB还是LSB等参数。你需要根据外设的数据手册填不能瞎选。比如W25Q64 SPI Flash支持Mode 0和Mode 3我习惯用Mode 0也就是CPOL0、CPHA0时钟空闲为低第一个边沿采样。确认模式后分频系数按“外设支持的最高频率”来选宁可低一点求稳也不要顶着极限跑。配置完SPI再配DMA。DMA全称是直接存储器访问它可以帮CPU把数据从内存搬到外设或者从外设搬到内存传输完成后才通知CPU。用SPI读取数据时如果一字节一字节地等CPU被占得死死的典型表现是主循环卡顿、其他任务延迟。用DMA以后CPU在配置完DMA通道后就去干别的事数据到了自动进内存效率完全不一样。CubeMX里在SPI1的DMA设置页添加SPI1_RX请求再添加SPI1_TX请求数据宽度根据你要读的数据长度设置一般选Byte或者Half Word。生成代码后在工程里做的事其实就那么几件先拉低CS再调用HAL_SPI_Receive_DMA启动接收等待DMA传输完成中断回调然后拉高CS。注意CS的拉低和拉高时机尤其是用软件片选时必须在启动传输前拉低、在接收完成后拉高否则时序就乱了。我这段时间调MT6701磁编码器就是这套流程稳定得很。3.2 UART的阻塞、中断与DMA怎么选UART有三种收发模式很多人搞不清楚什么场景该用哪种。其实判断标准很简单打印一条调试信息用阻塞方式无所谓接收不定长数据用中断大批量双向传输用DMA。阻塞模式就是调用HAL_UART_Transmit后一直等到发送完成才返回代码最简单调试的时候最方便。我建议刚开始调试一块新板子的时候只用阻塞模式把串口打印跑通确认UART本身没问题再去上中断和DMA免得一次引入太多变量。中断模式是配置HAL_UART_Receive_IT每收到一个字节就进一次中断在回调函数里拼包。这个模式适合数据量不大、但需要边收边处理的场景比如接收AT指令、按键命令之类。要注意的是中断接收的单字节方式逻辑比较脆弱如果一帧数据还没拼完又收到新数据容易漏包一般会配合空闲中断或者定时器超时来判定一帧数据结束。DMA模式适合传输大块数据比如用串口做固件升级、把采样数据实时回传到上位机。配置DMA时有一个常见坑接收DMA和发送DMA是两个独立通道接收DMA还需要配合串口的空闲中断才能知道“一帧数据什么时候结束”。不然DMA一直在收你根本不知道数据包边界在哪里。我常用的做法是DMA接收加串口空闲中断空闲中断触发时去读剩余数据长度就能算出这一帧的实际字节数。调UART时串口调试助手是必备工具。我习惯用SSCOM设置好端口、波特率、数据位、停止位、校验位以后可以十六进制显示、定时发送、保存日志功能实用还不花哨。如果你用的是USB转UART芯片比如FT231X要先装好驱动Windows设备管理器里能看到对应COM口号才能正常连接。很多人调试UART说连不上设备一半是驱动没装好一半是端口选错了这在排查顺序里要排在前面。3.3 I²C硬件外设还是软件模拟STM32F103自带硬件I²C模块但工程圈里对它的口碑一直不太好很多人说它容易卡死、状态机复杂。ST官方虽然也发布过一些勘误和解决办法但我见得更多的方案是用GPIO软件模拟I²C时序。为什么大家都在模拟因为I²C协议本身不复杂起始、停止、发字节、收字节、应答这些时序用GPIO翻转就能做出来代码逻辑清晰、可控性强、出问题好排查。而硬件I²C一旦进入异常状态比如从机操作失误导致SDA被拉死不释放硬件状态机可能就卡在那里软件怎么复位都不好用。相比之下软件模拟遇到卡死我可以用程序主动翻转SCK来“激活”从机把总线救回来。当然软件模拟也有缺点它要占用CPU时间时序的准确性依赖于中断被延迟的情况。如果系统里中断很多I²C软件模拟的时序可能被撕裂这时就得用硬件I²C更稳。从F4系列开始硬件I²C改进不少但如果是F1系列的老项目我的建议还是软件模拟稳定压倒一切。如果你决定用CubeMX的硬件I²C配置时填一下Standard Mode100kHz或者Fast Mode400kHz地址7位还是10位按外设的地址宽度来别的交给HAL库。读取的步骤一般是生成起始条件、发送从机地址加读标志、接着读一个字节或连续读多个字节、最后生成停止条件。调不通的时候优先查地址对不对、上拉电阻有没有贴、ACK有没有响应千万不要一上来就怀疑时序I²C的坑多半在前三个。4. 调试工具与方法从根上定位问题接口配置好了代码写完了板子一上电问题就来了。这时候就得靠调试手段定位。我见过很多工程师调试全靠眼睛瞪瞪着瞪着就下班了。下面这些工具和方法是我调试三种接口的常用套路。4.1 逻辑分析仪看通信波形的神器调SPI和UART逻辑分析仪比示波器好用得多。为什么因为通信协议是数字信号逻辑分析仪能直接把总线上的0和1翻译成协议帧你不用自己数波形数到眼瞎。一个几十块钱、24MHz采样率的8通道逻辑分析仪就够应付日常项目。拿UART举例把逻辑分析仪的通道夹在TX引脚上打开软件选好波特率采集一段波形软件会自动解析出“起始位、0x55、停止位”这样的结果。如果解析出来的数据跟你发送的不一致要么波特率设置错了要么电平反了要么数据位和停止位参数不一致。拿SPI来说逻辑分析仪可以同时抓SCLK、MOSI、MISO、CS四根线软件会自动解析出每个字节你一眼就能看出设备返回了什么数据。之前调一个SPI Flash读ID读回来全是0用逻辑分析仪一抓发现CS拉低得太晚时钟都跑完两个周期了CS才拉低外设压根没被选中问题一下就定位了。示波器也还是需要备一台主要用来判断信号质量。比如SPI时钟线上的过冲、振铃、边沿太缓这些问题用逻辑分析仪是看不出来的必须示波器上阵。所以我的桌面一般是三件套示波器看电气质量逻辑分析仪看协议内容万用表量通断和电平。这三样配合起来大部分通信问题都能在半小时内缩小到具体引脚。4.2 串口打印与日志系统UART除了当业务通信接口最大价值是当调试窗口。几乎所有MCU工程都会把printf重定向到UART然后用串口助手看打印。这个操作很简单重写一下fputc函数把输出导向到串口句柄即可。但在项目里用一段时间你就会发现裸printf太乱了。我的习惯是搞一个轻量级log模块按级别输出ERROR、WARN、INFO、DEBUG并且同时把数据写到一个RAM环形缓冲区里。这样正常运行时有串口打印看实时状态一旦设备死机或者跑飞了把缓冲区里的数据倒出来分析就能知道死机前最后做了什么。如果你用调试器还可以把打印输出重定向到调试器的RTT功能省掉一根串口线调试体验好很多。调试串口还有一个技巧用波特率115200打印速度够快信息也够。但你在室内测试时要远离电机、继电器这类大电流设备否则串口打印会周期性乱码。之前一次实测电机一启动串口就乱码排查了半天是电源地没处理好导致地电位波动直接干扰了UART的参考电平。如果项目里有以太网口也可以用网络调试助手代替串口助手上位机通过UDP或者TCP发报文到设备日志直接通过网络传出来这种方式在设备已经联网的调试阶段特别方便也省得一直插着USB线。4.3 常见问题排查速查表下面这个表是我把多年踩坑经验浓缩出来的速查表。每次调试卡壳的时候按图索骥能省不少时间。通信接口现象可能原因排查方法SPI读回数据全是0xFF片选没拉低、MISO没接对、从机没上电用逻辑分析仪抓CS和MISO检查接线和电源SPI读回数据错位或乱码模式CPOL/CPHA不匹配、速率太高确认外设支持的SPI模式降低分频系数SPI部分设备通信正常、部分不正常CS引脚复用冲突、软件片选建立时间不够检查GPIO复用功能配置CS拉低后加延时再操作UART字符串乱码波特率不对、数据位/校验位不一致串口助手重设参数用逻辑分析仪量一个bit宽度确认波特率UART完全收不到数据TX/RX接反、没有共地、引脚未配置万用表测引脚电平交叉换线测试UART周期性强干扰乱码电源地噪声、线束靠近干扰源改善共地串口线远离大电流走线I²C总线卡死SDA一直为低从机错误拉低、上拉电阻缺失、地址错误上电后用示波器看SDA电平尝试翻转SCLK释放总线I²C读取正常但写入失败写保护引脚状态、字节地址超范围查外设数据手册的写保护逻辑这张表不是万能药但能覆盖我实际遇到过的八成问题。剩下两成就是靠细心和耐心一步一步缩小范围了。硬件调试最忌讳的就是东查一下西查一下没有章法。我的流程永远是先确认电源和地再确认引脚配置然后查波形最后才怀疑代码逻辑。把这个顺序固定下来你的调试效率至少翻一倍。最后再多说一句接口选型这件事。我看过太多人纠结“哪个好”其实真正应该问的是“哪个合适”。我现在的固定流程是这样的先列出所有外设的速率、数量、引脚预算、通信距离这些硬指标画一张表对比再考虑团队熟悉度和调试工具链最后才打开CubeMX动手。调板的时候逻辑分析仪和串口助手常备先确认物理层正常再查协议层不要一步跳到代码逻辑上瞎猜。这么多年下来SPI、UART、I²C各自的脾气我已经摸得差不多踩坑少了效率自然就上去了。希望这篇分享能让你少走点弯路哪怕只帮你节省一次查问题到半夜的时间我也觉得值了。