1. 开篇认识为什么嵌入式开发绕不开这两条总线搞嵌入式开发这些年和串口打了无数交道之后你会发现一个规律但凡板子上有点逻辑的传感器、存储芯片、显示屏驱动十有八九走的不是I2C就是SPI。这两条总线几乎是所有MCU项目的“标配外设”不管是STM32、GD32、ESP32还是NXP、瑞萨的芯片参考手册里外设章节写得最多的往往就是这两个。I2C和SPI本质上都属于串行通信协议也就是说数据是一位一位按顺序传输的不像并行总线那样一次传一整字节。它们和UART最大的区别在于UART是异步通信双方各管各的时钟只要波特率一致就能对上而I2C和SPI是同步通信时钟线由主机主动给出从机跟着时钟节奏走。这个本质区别决定了它们在应用中的可靠性、复杂度和使用场景完全不同。先说结论I2C适合低速、引脚紧张、需要挂多个设备的场景2根线就能挂几十个芯片SPI适合高速、大数据量、对实时性要求高的场景但线多一般要4根线才能驱动一个从机。弄清楚这两个协议的区别、各自的工作原理、常见的坑和实战配置方法是嵌入式从业者必须跨过的基础门槛。这篇文章我打算把它写成一篇可以直接“抄作业”的干货手册重点讲透I2C和SPI的物理层设计、时序原理、在STM32上的实际配置方法包括CubeMX DMA这种工程上常用的套路以及我在实际项目中踩过的坑和排查经验。2. I2C通信协议的核心原理2.1 物理层设计开漏输出加外部上拉到底图什么I2C总线只有两根线SCL时钟线和SDA数据线。它俩有一个非常特殊的硬件要求所有设备接入这两根线时驱动方式必须是开漏输出然后在总线上统一接上拉电阻到电源。刚学I2C的人一定问过这个问题为什么非要用开漏输出加外部上拉直接用推挽输出推高推低不香吗答案要从I2C的“线与”特性说起。I2C总线上可以挂很多设备任何一个设备都可以主动把SDA拉低。所谓的线与就是只要总线上任意一个设备输出低电平整条总线就是低电平只有所有设备都不拉低时上拉电阻才把总线拉到高电平。这种机制保证了多个设备同时操作总线时不会发生短路——如果两个设备一个想推高、一个想推低用推挽输出就直接打架了可能烧毁引脚。而开漏输出特性就是只能拉低或者释放配合外部上拉电阻产生了高电平天然实现了这个安全的仲裁机制。上拉电阻的取值不是随便选的这里面有门道。电阻选得太大RC充电时间常数变大上升沿变缓当总线电容较大时信号波形会被“磨圆”高速通信直接出错电阻选得太小灌入引脚的电流大了低电平可能拉不到标准要求例如输出低电平需要低于0.4V设备会被强行拉高甚至可能损伤引脚。根据I2C规范标准模式100kHz、快速模式400kHz下上拉电阻一般推荐在2.2kΩ到10kΩ之间。具体取值可以用下面这个方法估算假设总线电容Cbus为200pF要求上升时间tr不超过1μs标准模式Rmax ≈ tr / (0.8473 × Cbus) ≈ 1μs / (0.8473 × 200pF) ≈ 5.9kΩ。 最小电阻则是为了保证总线低电平不会被拉太高Rmin (VDD - VOLmax) / IOLmax以3.3V系统、VOLmax0.4V、IOLmax3mA计算Rmin ≈ (3.3 - 0.4) / 3mA ≈ 967Ω。所以实际项目里在3.3V系统下我习惯用4.7kΩ或2.2kΩ既保证信号没毛刺又不会让功耗太难看。如果板子走线长、挂的设备多优先选2.2kΩ给总线电容留出余量。之前在一块板子上为了省功耗用了10kΩ上拉结果400kHz通信时灵时不灵示波器一看SCL上升沿已经到了1.8μs波形就是个斜坡换成2.2kΩ后一切正常。2.2 时序核心起始条件、停止条件与数据有效性I2C总线上的一切通信行为都从时序开始。大致过程是这样主机先发出起始条件然后发送一个字节的从机地址加读写位接着根据读写方向传输数据最后用停止条件结束或者发送重复起始条件继续下一笔事务。起始条件START的定义是在SCL保持高电平期间SDA产生一个高到低的跳变。停止条件STOP则是在SCL高电平期间SDA产生一个低到高的跳变。这两者是总线上的“元事件”所有设备都在监听这两个边沿来同步自己的状态机。数据有效性规则更关键在SCL高电平期间SDA上的电平必须是稳定的SDA只有在SCL为低电平期间才允许变化。直观理解就是SCL像相机的快门只有在快门打开高电平那一刻SDA上的电平才被“拍下来”作为有效数据其他时间SDA再折腾都不算数。新手最容易犯的错就是在SCL高电平期间去翻转SDA结果把数据变成长得像起始或停止条件的非法状态总线上所有设备都懵了。2.3 数据帧格式、应答机制与多设备挂载每次传输主机先发出起始条件然后发送从机地址。最常见的7位地址模式下地址字节由7位地址加1位方向位组成方向位为0表示主机要写从机为1表示主机要读从机。所以从机地址0x50实际发送到总线上的字节就是0xA0写或者0xA1读。这一点我在项目里被问过无数次很多人把7位地址和8位地址搞混导致设备无应答。建议代码里明确统一EEPROM这类芯片手册里如果写的是“Device Address 1010 000”7位那发送时要左移一位再拼上读写位如果直接写的是0xA08位那发送时就别动了。地址发出去之后从机如果发现自己被寻址会在第9个时钟周期把SDA拉低这就是应答位ACK。如果从机没应答SDA在第9个周期保持高电平主机就知道没人理它。写入数据时每个字节后面同样跟着一个应答位读取数据时主机在收到最后一个字节后要发送一个非应答NACK然后紧跟停止条件从机就知道“读完了释放总线”。应答机制看似简单实际调试时用逻辑分析仪看波形是最直观的我排查I2C问题几乎全靠逻辑分析仪配合解析脚本来定位是卡在寻址阶段还是数据传输阶段。挂多个设备时要留意I2C地址是7位的去掉保留地址后理论最多能挂112个设备。但实际限制往往是总线电容——每挂一个芯片都会增加负载电容线长、引脚寄生电容累积起来信号质量就会恶化。挂的设备多了以后建议降低通信速率比如从400kHz降到100kHz并且尽量把总线布线缩短。3. SPI通信协议的核心原理3.1 四线制分工SCLK、MOSI、MISO、CS的作用SPI是Motorola提出的一种高速全双工同步串行总线。标准配置是四根线SCLK串行时钟、MOSI主出从入、MISO主入从出、CS片选从设备选择线。和I2C最大的不同是SPI没有应答机制主设备就是“我说什么你听什么”时钟给多少数据就移多少传输效率高但可靠性由硬件和协议本身保证。SCLK由主机产生频率可以很高常见的有几MHz到几十MHz。MOSI和MISO是两根独立的数据线所以SPI天然支持全双工同一时刻既能发送又能接收这一点在做“读传感器数据之前要先写寄存器地址”这种操作时非常有用——写寄存器地址的同时芯片就已经把状态或数据灌到MISO上了。每个从机的CS引脚必须单独拉低才能被选中。只要CS为高从机的MISO引脚必须处于高阻态释放总线否则多个从机同时驱动MISO就会打架。CS这根线在实际项目中常常被忽略尤其是用硬件片选的MCU时配置不到位就会出现“第二个从机读不到数据”的诡异问题。3.2 CPOL和CPHA四种模式怎么选SPI有四种工作模式由两个参数决定CPOL时钟极性和CPHA时钟相位。CPOL决定空闲时SCLK的电平CPOL0时空闲为低电平有效边沿是上升沿CPOL1时空闲为高电平有效边沿是下降沿。CPHA决定数据采样是在第一个边沿还是第二个边沿CPHA0时数据在第一个时钟边沿被采样CPHA1时数据在第二个时钟边沿被采样。所以就有了经典的四组组合模式0CPOL0CPHA0空闲低上升沿采样最常用模式1CPOL0CPHA1空闲低下降沿采样模式2CPOL1CPHA0空闲高下降沿采样模式3CPOL1CPHA1空闲高上升沿采样实际选型时一定以从机数据手册为准。大多数Flash芯片、SD卡、LCD驱动默认支持模式0或模式3比如W25Q系列Flash默认工作在模式0和模式3都行。我在配置SPI时习惯先把模式0跑一遍如果不通再用示波器抓波形对比手册里的时序图看是采样沿差了一个拍还是极性反了。调试SPI时用示波器同时抓SCLK和MOSI、MISO是最直观的定位方式。还有一种判断技巧看手册里数据是在SCLK的哪个边沿有效。比如手册说“Data is latched on the rising edge of SCLK”如果空闲时SCLK是低那第一个上升沿就是采样沿这就是模式0如果空闲时SCLK是高那第一个上升沿其实是第二个时钟边沿得考虑它和CPOL的组合关系。不要硬背模式编号理解“你在哪个边沿采样”才是关键。3.3 片选控制的两种方案硬件片选和软件片选怎么取舍SPI的CS片选工程里通常有两种处理方式用MCU的硬件片选引脚比如STM32上的NSS或者用任意GPIO做软件片选。硬件片选的优点是自动管理每次通信开始前由外设自动拉低NSS通信结束自动拉高SPI外设和DMA配合得比较好不用CPU干预。但缺点也很明显很多MCU的硬件NSS行为并不灵活尤其在做“读Flash时CS必须保持低电平直到读完整个数据帧”这种长操作时硬件片选可能会在某个阶段提前释放导致从机以为事务结束了数据直接错乱。软件片选是用普通GPIO去控制CS传输前手动拉低传输完毕后手动拉高。这种方式灵活性和可控性极强特别是在操作那些有复杂命令序列的芯片时我可以精确控制CS在每一帧之间的保持时间。缺点是每次传输需要额外的GPIO操作时间开销但对绝大多数应用来说这个开销完全可以忽略。实操中我的经验是单从机场景硬件片选和软件片选都行但更推荐软件片选因为排查问题时逻辑更简单多从机场景几乎必须用软件片选——每个从机接一个GPIO想操作哪个就把对应GPIO拉低。另外要注意所有从机的MISO必须支持高阻释放否则你选中的从机在回数据的同时其他从机也可能在MISO上产生电平冲突。4. 实操STM32F103上I2C和SPI的配置与代码解析4.1 用CubeMX快速生成I2C和SPI的初始化工程STM32生态里现在绝大多数项目都用STM32CubeMX配置外设初始化代码再在生成的工程基础上添加业务逻辑。我这里以STM32F103C8T6为例讲一下关键配置。在CubeMX中I2C的配置相对简单选择I2C1后Mode设为I2CSpeed Mode选Standard Mode或Fast Mode时钟频率填100000或400000注意芯片本身外设时钟频率要设置在合理范围否则I2C时序配出来会偏。如果代码需求很简单不需要那么多高级功能Duty Cycle保持默认即可硬件I2C一般不会有大问题。SPI的配置需要多花点心思选择SPI1后Mode设为Full-Duplex Master方向选Tx and Rx硬件片选如果不用记得把NSS设置为软片选模式Software NSS否则会占用一个引脚还要留意它的电平变化时钟预分频器决定SCLK频率比如APB2时钟72MHz预分频128后SCLK大概是562.5kHz这个速度对大多数Flash和传感器足够时钟极性CPOL和相位CPHA参照从机手册设置一般Flash和SD卡芯片模式0或模式3都兼容。还有Data Size选8bitMSB先传输这是和大多数外设芯片约定的标准。生成完工程后不要急着写业务代码先确认初始化代码里GPIO的复用时序设置是否正确。STM32CUBE生成的代码里_HAL_RCC_GPIOA_CLK_ENABLE()、GPIO_InitStruct、SPI/I2C的Init结构体一并做好这些配置由CubeMX搞定比手写库函数时代省了不少事。4.2 I2C读写EEPROMAT24C02完整代码与注意事项AT24C02是一块非常经典的I2C EEPROM容量256字节7位地址一般为0x50。用它来练手I2C读写再合适不过。先写一个单字节写函数。AT24C02的写时序是起始条件 - 发送设备地址0xA0- 等待ACK - 发送寄存器地址 - 等待ACK - 发送数据 - 等待ACK - 停止条件。代码如下uint8_t AT24C02_WriteByte(uint16_t addr, uint8_t data) { uint8_t dev_addr 0xA0; // 0x50左移一位加写位 I2C_HandleTypeDef *hi2c hi2c1; // 第1步发送起始条件设备地址写位 if (HAL_I2C_Master_Transmit(hi2c, dev_addr, addr, 1, 100) ! HAL_OK) return 1; // 注意上面这种写法是错误示范addr是16位直接取地址传输会出错 // 正确做法是拼一个缓冲区buffer[0]设备地址buffer[1]寄存器高地址buffer[2]寄存器低地址…… }这里必须指出一个新手常见误区HAL_I2C_Master_Transmit的第二个参数是设备地址第三个参数是要发送的数据缓冲区指针长度为第四个参数指定的字节数。虽然函数名叫Master_Transmit但它发送的并不完全是“原始数据”而是会把设备地址、方向位和你要发的内容一起组合成完整的一帧所以不要再单独去发设备地址了。正确的写操作应该把“寄存器地址”和“要写入的数据”放到同一个缓冲区里uint8_t AT24C02_WriteByte(uint16_t mem_addr, uint8_t data) { uint8_t buf[2]; buf[0] (uint8_t)(mem_addr 0xFF); // AT24C02地址只有8位高字节不用 buf[1] data; if (HAL_I2C_Mem_Write(hi2c1, 0xA0, (uint16_t)buf[0], I2C_MEMADD_SIZE_8BIT, buf[1], 1, 100) ! HAL_OK) return 1; HAL_Delay(5); // 等待EEPROM内部擦写完成 return 0; }更好用也更安全的方法是调用HAL库的HAL_I2C_Mem_Write专门用来操作这类带内部地址的存储类芯片参数里直接传设备地址、存储地址、地址宽度和数据。读操作更简单HAL_I2C_Mem_Read直接指定从哪个地址开始读它内部会自动执行“先写地址再读数据”的复合时序。EEPROM的页写特性要注意一页通常8字节或16字节向同一页连续写数据时如果超过页边界地址回卷到页首会覆盖已有数据。项目里如果一次性写超过一页的数据必须拆分成多次写操作或者一次一页地写中间加5ms以上延时。硬件I2C在STM32F1上曾经被很多人吐槽过“有Bug”其实多数情况下都是初始化配置或外部上拉电阻没处理好导致的问题。在硬件I2C上我建议先确认SCL和SDA引脚没有错误复用并且外部确实接了上拉电阻。非要用GPIO模拟I2C也不是不行但工程上能省事就省事硬件I2C在F1上完全能用我做了十几块板子都没翻过车。4.3 SPI通过DMA方式读取W25Q16 Flash数据完整流程SPI和DMA结合是嵌入式里做大数据块传输的常用手段典型场景就是读Flash。比如W25Q16这颗SPI NOR Flash用DMA把整块数据搬进内存CPU就可以去处理别的事效率提升非常明显。这里以“使用CubeMX生成SPIDMA的配置方案”为例详细过一遍流程。CubeMX里除了把SPI1配成Master还要使能SPI1的TX DMA和RX DMA请求。在DMA Settings里添加两个DMA通道一个设置为SPI1_TX另一个设置为SPI1_RX模式都选Normal模式因为每帧传输长度不固定循环模式容易出bug。注意数据宽度要和SPI的数据宽度保持一致配置为Byte。SPI外设的中断在DMA模式下可以不用开但DMA传输完成中断要开这样才能在接收完成后处理数据。W25Q16的读操作时序是CS拉低 - 发送0x03读命令- 发送24位地址3个字节- 连续读取数据 - CS拉高。DMA配合时有一个坑特别值得说SPI的接收是通过发送哑字节来产生时钟的所以在启动DMA接收之前必须先启动DMA发送发送的数据可以是0xFF哑字节。否则只有RX DMA在工作没有时钟数据根本进不来。工程里常用的代码结构如下// 启动DMA读先确保发送和接收都指向正确的缓冲区 HAL_SPI_Transmit_DMA(hspi1, dummy_buf, data_len); HAL_SPI_Receive_DMA(hspi1, rx_buf, data_len); // 注意实际项目中不建议两句话连续调用更好的做法是 // HAL_SPI_TransmitReceive_DMA 一次性同时启动收发其实HAL库提供了一个更省心的接口HAL_SPI_TransmitReceive_DMA它在同一个函数里同时启动发送DMA和接收DMA不用手动去管两条DMA通道谁是主谁是辅只要把tx_buf和rx_buf分别传进去配合一个dummy数组和接收数组即可。数据接收完成后在DMA传输完成中断回调里把CS拉高这一帧读操作才算完整结束。写Flash时也要注意写命令0x02、使能命令0x06之后要等待芯片内部完成擦写。轮询状态寄存器0x05命令的方法比固定延时更可靠——我之前用固定延时5ms这种方式写过一次数据结果高温下Flash偶尔状态没完成就开始下一次写数据直接丢了。后来改成读状态寄存器等待BUSY位为0再也没出过问题。4.4 初始化配置的关键参数速查表下面整理了一张我在实际项目中常用的配置速查表覆盖STM32F103其他型号思路一样主要看时钟频率外设配置项常用取值说明I2C1ModeI2C硬件I2CI2C1Speed ModeFast Mode / 400kHz若总线过长或负载较多降到100kHzI2C1上拉电阻2.2kΩ~4.7kΩ外部电阻优先于内部上拉SPI1ModeFull-Duplex Master全双工主机SPI1NSSSoftware NSS用GPIO控制片选更灵活SPI1BaudRate2.25MHz~9MHz不要超过从机上限留意布线质量SPI1CPOL/CPHAMode 0或Mode 3以从机手册时序图为准DMASPI1_TX / SPI1_RXNormal模式Byte宽度循环模式只适合连续采样流这个表不是标准答案但基本覆盖了我在绝大多数项目里的常见选择。实际还是以从机芯片手册为准尤其是SPI速率这块很多Flash写着支持100MHz但那是芯片级极限板级布线不好时高速奔跑大概率出问题。5. 常见问题与排查技巧实录5.1 I2C上拉电阻太小导致无法通信之前做过一块板子为了追求低功耗把SDA和SCL各接了一个3.3kΩ上拉到3.3V理论上应该没问题。但实际测试时400kHz通信完全不稳定偶尔能读到一个字节多读几次就死掉。用示波器抓SDA波形发现低电平时SDA的电压最低只能拉到1.2V左右正常情况下低电平应该低于0.4V。这个现象说明上拉电阻太小了从机的灌电流能力不足以把总线拉到足够低的电平结果从机识别不到有效的低电平通信自然失败。排查方法非常简单断开所有I2C设备只留主控和一颗从机量一下SDA、SCL对地电阻。正常情况两根线上量到的阻值都应该是上拉电阻值比如4.7kΩ左右如果量出来只有几百欧姆那肯定有设备的上拉或内部电阻并联了逐一把设备摘掉排查。最终方案就是把上拉电阻从3.3kΩ改成4.7kΩ波形恢复正常。需要注意另一个坑有些MCU的GPIO内部有上拉电阻比如STM32的内部上拉大约30kΩ到50kΩ如果外部上拉电阻也接上了两者并联会降低总线低电平的可驱动能力。I2C总线的正确做法是必须加外部上拉但内部上拉最好在配置时关掉否则等效上拉阻值不可控。5.2 SPI通信不生效从波形里找原因SPI通信不生效最常见的三种原因按优先级排序时钟模式和从机不匹配、片选时序问题、SCLK频率太高信号失真。时钟模式不匹配时从机的采样沿刚好错过了数据的中点导致接收数据位全是0或随机值。这种情况下直接用示波器看SCLK和MOSI波形对比从机手册里的时序图最直观。如果SCLK空闲电平是低MOSI在上升沿前后稳定那用的就是模式0如果从机要求模式3SCLK空闲高采样沿在上升沿那你把配置改成模式3即可。片选时序问题更隐蔽。有些芯片在CS拉低后还需要一段tSUsetup time才允许SCLK出现或者在CS拉高后需要一段tHhold time。如果SPI帧结束后立即拉高CS可能连最后一个字节都没传完就中断了。我的经验是CS操作尽量用延时或者让DMA完成后回调里再拉高不要直接在发送函数返回后立刻操作CS。SCLK频率过高导致的信号失真一般表现为通信时好时坏在高温或加长杜邦线后问题加重。用示波器看SCLK上升沿如果已经出现明显振铃overshoot/undershoot就说明信号质量出问题了。处理方法是降频比如从18MHz降到4.5MHz另外把SPI数据线尽量走短走粗地线铺好大多数问题都能缓解。5.3 SPI DMA接收的常见坑与解法DMA配合SPI接收有几个特别经典的坑我这里逐个说。第一个是“只有TX DMA工作RX DMA数据全是0xFF”。原因是SPI的RX通道需要时钟才能采到数据而时钟又来自主机发送的数据。如果你的收发没有同时启动RX就会一直停在初始状态收到的是总线空闲电平0xFF。解决方法是必须同时启动收发或者发送和接收共用同一个DMA请求。第二个是“DMA传输完成中断触发后数据还是旧的”。原因是DMA传输完成中断里处理数据时SPI外设可能还有最后几个字节在移位寄存器里没完全读出。稳妥的办法是在传输完成中断回调里先清标志再延时几十微秒或者等待SPI外设状态寄存器里的BSY位清零然后再去读接收缓冲区。第三个是“HAL_SPI_TransmitReceive_DMA在多次调用后死机”。排查发现是上一次传输还没结束时再次启动了传输导致DMA通道状态错乱。解决办法是每次启动前先检查SPI的状态等上次传输完成标志置位后再进行下一次。我一般用信号量或者标志位来同步确保同一时刻只有一个DMA传输在进行。再补充一个和DMA无关的坑SPI读Flash时如果软件片选CS在每次时钟传输后立刻拉高Flash对多字节读命令0x03是支持的它会连续输出数据直到CS拉高但如果主机的DMA接收长度和实际读出的数据字节数不匹配就会出现数据错位。务必保证你请求接收的字节数和芯片实际输出的字节数一致。6. 应用场景对比与选型建议6.1 啥时候用I2C啥时候用SPI选型这件事没有万能的答案但有一些清晰的规律可以参考。I2C的优势在引脚少、多设备拓扑方便。哪怕主控引脚紧张两、三个GPIO就能搞定一堆传感器比如温湿度传感器SHT30、气压计BMP280、触摸按键芯片、EEPROM这些全是I2C接口。而且这些传感器本身数据量小采样率低100kHz或400kHz的速率完全够用。I2C还有一个先天优势是总线支持多主机仲裁两个主控可以挂同一条总线上做冗余切换这在一些需要备份机制的项目里特别实用。SPI的优势在速度和吞吐量。如果你要驱动1.8寸TFT屏做GUI刷新、要读大容量Flash、要采集高频ADC的数据I2C就完全带不动了。SPI动辄几十MHz的时钟频率配合DMA可以做到几乎没有CPU开销的持续数据搬运。另外SPI没有地址帧、应答帧这些额外开销每字节的真实传输效率远高于I2C适合对时序敏感的场合。两者也各有短板。I2C的应答机制增加了协议开销高速下容易受干扰网络上很多人吐槽I2C抗干扰差其实多半是上拉电阻和布线问题。SPI没有应答机制接收端如果没准备好主机不会知道所以SPI通常用于“从机是简单外设、时序可控”的场景如果想做复杂的校验和重传要么在软件协议层自己加要么改选CAN这类带错误处理的总线。6.2 从引脚、速率、复杂度三个维度做决策如果手头有个项目拿不准用哪个总线可以按下面这个思路过一遍速率需求数据量小于1kbps选I2C数据量大于1Mbps选SPI。引脚预算引脚紧张、要挂3个以上设备且全是慢速传感器选I2C引脚宽裕、只接一两个高速外设选SPI。软件复杂度I2C在软件层面的时序和状态机相对简单但有ACK、NACK、重试这些机制调试要多花点精力SPI的代码结构更直白就是发字节、收字节但没有错误反馈排查问题时只能靠波形说话。从机芯片生态很多传感器、EEPROM、RTC只有I2C接口而Flash、SD卡、LCD驱动、ADC采样基本都是SPI接口。选型时先看你要用的外设芯片支持什么协议协议就定了剩下的只是参数调优。还有一种常见需求是既想用I2C的低引脚又想用SPI的高速那就得考虑取舍或者折中方案了。比如某些传感器同时支持I2C和SPI两种接口这时候我会优先选SPI因为SPI的实时性和吞吐量更好而且SPI在初始化上不容易踩到自己埋的坑。反过来如果仅需要周期性地读取环境温度1Hz更新一次I2C就绰绰有余没必要为用SPI而用SPI。7. 工程经验总结与后续扩展方向我在项目里最终选哪条总线通常会加上一个隐含考量团队里维护代码的人容不容易上手。I2C的调试资料多、逻辑分析仪支持好新人出错也好排查SPI虽然快但对波形和时序的要求更高没人带的话容易花很多时间去调模式匹配。所以说技术选型不只是看芯片手册的参数还要看整个项目组的经验和工具链。真实项目中很有价值的一个经验是先把I2C和SPI的现象摸清楚再写驱动代码。我调试任何一颗新的I2C或者SPI从设备都会先用逻辑分析仪抓一下polling模式的原始波形确认ACK、地址、命令都能够正常交互再去写DMA复杂的收发流程。这样在DMA出问题时大概率能断言是DMA配置的问题而不是协议本身的问题。这篇文章只是把I2C和SPI的基础原理、配置流程、常见问题做了一个系统性梳理实际项目里它们还能和中断、DMA、RTOS信号量、环形缓冲区配合出各种花样。后续如果有机会我再单独写一篇“用逻辑分析仪三步定位I2C诡异问题”的实战记录把那些偶然踩到的坑和排查顺序完整复盘出来。如果你手头正遇到某个具体的通信异常用示波器或逻辑分析仪抓一下波形再对着这篇里的排查思路过一遍大概率能定位到原因。
