企业官网建设流程全解析

刚入行那会儿，每次拿到一块新板子，我第一件事就是翻原理图看接口标号。I2C、I2S、SPI、UART，这四个缩写几乎出现在每一块嵌入式板卡上，引脚数量不同、名字相似，稍不留神就会把SDA当成MOSI接进去，然后花一整天在逻辑分析仪上找波形。直到我把四种协议从头到尾理了一遍，才发现它们之间不只是“快慢不同”这么简单——每个协议从诞生那天起，就是为某一种特定场景而设计的。这篇内容我就围绕这四个协议的时序特征、物理层差异、选型逻辑和实际调试中的坑，认认真真做一次横向对比，帮你在自己项目里少走弯路。

这篇文章适合刚接触嵌入式通信协议的同学，也适合已经在用但没深究过“为什么这样设计”的开发者。我会把原理讲清楚，也会给出实际可抄的配置思路和调试经验。

1. 四种协议的身份定位：它们各自解决什么问题

很多教程喜欢直接罗列引脚定义和帧格式，但我觉得理解协议最好的切入点，是先搞清楚“它生下来是为了干什么的”。

1.1 UART：给“两个设备聊天”设计的异步串行协议

UART（Universal Asynchronous Receiver/Transmitter，通用异步收发器）的历史可以追溯到早期计算机串口设备，它解决的问题其实非常朴素：让两个设备之间，只靠一根发送线、一根接收线就能互相传数据。

它叫“异步”，是因为收发双方不需要共享时钟线。发送方按照约定的波特率（比如115200bps）把数据一位一位地发出去，接收方用自己的时钟在同样的波特率下去采样。这就好比两个人打电话，不需要一根额外的“节拍器”线，只要双方都说话语速一致就行。

UART的典型特征是点对点，一收一发。虽然也有一主多从的RS-485变体，但那是靠地址和收发使能来控制的方向切换，本质上还是一对一通信在工作。它的帧结构也很简单：空闲时拉高，起始位拉低一个位时间，然后传5到8个数据位，最后是校验位（可选）和停止位。这也是为什么UART在调试中最常见——往TX脚扔几个字节，串口助手就能看到内容，不需要考虑总线仲裁、设备寻址这些复杂机制。

所以UART最适合的场景是：两个设备之间低速、简单、双向的数据交换，尤其是调试日志、AT指令、GPS定位信息这类流式文本数据。

1.2 I2C：给“一总线上挂很多小器件”设计的同步协议

I2C（Inter-Integrated Circuit，集成电路间总线）是Philips（后来是NXP）在1982年为了连接电视、音响里的各种芯片发明的。它解决的核心问题是：板子上器件越来越多，每颗芯片都单独拉几根控制线，PCB布线会爆炸。

I2C只用了两根线：SDA（数据线）和SCL（时钟线）。所有器件挂在这两根线上，每个器件有唯一的7位或10位地址，主机通过地址寻址来和某个从机通信。因为线少，所以速度快不起来，标准模式100kbps，快速模式400kbps，高速模式3.4Mbps，实际嵌入式项目里100k和400k用得最多。

它的设计哲学是“够用就行”——大多数传感器、EEPROM、RTC（实时时钟）、温度监控芯片，数据量都很小，不需要高带宽，但要求接线简单、挂载方便。我还见过一个I2C总线上挂了8个设备的设计，从气压计到触摸屏控制器全在上面，每个设备地址不一样，互不干扰。

I2C最特别的地方在于开漏结构和上拉电阻。SDA和SCL都是开漏输出，只能拉低，不能主动拉高，靠外部上拉电阻把线拉回高电平。这种设计天然支持多设备“线与”——只要有一个设备拉低，总线就是低，从而实现了最原始的仲裁机制。这也是为什么I2C时序图里总有那些看起来很“圆润”的上升沿——那是RC充电曲线。

1.3 SPI：给“高速传输数据块”设计的同步协议

SPI（Serial Peripheral Interface，串行外设接口）是Motorola在80年代提出的，定位和I2C正好相反：我不管你能挂多少设备，我就是要快，要简单粗暴地把数据倒进来倒出去。

SPI最少需要四根线：SCLK（时钟）、MOSI（主出从入）、MISO（主入从出）、CS（片选）。主机产生时钟，时钟一跑，双方同步移位，一个时钟周期交换一个bit。因为是全双工，而且时钟可以由主机无线调速，SPI可以轻松跑到几十MHz，在嵌入式领域做到数十Mbps甚至上百Mbps的吞吐量不是什么难事。

代价就是：每挂一个从设备，就要独占一个片选脚。如果你的主控GPIO充裕、设备数量在2到3个以内，SPI是效率最高的选择。Flash存储、SD卡（SD卡早期就是SPI模式起步）、显示屏控制器、ADC采样芯片，这些需要批量搬数据的场景几乎是SPI的主场。

SPI没有标准帧格式一说，它只有“时序约定”。CPOL（时钟极性）和CPHA（时钟相位）两个参数组合出四种模式，这也是初学者最容易踩坑的地方——后面我会专门展开讲。

1.4 I2S：给“音频采样数据连续流动”设计的同步协议

I2S（Inter-IC Sound，集成电路间音频总线）是Philips在1986年为数字音频制定的协议，它干的事和上面三个完全不同：它专门传输连续的音频采样流（PCM数据）。

音频数据有一个特点：它是实时产生的，左右声道交替采样，而且对时序连续性要求极高。I2S为此专门设计了三个信号：BCK（位时钟）、LRCLK（左右声道选择时钟/帧同步信号）、SD（串行数据）。有的系统还会加一根MCLK（主时钟），给音频DAC芯片做内部时钟基准。

I2S的典型配置是：BCK频率 = 采样率 × 位深 × 通道数。比如44.1kHz采样率、16bit、双声道，BCK就是44.1k × 16 × 2 = 1.4112MHz。LRCLK的频率等于采样率，低电平期间发左声道数据，高电平期间发右声道数据。你可以把I2S理解成一个永不停歇的流水线——主机不断产生时钟，数据一位一位被推送到DAC里，中间停了就会产生爆音或卡顿。

所以I2S不适合传控制指令，也不适合做通用数据传输，它就是为音频单行道量身定做的。谁要是试图用I2S去传一堆非音频的随机数据，那是真的选错了工具。

2. 时序细节与波形特征：从逻辑分析仪视角看差异

协议对比不能只停留在“引脚功能表”上，拉出真实波形看才是硬功夫。我从波形特征入手，逐个拆解，因为调试时你就是在示波器或逻辑分析仪上认这些波形的。

2.1 UART波形：最简单的电平翻转，但波特率误差是隐形杀手

UART的波形一眼就能认出来：空闲状态是持续的高电平（通常3.3V或5V），起始位是一个明显的下降沿，然后数据位逐个出现，最后停止位拉高。

抓一个115200、8N1（8数据位、无校验、1停止位）的波形，逻辑分析仪上你会看到类似这样的结构：一个低电平段（起始位），跟着8个宽窄不一的电平段（数据位，LSB先行），最后是一个高电平段（停止位）。

关键点是：UART没有时钟线，接收方靠什么保证同步？答案是“起止位+波特率误差容忍”。

接收方在检测到下降沿（起始位）后，会开始用内部时钟计时，然后在每个位时间的中间点采样。这个机制有一个容忍范围，通常要求收发双方波特率误差不超过±2%到±3%。超过这个范围，位采样点就会偏移到数据位边缘，出现乱码或丢字节。

我实际测过，主板用晶振分频出的115200，和USB转串口芯片内部PLL出来的115200，两者误差一般在±1%以内，问题不大。但如果你用软件模拟UART，在忙乱中被中断打断，时序漂移就会积累起来。尤其是一些主频不高的MCU，定时器重装值的四舍五入会让实际波特率偏得离谱。

2.2 I2C波形：起始停止条件和应答位是灵魂

I2C波形比UART复杂，但特征非常鲜明。你抓一次EEPROM写入操作，会看到反复出现的两种“特殊电平变化”：

起始条件（START）：SCL为高电平时，SDA产生一个下降沿。 停止条件（STOP）：SCL为高电平时，SDA产生一个上升沿。

这是I2C协议的符号学基础。在数据阶段，规定SDA只能在SCL为低时变化，SCL为高时必须保持稳定，接收方在SCL上升沿采样SDA。

每个字节传输9个时钟：前8个时钟传数据（高位先行），第9个时钟传应答位。主机发送完8位地址+读写位后，释放SDA，从机如果存在且地址匹配，会把SDA拉低一个时钟周期作为ACK。如果没有ACK，从机根本不在线，波形上SDA在第9个时钟继续保持高电平——这是排查I2C设备不通信时最常见的信号。

这里有个细节：7位地址+读写位正好凑成一个字节。比如RDA5807那个经典收音机芯片，7位地址是0x3C，那么写操作字节是0x78（左移一位补0），读操作字节是0x79（左移一位补1）。很多初学者在代码里写错设备地址，就是因为没搞清楚“7位地址”和“总线字节”之间的换算关系。这也是那些“i2c通信失败”问题里最高频的根因之一。

除了标准帧，I2C还支持重复起始条件（在主从通信中途重新发起START而不发STOP，用于在读操作前切换传输方向），以及10位地址扩展、自由数据模式（比如访问大容量EEPROM时连续读多个字节不需要重新寻址）等变体。但这些都是在基础时序上做加法，先把起始停止、ACK、字节格式看明白，后面都好说。

2.3 SPI波形：看边沿采样，关键是CPOL/CPHA

SPI波形结构上是四种协议里最直观的：CS拉低表示一次传输开始，SCLK在那边连续翻转，MOSI在时钟的某个边沿输出数据，MISO在同一或另一个边沿被采样。但“哪个边沿写、哪个边沿读”就分出了四种模式。

CPOL决定空闲时SCLK电平：CPOL=0，空闲低；CPOL=1，空闲高。 CPHA决定采样发生在哪个边沿：CPHA=0，在第一个边沿采样；CPHA=1，在第二个边沿采样。

以模式0（CPOL=0，CPHA=0）为例：空闲时时钟线为低，第一个边沿（上升沿）采样，第二个边沿（下降沿）改变数据。模式1则是第一个边沿改变数据，第二个边沿采样。

实际工作中，Flash芯片（比如W25Q系列）几乎都在模式0或模式3工作，SD卡SPI模式通常用模式0，部分ADC芯片要求模式1或模式2。调试SPI通信时，逻辑分析仪抓波形，看到数据出现“错一位”或者“第一位丢失”，十有八九就是CPHA设置反了。

关于片选，很多人都踩过“硬件片选”和“软件片选”的坑。软件片选就是用普通GPIO拉低拉高，时序上完全受控，想延时多久就多久，缺点是每次片选切换需要CPU参与。而有些MCU的专用硬件片选（如STM32的NSS），会在SPI传输自动结束时提前拉高，如果从设备要求CS保持低电平直到最后一个位采样完成，硬件片选配上SPI DMA就会偶发性丢最后一个字节。我在调试RK3588SPI接口时就遇到过类似问题：硬件片选默认行为在传输结束立刻释放，导致后级设备收尾数据出错，最后改用软件片选才稳定。

2.4 I2S波形：数据始终在跑，对齐不齐一眼就看出来

I2S波形和前面三种完全不同。你用逻辑分析仪抓I2S，会看到BCK是一个连续的方波脉冲串，LRCLK是一个方波（频率等于采样率），SD线上则是持续不断的bit流。

I2S标准定义：SD数据在LRCLK下降沿之后延迟一个BCK周期开始，也就是“数据比帧信号延迟一位”。左声道数据在LRCLK为低期间发送，右声道在LRCLK为高期间发送。发送方在BCK下降沿改变数据，接收方在BCK上升沿采样。

不过市面上还有左对齐（Left Justified）和右对齐（Right Justified）两种变体。左对齐模式数据紧跟着LRCLK翻转，无延迟；右对齐模式数据对齐到帧结尾。如果主控的I2S控制器和音频编解码芯片配置不一致，你听到的声音就是尖锐的噪声或明显的节奏错乱——这在波形上很难看出来，只能靠对照芯片手册的时序图和控制器寄存器设置来排查。

MCLK是另一个高频坑。很多现代DAC（比如ES8388、WM8960这类编解码芯片）要求主机提供MCLK（或称SYSCLK），用来驱动内部滤波器时钟。MCLK频率通常是采样率的256倍或512倍，比如44.1kHz对应11.2896MHz或22.5792MHz。有些主控片上PLL不一定能分频出这个精确值，系统就得改采样率（48kHz对应12.288MHz）来迁就时钟配置。这就是为什么很多音频板子默认用48kHz而不是44.1kHz——纯粹是MCLK生成更容易。

3. 物理层与拓扑结构对比：引脚、速率和能挂几个设备

下面这张表是四种协议最核心的物理层差异，建议截图保存，选型时直接对照着看。

3.1 I2C上拉电阻怎么选：一个影响全总线稳定性的细节

I2C虽然只有两根线，但这两根线上的上拉电阻选错，整条总线都会出问题。阻值太小，灌电流过大，低电平可能压不下去；阻值太大，RC上升沿太慢，高电平来不及建立，高速模式根本跑不稳。

常用做法是：400kHz快速模式配2.2kΩ上拉，100kHz标准模式配4.7kΩ上拉，总线电容大的时候选小一点。一条经验公式是上升沿时间约等于0.7倍R×C，如果你不知道总线电容，可以先用4.7kΩ起手，逻辑分析仪看上升沿，如果沿变得太缓再换2.2kΩ。我遇到过一块板子，设计时忘了放上拉电阻，I2C扫描一个设备都扫不到，后来飞线焊了俩4.7kΩ才恢复。

还有一个很容易忽视的问题：如果板上有多个I2C器件，而且每个器件子卡都自带4.7kΩ上拉，并联起来等效电阻可能只有1kΩ不到，此时低电平灌电流过大，主机GPIO可能拉不下去，通信时好时坏。做法是多板互联时，只保留主机侧一组上拉。

3.2 SPI为什么可以跑很高：推挽输出和专用片选

SPI之所以能上几十MHz，物理层面有三个原因：推挽输出（高电平和低电平都是主动驱动）、时钟和数据由主机同步产生、片选隔离了无关设备。相比之下I2C的开漏结构和仲裁机制天生限制了速率，要上升沿靠外部电阻慢慢充电，想跑快就得加大电流，功耗和EMI都上去。

SPI的速率上限通常由两方面决定：主控SPI外设支持的最大频率，以及从设备的数据手册标称最大值。比如W25Q128JV手册写可以支持到133MHz DTR模式，但STM32F103的SPI最高只有18MHz（主频72MHz/4），所以瓶颈反而在主控这边。

多设备SPI还有一个做法是“菊花链”（Daisy Chain），多个从设备的MISO和MOSI串联起来，数据像移位寄存器一样级联传下去。好处是省片选脚，坏处是延迟叠加，适合对实时性要求不高但设备多的场景。但在绝大多数嵌入式项目里，老老实实每设备一个CS脚最稳。

3.3 UART为什么看起来“慢”：波特率不是带宽

很多人拿UART和SPI比速率，觉得UART太慢。但注意，UART在115200bps下，有效数据率要打折扣：每传1字节实际占用10个位时间（1起始位+8数据位+1停止位），大概1.152Mbps的线速率只能跑出115KB/s的有效吞吐。如果开了校验和双停止位，还要更低。

所以UART不是用来搬大量数据的。它的优势是简单、长距离版本成熟（RS-485能跑1200米）、协议可以自定义加帧头校验帧尾。16550这个经典UART芯片定义了现代串口的寄存器规范，一直沿用到今天，也侧面说明这个协议的生命力有多长。

4. 项目选型决策指南：什么场景选哪个协议

理论上讲清楚之后，落到实际项目里怎么选型，我给出几个具体的决策路径和案例参考。

4.1 选型决策树：三步帮你定方向

1. 先看数据量：如果你每个事务只是交换几个字节（传感器读数、寄存器配置），I2C通常最合适。如果你要连续搬移几KB到几MB的数据（固件更新、图像帧、音频流），考虑SPI或I2S。
2. 再看方向：如果两个设备互相对发数据，且都主动发起通信，UART最宽松（双方都是主机没有从机概念），SPI则要设计好从机中断机制来模拟双向主动通信。I2C的主从模型决定了它适合“主机主动轮询从机”。
3. 再看设备数量：一板上挂超过3个同总线外设，I2C最省引脚。设备数量少但追求速率，SPI。音频数据最后一定要落到I2S，不要再拿SPI去模拟曼彻斯特编码传音频采样，那是给自己找麻烦。

4.2 案例拆解1：环境监测节点

我之前做一个环境监测节点，板载主控STM32。温湿度传感器SHT40用I2C接，因为就是周期性读几字节温湿度数据；气压传感器BMP390也在同一条I2C总线上，地址不同，扫描一次就能发现。日志和调试接口走UART，接到USB转串口模块（FT232R这类），上位机读串口助手看输出。板载Flash W25Q32用于存储历史数据，用SPI接，因为写入几百条日志要批量搬数据，SPI比I2C快一个数量级。

这个案例里四个协议用了三个，各司其职。音频芯片压根没出现，所以I2S没被用到——但项目里如果加上音频播报功能，话题就完全不同了。

4.3 案例拆解2：带触摸屏的音频播放器

这是我做过比较复杂的一个嵌入式设备。主控是ESP32-C3。

• 音频输出：编解码芯片ES8388通过I2S接收主控发来的PCM数据，同时通过I2C配置寄存器（耳机音量、采样率、通路切换）。同一个芯片上出现了I2S传数据、I2C传控制字，这个组合非常经典。
• 触摸屏：GT911电容触摸屏走I2C，地址是0x14/0x5D可选。初期老是通信失败，后来发现就是上拉电阻阻值不对加上I2C地址模式判断错误，改完就好了。
• 显示屏初始化：部分屏初始化参数通过SPI写入，或者有些屏幕原生就是SPI接口。
• 主控和另一颗MCU之间：用UART交互命令，格式化成JSON字符串。

这个项目的经验就是：一颗音频编解码芯片上I2C和I2S并存是标准玩法，I2C管“配置”，I2S管“数据”，两套协议分工明确。配置和数据分离，这是一个很重要的设计思路——不要在音频数据流里嵌控制信息。

4.4 特殊场景：FPGA+SPI ADC的高速采样

FPGA项目里，SPI几乎是绝对主角。比如要通过ADC采集高速信号送到FPGA处理，一颗20MHz采样率的ADC通常就是SPI接口，FPGA把SPI的SCLK当作采样时钟的一部分来设计，时钟连续翻转，数据不断涌入。这时候SPI的“同步、连续、可高带宽”特征全部发挥出来了。

在这种场景下，I2C就完全不适合——20MHz的采样率意味着每秒要传几百万字节，I2C在400kHz下每秒最多50KB，差了两个数量级。而UART即使跑到2Mbps也只有250KB/s，同样不够用。所以FPGA+高速ADC选SPI是唯一合理选项。

4.5 混合系统中协议并存：管理面与数据面分离

很多复杂系统里，你会看到同样的芯片同时用I2C和SPI甚至UART接出不同功能。比如一款交换芯片或PHY，调试接口是UART，寄存器管理口是MDIO（类似I2C的管理总线）或I2C，固件启动则挂在SPI NOR Flash上。这就是“管理面与数据面分离”的经典架构——SPI快速搬数据，I2C管配置，UART做人机调试。

如果你的系统里也有多协议并存的需求，记住一个原则：数据流走SPI或I2S，控制流走I2C，调试流走UART。按这个原则分配接口，后期维护会省心很多。

5. 实战调试经验：我在调这四个协议时踩过的坑

最后这部分是干货中的干货。以下每一个问题都是我在实际项目中真实遇到过、并且花时间排查过的，希望你能绕过。

5.1 I2C：总线锁死和上拉电阻的连锁反应

I2C有一个特别恶心的故障：总线锁死。现象是SDA一直为低，所有通信都失败。常见原因是某次通信异常时，主机或从机在发送数据中途释放了时钟，从机状态机卡在“等待时钟”的中间状态，SDA上的低电平被锁死。解决办法很简单——把SCL手动翻转9个时钟，从机状态机就能复位。

我自己就遇到过GT911触摸屏I2C通信失败的问题：上电后触摸屏偶尔能识别、偶尔死锁，排查到最后是上拉电阻选择不当导致高电平建立太慢，再加上电源上电时序中复位信号和I2C初始化竞争。对策是先硬件复位触摸屏，延时100ms再配置I2C，并且把上拉电阻从10kΩ换成4.7kΩ，问题彻底消失。

5.2 SPI：CPOL/CPHA配反让数据“全对又全错”

调试SPI Flash时最迷惑的现象是：读出来的芯片ID前几个字节正确，后面全错。这通常不是驱动的问题，而是模式不匹配。W25Q系列支持模式0和模式3，很多主控默认用模式0，但如果之前别人把模式配置成了3，读回来的数据会有细微差异。

我的排查步骤固定在五步：先用逻辑分析仪抓CS、SCLK、MOSI、MISO四根线，和从设备手册的时序图对照；确认CPOL空闲电平和手册一致；确认CPHA采样边沿和手册一致；检查CS有效期间是否覆盖了整个传输过程；最后用只读命令（比如读JEDEC ID）验证，因为读ID不改变芯片状态，反复试模式安全。

有一次我在STM32上用SPI DMA读ADC，数据偶尔跳变，根因是SPI开启DMA后，DMA传输完成中断比最后一个字节采样完成早半拍，我在中断里立刻读了SPI_DR寄存器，拿到的是旧数据。解决方案是等待SPI空闲标志（BSY位清零）后再读数据，或者把DMA的传输宽度改成半字。

5.3 UART：波特率误差和USB转串口芯片的坑

UART调试时如果出现“能发不能收”或“收的数据有规律性错误”，大概率是波特率误差问题。比如用8MHz内部RC振荡器的MCU硬跑115200，分频系数不是整数，实际波特率可能偏了3%以上，接收方向就会出现数据低位错误。

另外一类高频问题是USB转串口芯片的驱动选择。FT232R、FT231X这类芯片在Windows下驱动装不对，会识别成未知设备或端口不工作。调试时先确认设备管理器里识别的是“USB Serial Port”，再检查驱动版本。国产兼容芯片另说，它们偶尔会出现掉线，这是芯片本身的问题，不是协议的事。

UART还有一个隐蔽坑：如果只接了TX和RX，但设备端开着硬件流控（RTS/CTS），接收方可能因为CTS被拉低而拒绝发送。我接过一个GPS模块，怎么发命令都不回应，后来发现它默认开启了RTS/CTS流控，把主控空余的两个GPIO接过去模拟RTS/CTS信号才恢复。

5.4 I2S：DMA缓冲和左右声道对齐

I2S调试最讨厌的是无声或噪声。我遇到过ESP32-C3 I2S输出到外部DAC后没有声音的情况，逻辑分析仪看BCK和LRCLK都有波形，SD线上也有数据，但DAC没有输出。

排查到最后发现两个问题叠加：一是LRCLK的极性配反，本该低电平为左声道，配置成了高电平为左声道；二是DMA缓冲区的PCM数据字节序和DAC期望的格式不一致。16bit音频数据，DAC期望的是小端序，我代码里按大端序填充，导致每个采样值高低字节颠倒，解出来的就是噪声。

调试I2S的基本功是把MCLK/BCK/LRCLK的频率测准，三个频率关系必须满足：MCLK = 256×采样率或512×采样率，BCK = 采样率×位深×通道数，LRCLK = 采样率。如果测量结果偏离这个比例超过1%，音频一定出问题。

5.5 调试工具和通用方法

说一千道一万，调这四种协议，逻辑分析仪是我最推荐的工具。现在市面上的廉价逻辑分析仪配合上位机软件，就可以同时抓十几路信号，I2C和SPI还能直接解码成十六进制数据，大大缩短排查时间。示波器更适合看模拟细节（上升沿快慢、电平幅度），逻辑分析仪适合看时序关系（谁先谁后、采样边沿对不对）。

我自己的习惯是：每一种新协议，先让硬件工程师拉一根测试点，把关键信号都引出来，然后跑一个最简单的loopback或读器件ID的demo，抓波形确认，再进入业务逻辑开发。这一步看起来多花了半小时，实际上省下的查错时间是以天计的。

写在最后的一点个人体会

四种协议放在一起对比，最容易得到的结论是“SPI最快、I2C最省线、UART最简单、I2S最专一”，但实际项目里更重要的不是背这个结论，而是理解它们各自的设计哲学。I2C的地址仲裁、SPI的片选和DMA结合、UART的起止位同步、I2S的帧对齐连续性，每个细节背后都是几十年工程实践的沉淀。

我个人实际体验最深刻的一点是，不要试图用一个协议包打天下。之前在某个项目里，有人试图用SPI去接一个本来应该I2C的传感器，理由是“SPI快”，结果为了模拟I2C的应答位和总线释放，写了上百行的状态机，最后还是不稳定。后来换回I2C，二十行代码解决战斗。协议选型的第一原则是匹配场景，而不是追参数。

最后分享一个小技巧：无论调哪个协议，先在纸上把时序图画出来，标清楚哪个边沿采样、哪个电平有效、地址字节是多少，再写代码。我见过太多人代码写完才发现连从机的设备地址都算错了。把这四种协议的时序图打印出来贴在工位前，比记住所有寄存器配置更有用。