嵌入式通信协议选型实战：UART/I2C/SPI/I2S四大接口深度对比

1. 这不是协议说明书，是嵌入式工程师的“通信选型决策手册”

i2c、i2s、spi、uart——这四个缩写几乎刻在每个嵌入式工程师的键盘上，也反复出现在原理图评审、PCB布线、驱动调试和深夜抓波形的屏幕里。但真正能说清“为什么这里必须用I2C而不是SPI”“I2S为什么不能简单替换成UART”“UART跑115200bps稳定，换SPI却要调到4MHz才够用”的人，远比写过这四种接口代码的人少得多。我干了12年硬件底层开发，从8位单片机裸机驱动写到SoC级Linux BSP适配，踩过的坑足够填平一个小型实验室：I2C总线被电机干扰拉低导致传感器集体失联；SPI Flash读取时因CS信号毛刺引发固件校验失败；I2S音频输出出现周期性杂音，查了三天才发现是时钟相位偏移了半个周期；UART串口明明接线正确，却始终收不到数据——最后发现是电平标准搞错了，TTL和RS232混用了。这些都不是理论问题，而是焊点、走线、时序、电源噪声和芯片手册第37页小字注释共同作用的结果。这篇内容不讲教科书定义，不列标准参数表，只讲真实项目里怎么选、怎么调、怎么避坑。适合正在画原理图的硬件工程师、刚接手新模块的驱动开发者、被客户问“你们用的是哪种通信？”而卡壳的FAE，以及想把毕业设计做扎实的学生。如果你正为某个传感器该挂I2C还是SPI纠结，或者被I2S波形里多出来的毛刺折磨得睡不着，那接下来的内容，就是你今晚该看的。

2. 四种通信的本质差异：不是“谁更快”，而是“谁在解决什么问题”

2.1 协议设计哲学的根本分野

很多人一上来就比速率：UART最高1Mbps（实际常用115200），I2C标准模式100kHz、快速模式400kHz、高速模式3.4MHz，SPI轻松上10MHz甚至50MHz，I2S专为音频设计，典型速率2.8224MHz（DSD）、11.2896MHz（PCM）。但这就像拿卡车载重能力去比高铁准点率——维度错位。真正的起点，是理解每种协议诞生时要解决的核心矛盾：

• UART解决的是“点对点异步通信的物理层兼容性问题”。它不关心两个设备是不是同一块板子上的，只要电平匹配（TTL/RS232/RS485）、波特率一致、起始停止位对齐，就能传。它的“协议”其实只有帧结构（起始位+数据位+校验位+停止位），没有地址、没有应答、没有主从协商。所以UART天生适合调试口、GPS模块、蓝牙透传模块这类“即插即用”的外设，但绝不能用来挂多个传感器——你没法告诉STM32“现在我要跟温湿度传感器说话”，因为UART没有寻址机制。

• I2C解决的是“多设备共享总线的地址仲裁与冲突避免问题”。它用两根线（SCL时钟、SDA数据）实现全双工通信，靠开漏输出+上拉电阻实现线与逻辑，靠起始/停止条件定义事务边界，靠7位或10位地址区分设备。它的核心价值不是速度，而是“省线”和“可扩展性”：一个主控可以挂十几个从设备，只需两根线，且支持热插拔（理论上）。但代价是时序复杂（起始/停止/应答/重复起始）、速率受限（受总线电容影响）、抗干扰弱（SDA/SCL都是双向开漏，易受干扰）。

• SPI解决的是“高速、确定性、低延迟的主从数据搬运问题”。它用四根线（MOSI/MISO/SCLK/SS），每个从设备独占一根SS（片选）线，通信完全由主控时钟驱动，无地址、无应答、无仲裁。这意味着：只要主控发出时钟，从设备就必须响应，数据在时钟边沿严格采样，延迟可精确到纳秒级。所以SPI是Flash、ADC、DAC、高速WiFi模组的首选——你需要确定性的吞吐量，而不是灵活的设备管理。

• I2S解决的是“数字音频流的时序同步与通道分离问题”。它不是通用数据总线，而是为PCM、DSD等音频格式定制的协议。它有三根核心线：BCLK（位时钟，决定采样点速率）、WS（字选择时钟，即LRCLK，标识左右声道）、SD（串行数据）。关键在于，I2S强制规定了数据在BCLK上升沿/下降沿的采样时机、WS翻转与数据帧的对齐关系、MSB/LSB优先顺序。这种硬性同步，确保了音频数据不会因时钟抖动产生咔哒声或相位偏移。你不能用SPI模拟I2S——即使波形看起来一样，缺少严格的时序约束，播放出来就是破音。

提示：记住这个口诀——“UART连世界，I2C管设备，SPI搬数据，I2S送声音”。脱离应用场景谈速率，就像问“锤子和螺丝刀哪个更好用”。

2.2 物理层与电气特性的现实约束

理论速率只是纸面数据，实际能跑多快，取决于板级实现：

• UART的瓶颈在电平转换和接收端采样精度。TTL UART在板内通信可达2Mbps，但通过USB转串口芯片（如FT232R、CH340）时，实际稳定速率常被限制在921600bps以下，原因在于USB协议栈处理延迟和芯片内部FIFO深度。更隐蔽的问题是：当使用长线（>1米）连接时，信号反射会导致采样错误，此时必须加终端电阻或改用RS485。

• I2C的速率天花板由总线电容决定。公式为：f_max ≈ 1 / (2.2 × R_pullup × C_bus)。假设上拉电阻4.7kΩ，总线电容100pF（含PCB走线、器件引脚电容），理论极限约215kHz。实测中，若挂载3个传感器（每个引脚电容5pF），走线长度10cm（约8pF/cm），总电容≈3×5+10×8=95pF，4.7kΩ上拉下，可靠速率约250kHz。想上400kHz？要么换1kΩ上拉（但会增大功耗、降低噪声容限），要么缩短走线、减少挂载设备。

• SPI的速率直接受制于信号完整性。当SCLK频率超过20MHz时，必须考虑：

  • 走线长度：>5cm需做阻抗匹配（通常50Ω）
  • 信号边沿：过快的上升/下降时间（<1ns）会激发高频谐波，导致EMI超标
  • SS信号质量：片选信号若存在毛刺，可能误触发从设备，造成数据错乱。实测中，STM32H7在100MHz SCLK下，SS走线需与SCLK等长，且远离电源和高频开关信号。

• I2S对时钟抖动（Jitter）极度敏感。音频PLL输出的BCLK，相位噪声需优于-100dBc/Hz@1kHz。普通MCU的GPIO模拟I2S，其时钟由系统定时器生成，抖动可达100ps以上，导致16bit音频信噪比（SNR）从96dB暴跌至70dB以下。这就是为什么ESP32-C3官方推荐使用内置I2S外设而非软件模拟——硬件外设的时钟路径经过专门优化。

2.3 协议开销与实时性的真实成本

数据吞吐量 ≠ 有效带宽。协议本身的开销，往往比标称速率影响更大：

协议	典型配置	每传输8bit数据的实际开销	有效带宽占比	实际影响
UART	8N1, 115200bps	起始位1bit + 数据8bit + 停止位1bit = 10bit	80%	115200bps标称，实际数据速率仅92160bps
I2C	100kHz, 7位地址	起始+地址+读写位+应答+数据+应答+停止 ≈ 32bit/字节	25%	100kHz总线，有效数据速率仅25kB/s
SPI	8bit模式, 10MHz	无额外开销，纯数据流	100%	10MHz SCLK = 10MB/s有效带宽
I2S	16bit, 44.1kHz, 双声道	BCLK=16×2×44.1kHz=1.4112MHz，数据位16bit×2=32bit/帧	100%	1.4112MHz BCLK = 1.4112MB/s有效带宽

这个表格揭示了一个残酷事实：I2C在低速场景（如读取温湿度传感器）足够用，但若要用I2C传输图像数据（哪怕160×120灰度图），100kHz下每帧需耗时数秒——而SPI Flash在相同分辨率下可做到毫秒级加载。同样，I2S的“100%有效带宽”建立在其专用时序基础上；若强行用SPI模拟I2S，需额外消耗CPU周期生成WS/BCLK，有效带宽立刻打五折。

3. 四种协议的实操细节与致命陷阱

3.1 UART：看似简单，实则暗礁密布

UART的“简单”是最大的认知陷阱。我见过太多项目，因为忽略以下细节而返工：

• 电平标准混淆：这是最常见错误。MCU GPIO直接输出的是3.3V TTL电平，而PC端USB转串口模块（如FT232R）输入要求也是TTL电平。但若接到PLC或老式仪器，它们使用RS232（±12V），直接连接会烧毁MCU。解决方案不是“加个电平转换芯片”这么笼统——具体选MAX3232（需外部电容）还是SP3232（内置电容），取决于PCB面积和BOM成本。更隐蔽的是：某些工业模块标称“RS232”，实际是3.3V逻辑电平，此时用MAX3232反而会损坏对方。

• 波特率误差累积：UART依赖双方独立晶振计时。若MCU用8MHz晶振，通过寄存器分频得到115200bps，实际误差可能达-2.3%；PC端USB转串口芯片若用12MHz晶振，误差+1.7%。两者叠加，总误差超4%，超出UART容忍极限（±3%），导致通信失败。实测技巧：用示波器测量实际波特率，若偏差大，改用更精准晶振（如25MHz）或启用MCU的波特率校准寄存器（如STM32的USARTDIV）。

• 中断与DMA的取舍：接收大量数据（如GPS NMEA语句）时，若用中断方式，每字节触发一次中断，CPU负载飙升。但盲目上DMA也有坑：DMA缓冲区大小需精心设计。例如，GPS模块每秒发10条语句，每条平均80字节，若DMA缓冲设为128字节，可能截断一条完整语句。正确做法是：设置DMA循环缓冲，配合空闲中断（IDLE interrupt）检测帧结束——当UART接收线空闲超10bit时间，即判定一帧结束，此时从DMA当前地址往前推，找到最后一个完整语句。

注意：FT232R驱动安装失败？别急着重装。Windows 10/11默认禁用旧版驱动签名验证。右键开始菜单→“运行”→输入msconfig→引导→高级选项→勾选“禁用驱动程序强制签名”，重启后即可安装。这是硬件工程师必备的“急救知识”。

3.2 I2C：总线幽灵与地址迷宫

I2C的调试，80%时间花在“为什么没反应”。根本原因在于其协议的隐式状态机：

• 地址匹配的隐藏规则：I2C地址是7位，但总线上传输的是8位（7位地址+1位R/W）。很多初学者以为AT24C02地址是0x50，实际发送的是0xA0（写）或0xA1（读）。更坑的是：部分器件（如某些EEPROM）地址位由硬件引脚（A0/A1/A2）决定，若PCB上这些引脚悬空（未接VCC/GND），地址随机，导致“有时能读，有时不能”。实测方法：用逻辑分析仪抓取起始信号后的前8位，确认是否为预期地址。

• 时序违规的隐形杀手：I2C标准规定，SCL高电平时间（t_SU;STA）必须≥4μs（100kHz模式）。但若MCU GPIO翻转速度过快，或使用非开漏输出模式，SCL高电平可能仅持续100ns，导致从设备无法识别起始条件。解决方案：在HAL库中启用I2C的“Fast Mode Plus”或手动插入NOP延时；更稳妥的是，用示波器测量SCL高电平宽度，不达标则更换IO口或调整时钟分频。

• 总线锁死的终极噩梦：当从设备在SCL为低时异常复位，可能将SDA拉低并保持，导致总线“卡死”。此时主控发送起始信号，SDA无法拉高，通信彻底瘫痪。标准解法是：向SCL发送9个脉冲（用GPIO模拟），迫使从设备释放SDA。但多数MCU库函数无此功能。我的经验是：在I2C初始化函数中，加入“总线恢复”子程序——先将SCL设为输入，SDA设为输出并拉高；然后循环检测SDA是否为高，若否，将SCL拉低再拉高9次，最后恢复I2C外设。

3.3 SPI：高速下的确定性与脆弱性

SPI的确定性是优势，也是枷锁。一旦出错，往往表现为“间歇性失败”，极难复现：

• CPOL/CPHA组合的生死抉择：SPI有4种模式（00/01/10/11），由CPOL（时钟极性）和CPHA（时钟相位）决定。CPOL=0表示空闲时SCLK为低，CPOL=1为空闲时为高；CPHA=0表示数据在SCLK第一个边沿采样，CPHA=1在第二个边沿采样。错误配置会导致数据错位。例如，ADS1256 ADC要求CPOL=0, CPHA=1，若设成CPOL=0, CPHA=0，则读出的数据高位全为0。实测技巧：用逻辑分析仪抓取MOSI波形，对照器件手册时序图，重点看SCLK空闲电平和数据建立/保持时间。

• SS信号的毛刺免疫设计：片选信号（SS）若存在窄脉冲（<50ns），可能被从设备误认为有效片选，导致数据错乱。硬件层面，需在SS线上加RC滤波（如100Ω+100pF）；软件层面，MCU在拉低SS后，必须插入至少1个指令周期延时（__NOP()），确保SS稳定后再发时钟。更可靠的做法：使用MCU的硬件SS功能（如STM32的NSS引脚），由SPI外设自动控制，避免GPIO操作引入不确定性。

• 全双工下的数据流向陷阱：SPI是全双工，MOSI和MISO同时工作。但很多开发者只关注发送，忽略接收。例如，向SPI Flash发送读命令（0x03），同时MISO线上会返回Flash的第一个字节。若未及时读取MISO寄存器，该字节会被覆盖，导致后续数据全部偏移。正确流程：发送命令字节时，同时读取dummy字节；发送地址字节时，继续读取dummy；最后发送0xFF（空操作），此时MISO返回真实数据。HAL库中，HAL_SPI_TransmitReceive()是安全选择，避免手动轮询的疏漏。

3.4 I2S：音频的时序圣殿

I2S不是“能跑通就行”，而是“时序差1ns，声音就破”。其核心在于三个信号的严格同步：

• BCLK与WS的相位关系：标准I2S规定，WS在BCLK的偶数边沿（通常为下降沿）跳变，且WS高电平对应左声道，低电平对应右声道。但某些CODEC（如ES8388）要求WS在BCLK上升沿跳变。若MCU I2S外设配置为“WS下降沿有效”，而CODEC期待上升沿，则左右声道会互换。实测方法：用示波器同时测量BCLK和WS，观察WS跳变时刻相对于BCLK的位置，与手册对比。

• 数据延迟（Data Delay）的魔鬼细节：I2S数据（SD）必须在WS跳变后的特定BCLK边沿开始输出。例如，TI TAS5707要求SD在WS跳变后第2个BCLK上升沿输出第一位。若MCU配置为“0延迟”，则SD与WS同步，导致CODEC采样错误。解决方案：查阅MCU参考手册，找到I2S外设的“数据延迟寄存器”（如STM32的I2S_IFR寄存器），设置对应延迟值。

• MCLK（主时钟）的不可替代性：I2S通常需要MCLK（主时钟，常为256×BCLK）供CODEC内部PLL使用。若MCU无MCLK输出引脚（如ESP32-C3），必须用GPIO模拟，但GPIO频率精度不足，导致音频失真。此时应选用支持I2S MCLK输出的MCU（如ESP32-S3），或外接专用时钟发生器（如Si5351）。

4. 真实项目选型决策树与避坑指南

4.1 选型决策树：五步排除法

面对一个新需求，按此流程快速锁定协议：

1. 第一步：确定通信方向与拓扑

   • 点对点？→ 排除I2C（虽支持，但浪费其多设备优势）、I2S（单向音频流）
   • 一主多从？→ 优先I2C（省线）、SPI（高速）
   • 主从固定？→ SPI（确定性高）
   • 需要热插拔？→ I2C（协议支持）、UART（物理层支持）

2. 第二步：评估数据特性

   • 小数据包（<32字节），低频（<10Hz）？→ I2C（如温湿度传感器）
   • 大数据流（>1MB/s），实时性要求高？→ SPI（如摄像头、高速ADC）
   • 音频/视频流？→ I2S（音频）、MIPI（视频）
   • 调试信息、配置指令？→ UART（人类可读，协议简单）

3. 第三步：检查硬件资源

   • MCU剩余GPIO极少？→ I2C（2线）、UART（2线）
   • 需要长距离传输（>10米）？→ UART（RS485）、SPI（需加驱动芯片）
   • PCB空间紧张，无法布设多根高速线？→ I2C（2线）、UART（2线）

4. 第四步：分析实时性要求

   • 控制环路（如电机PID）？→ SPI（微秒级响应）
   • 用户界面更新（如LCD刷新）？→ SPI（高速）、I2C（若分辨率低）
   • 后台日志上传？→ UART（简单可靠）

5. 第五步：验证生态支持

   • Linux系统？→ UART（console）、I2C（sysfs）、SPI（spidev）、I2S（ALSA）
   • RTOS？→ 查看BSP是否提供成熟驱动（如FreeRTOS+SPI Flash）
   • Python调用？→ UART（pyserial）、SPI（spidev）、I2C（smbus2），I2S需专用库（如pyaudio）

4.2 典型场景深度拆解

场景1：智能家居网关连接10个Zigbee传感器

• 表面需求：低功耗、多设备、小数据
• 错误选择：UART（需10个串口，不可能）
• 正确选择：I2C（2线挂10个，地址可配置）
• 关键细节：选用快速模式（400kHz），上拉电阻改用2.2kΩ，总线电容控制在50pF以内（PCB走线<5cm，传感器集中布局），软件实现超时重试（I2C通信失败时自动重发3次）

场景2：工业相机模块传输1280×720@30fps图像

• 表面需求：高带宽、低延迟
• 错误选择：I2C（速率不够）、UART（协议开销大）
• 正确选择：SPI（8位模式，20MHz SCLK = 20MB/s > 1280×720×2×30≈11MB/s）
• 关键细节：使用DMA双缓冲，MISO线加50Ω串联电阻抑制反射，SS信号与SCLK等长布线，MCU配置为SPI模式0（CPOL=0, CPHA=0），相机端严格遵循时序

场景3：ESP32-C3驱动I2S DAC播放音乐

• 表面需求：高质量音频输出
• 错误选择：用GPIO模拟I2S（抖动大，破音）
• 正确选择：启用ESP32-C3内置I2S外设，配置BCLK=3.072MHz（48kHz×64），WS=48kHz，SD数据格式为24bit左对齐
• 关键细节：MCLK必须由I2S外设生成（非GPIO），CODEC供电使用LDO而非DCDC（降低电源噪声），PCB上I2S走线远离开关电源和射频区域

4.3 常见问题速查表与独家避坑技巧

问题现象	可能原因	排查步骤	我的独家技巧
I2C扫描不到设备	上拉电阻缺失/阻值过大；SDA/SCL接反；设备地址错误	用万用表测SDA/SCL对地电压（应≈VCC）；逻辑分析仪抓起始信号	在I2C初始化后，立即读取一个已知地址的寄存器（如0x00），若返回0xFF，说明总线未激活；若返回0x00，说明设备未响应
SPI Flash读取数据全0	SS信号未拉低；CPOL/CPHA配置错误；Flash未退出保护模式	示波器测SS电平；对比手册时序图；发送解锁命令（0x06）	写入前先读取状态寄存器（0x05），若bit1=1，表示写保护开启，必须先发0x06解锁
UART接收数据错乱	波特率不匹配；电平不匹配；接收缓冲区溢出	示波器测实际波特率；确认电平标准；增加缓冲区大小	在中断服务程序中，仅将接收到的字节存入环形缓冲区，解析工作放在主循环，避免中断中处理耗时操作
I2S音频有杂音	BCLK/WS相位错误；MCLK抖动；电源噪声	示波器测BCLK/WS相位；频谱分析仪测MCLK相位噪声	在CODEC的AVDD引脚就近放置10uF钽电容+100nF陶瓷电容，比单纯加大电容更有效

实操心得：所有协议调试，第一件事不是看代码，而是用示波器或逻辑分析仪抓波形。我书桌抽屉里常年备着Saleae Logic 8，因为它能同时捕获UART/I2C/SPI/I2S，且免费软件足够用。记住：眼见为实，波形不会说谎。

5. 工具链与调试实战：从示波器到逻辑分析仪

5.1 工具选型：不求最贵，但求最准

• 示波器：不是所有示波器都适合嵌入式调试。200MHz带宽足够（SPI 50MHz信号的5次谐波在250MHz），但关键在采样率——需≥1GSa/s才能清晰捕捉边沿。我主力用Keysight DSOX1204G，胜在波形刷新率高（>100kwfms/s），能快速发现偶发毛刺。低端示波器（如DS1054Z）在捕获I2C起始条件时，因刷新率低，可能错过瞬态事件。

• 逻辑分析仪：比示波器更适合协议分析。Saleae Logic Pro 16支持I2C/SPI/UART/I2S解码，采样率100MSa/s，价格亲民。关键技巧：设置触发条件——I2C可设“地址匹配触发”，SPI可设“SS下降沿触发”，这样能精准捕获目标事务，避免海量无关数据。

• USB转接工具：FT232R模块最常见，但稳定性参差。我坚持用原装FTDI模块（带FT232RL芯片），因其驱动成熟，Windows/Linux/macOS兼容性好。国产CH340虽便宜，但在Linux下偶发权限问题（需sudo chmod a+rw /dev/ttyUSB0），不适合量产测试。

5.2 调试流程：标准化七步法

1. 确认物理连接：用万用表通断档测线路，确认无虚焊、短路。尤其检查I2C上拉电阻是否焊接、SPI的SS线是否接对引脚。

2. 测量电源质量：用示波器AC耦合测VCC，纹波应<50mVpp。I2S对电源噪声极其敏感，纹波超标直接导致底噪。

3. 捕获基础波形：逻辑分析仪接SCL/SDA（I2C）、SCLK/MOSI（SPI）、TX/RX（UART）、BCLK/WS/SD（I2S），设置合适采样率，捕获空闲状态。

4. 验证协议握手：I2C看起始/停止条件；SPI看SS下降沿后SCLK是否启动；UART看起始位；I2S看WS是否按预期频率翻转。

5. 解码关键事务：启用逻辑分析仪协议解码功能，查看地址、数据、应答是否符合预期。注意I2C的“NACK”标志，SPI的“dummy byte”位置。

6. 比对器件手册：将捕获波形与手册时序图逐项比对，重点关注建立/保持时间、边沿位置、电平宽度。

7. 隔离变量测试：若失败，逐一断开其他设备（I2C总线）、更换线缆（UART长线）、降低速率（SPI从10MHz降到1MHz），定位问题根源。

5.3 一个真实案例：GT911触摸屏I2C通信失败

客户反馈GT911触摸屏偶尔失灵，复位后恢复。逻辑分析仪抓取发现：正常时I2C通信流畅；失灵时，主控发送地址后，GT911无应答（SDA保持高电平）。深入排查：

• 测量GT911的INT引脚，发现失灵时INT被拉低但未释放——说明触摸IC内部锁死。
• 查阅GT911手册，发现其I2C从机有“总线超时复位”机制：若SCL被拉低超10ms，自动复位。
• 追踪代码，发现MCU在I2C中断中执行了耗时操作（如浮点运算），导致SCL被长时间占用。
• 解决方案：将耗时操作移出中断，在主循环中处理；I2C中断仅负责数据收发，确保SCL及时释放。

这个案例印证了那句话：嵌入式调试，一半在硬件，一半在代码，但根子永远在协议时序。

6. 扩展思考：协议融合与未来趋势

6.1 协议不是孤岛：混合架构的实践

单一协议难以满足所有需求，工程中常见混合方案：

• UART + I2C网关：主控通过UART与Wi-Fi模块通信（透传），Wi-Fi模块内部用I2C管理其传感器（如温湿度）。这样既利用UART的简单性，又发挥I2C的多设备管理能力。

• SPI + DMA + FreeRTOS队列：SPI Flash读取通过DMA完成，数据存入FreeRTOS消息队列，应用任务从中取数据。避免阻塞式SPI操作影响实时任务。

• I2S + PDM麦克风：PDM（脉冲密度调制）麦克风输出单线数字信号，需MCU用I2S外设的“PDM模式”解码。此时I2S不再传输PCM，而是作为PDM解码引擎。

6.2 新兴挑战与应对思路

• 多核MCU的协议竞争：Cortex-M7+M4双核架构中，若两核同时访问同一I2C总线，需硬件信号量或软件互斥锁。我的做法是：将I2C外设专属分配给M4核，M7核通过IPC消息请求M4代为操作，避免总线冲突。

• 低功耗场景的协议权衡：电池供电设备中，I2C的“地址广播”比SPI的“逐个唤醒”更省电——SPI每次通信需拉低对应SS，而I2C可批量读取多个寄存器。但I2C的上拉电阻持续耗电，此时可选用“休眠模式I2C”（如某些MCU支持的Low Power I2C），在空闲时关闭上拉。

• AIoT对通信的新要求：边缘AI模型推理结果需实时回传，传统UART带宽不足，I2C速率有限，SPI虽快但缺乏网络协议栈。解决方案是：SPI连接Wi-Fi模组（如ESP32），模组内部运行TCP/IP协议栈，MCU通过SPI发送AT指令或二进制数据包。此时SPI是物理层，TCP/IP是应用层，各司其职。

我在实际项目中发现，最可靠的系统，往往不是技术最先进的，而是协议选择最克制的。I2C不用于传图像，UART不挂传感器阵列，SPI不用来接音频，I2S不干数据搬运——守住边界，才是工程师的敬畏之心。