企业官网建设流程全解析

I2C和SPI这两个协议，我前前后后用了快十年了。从最早调一个陀螺仪传感器，到后来在产线上帮客户排查一批主板通信不稳的问题，再到现在带新人写驱动，几乎每天都在跟这两兄弟打交道。可以说，搞嵌入式如果能把I2C和SPI吃透，板级通信这块基本就稳了一大半。这篇就把我这些年积累的、踩过的坑、总结出的经验，一次性讲清楚。

先说说为什么这两个协议这么重要。在嵌入式系统里，芯片和芯片之间、主板和传感器之间要交换数据，方式无非就那么几种：UART、I2C、SPI、CAN，加上现在越来越常见的USB和以太网。其中I2C和SPI是板级通信（也就是同一块PCB上芯片之间通信）的绝对主力。你随便拆一个开发板、一个物联网模组、一个电机驱动板，上面至少有七八颗芯片是通过I2C或SPI挂在主控上的。它们管的事包括但不限于：读传感器数据、配置音频解码芯片的寄存器、读写Flash、控制屏幕、扩展IO口。

这两个协议看起来简单，实际用起来门道很多。I2C的外围电路就几个电阻，但选型不对直接通信失败；SPI速率上限很高，但模式配错、片选选错，数据全是乱的。很多初学者在Arduino或者STM32上能跑通Demo，一放到自己设计的板子上就翻车，往往就是没搞懂协议背后的电气原理和时序细节。

这篇文章我打算分几块来讲：先把I2C的完整工作原理、上拉电阻选型、时序细节掰开揉碎；再把SPI的四种模式、硬件片选和软件片选、DMA传输这些核心点讲透；最后结合实际调试经验，给出一份常见问题排查清单。不管你是准备入门的新手，还是被I2C波形折磨过的老手，这篇文章应该都能给你一些新的启发。

1. I2C通信协议核心拆解

I2C（Inter-Integrated Circuit）是Philips（现在的NXP）在1982年发明的，初衷就是让电视、音响这类消费电子设备内部能用更少的线连接各个芯片。它的设计极简却非常有生命力：两条线，一条时钟SCL，一条数据SDA，就能挂上百个设备。这也是它到今天仍在使用的根本原因。

1.1 为什么是开漏输出加上拉电阻，而不是推挽输出

这个问题我面试过很多人，十个有八个答不完整。I2C为什么不能像SPI那样直接推挽输出？关键在于“多主机仲裁”和“设备热插拔”这两个需求。

先看多主机仲裁。I2C允许总线上挂多个主机，两个主机同时发起通信时，怎么决定谁先谁后？靠的是线与逻辑。开漏输出意味着设备只能把电平拉低，不能主动拉高，拉高的工作由外部上拉电阻完成。这样一来，如果两个主机的输出电平冲突，只要有一个拉低，总线就是低电平，另一个通过回读SDA电平就能感知到冲突，主动退出，这个过程就是仲裁。如果换成推挽输出，两个主机一个输出高一个输出低，直接就是短路，瞬间烧毁引脚。

再看设备热插拔。开漏结构下，每个设备的SDA/SCL引脚其实都是一颗MOS管的漏极，设备不工作时只要不上电，对总线来说就是高阻态，不影响其他设备通信。这对现在很多可插拔的传感器模块特别重要。

所以，I2C外围那两个上拉电阻不是随便放的，它是协议能工作的物理基础。没有上拉电阻，总线永远是低电平，通信完全瘫痪；上拉电阻选得不对，不是波形爬不上去就是功耗超标。

1.2 上拉电阻的选型计算与100k速率的特殊场景

上拉电阻的数值怎么定？我一般直接按下面这个思路算。

电阻不能太大，因为总线存在寄生电容，RC充电时间常数决定上升沿时间。I2C规范里标准模式（100kHz）要求上升沿不超过1000ns，快速模式（400kHz）要求不超过300ns。你这个板子上总线的寄生电容，粗略估法是一根走线大概1pF/cm，加上每个芯片引脚还有几pF，一条总线上挂四五个设备，总电容差不多50pF。用公式t_rise≈0.8473×R×C反推，100kHz模式下R取10kΩ，上升沿差不多是424ns，符合要求；但400kHz模式下就必须降到3kΩ以下了。

电阻也不能太小，因为设备拉低总线时，电流要流过这个电阻。2V到5V的系统里，阻值太低，灌入引脚的电流可能超出芯片的灌电流能力（IOL，一般是3mA到20mA），还会额外消耗功耗。

我的习惯是：3.3V系统、100kHz标准模式，选4.7kΩ到10kΩ都能跑；跑400kHz，选2.2kΩ到4.7kΩ；如果总线很长、挂载设备很多（超过8个），就选1kΩ到2.2kΩ。

这里特别说一下热搜词里那个“100k I2C信号规格”。我猜这是指低速场景，比如EEPROM等一些器件在配置阶段只支持100kHz甚至更低。这种情况把主控的I2C时钟配置成100kHz以下，同时上拉电阻可以适当选大一点，比如10kΩ甚至20kΩ，以降低功耗。但要注意，不是所有从机都支持低速，某些新的传感器芯片要求最低400kHz才能完成初始化序列，如果用了太大的上拉电阻导致边沿过缓，从机可能识别不到起始信号。所以最稳妥的做法是：先用数据手册确认器件的最高和最低通信速率，再做配置。

1.3 时序是如何保证的：起始、停止、数据、ACK

I2C的时序可以拆成四个基础动作，理解了这四个动作，基本就能看懂示波器上的任何I2C波形。

起始条件（START）：SCL为高电平时，SDA从高跳变到低。这个动作宣告总线开始通信。

停止条件（STOP）：SCL为高电平时，SDA从低跳变到高。这个动作宣告总线释放。

数据传输：SDA上的数据必须在SCL高电平期间保持稳定，只在SCL低电平期间才能变化。也就是说，数据是在SCL上升沿附近被从机采样锁存的。这句话是整个I2C时序的核心，能对照着波形图和这句话把数据读出来的话，I2C时序就不再是一个黑盒子。

ACK应答：每传输完一个字节（8位），第9个时钟周期是应答位。主机释放SDA，从机如果正常接收就把SDA拉低，表示“我收到了”；如果从机忙不过来或者地址不匹配，就保持高电平，产生NACK。

实操中我建议初学者做一件事：拿逻辑分析仪抓一段真实的I2C通信波形，对照数据手册手动解析一遍地址字节和数据字节。不要只是跑通代码就完事，手动解析一次之后，你对I2C时序的理解会产生质的飞跃。工具用廉价的Saleae逻辑分析仪或者金沙滩的逻辑分析仪都行，配合PulseView软件免费好用。

1.4 寻址机制：7位地址与10位地址

I2C总线上挂多个设备时，靠地址区分彼此。最常见的7位地址模式，地址范围是0x08到0x77（0x00是广播地址，0x01到0x07保留，0x78以上留作10位地址扩展）。发送地址时，主机发送的是7位地址左移一位后的结果，最低位是读写标志：0表示写，1表示读。所以你在代码里经常看到0x68、0xD0这种写法，前者是7位地址（比如MPU6050），后者是把7位地址加上读写位后的8位形式。这个细节经常让新手困惑，我见过有人把器件地址搞反，连调一周都读不到数据。

7位地址只能挂127个设备，实际器件一般通过地址引脚（A0、A1、A2）来设置低几位，比如常见的EEPROM AT24Cxx，用A0、A1、A2引脚组合出8个不同地址，一条总线上最多挂8颗同样的芯片。10位地址模式用得少，一般只在需要大量设备的工业场景才用，日常开发碰到的概率很小。

1.5 I2C的扩展应用和常见误区

总线上需要挂的设备太多，或者从机地址冲突时怎么办？两种方案比较常用：

一是I2C多路复用器，典型芯片是TCA9548A，它可以把一条I2C总线扩展成8路，每路都可以挂完整的设备链。注意，复用器的切换命令要在通信间隙发送，不要在一个连续读操作中间切换通道，否则从机状态会错乱。

二是I2C电平转换器，典型芯片是PCA9306或TXS0102，用来连接不同电压域的I2C总线，比如主控是3.3V，传感器是5V。这里有个坑：很多电平转换器是双向的，但必须正确接参考电压引脚，如果接反了，通信表现为“偶尔成功、随机失败”。之前有个客户，I2C总线挂了一个5V的气压传感器，他们用PCA9306接3.3V主控，结果经常出现读到的气压值跳变，排查半天发现是OE引脚悬空，导致输出高阻态，改成上拉固定使能后问题立刻消失。

还有一个常见误区是I2C是否需要配置内部上拉。很多MCU的GPIO内部自带上拉电阻（典型值30kΩ到50kΩ），但I2C规范一般推荐外部上拉。如果你在板子上已经放了外部上拉电阻，内部上拉可开可不开，影响不大；但如果你懒得放外部电阻，想依赖内部上拉，要注意内部上拉阻值太大，400kHz快速模式下上升沿可能不达标，而且一条总线上多个设备都开启内部上拉，等效电阻还会并联变小，反而影响一致性。我的建议是：硬件设计阶段就规划好外部上拉电阻，软件里不使能内部上拉，减少变量。

2. SPI通信协议核心拆解

SPI（Serial Peripheral Interface）是Motorola在1980年代推出的，设计目标很直接：高速度、全双工、简单到几乎没有协议。它用四根线——SCLK时钟、MOSI主出从入、MISO主入从出、CS片选——实现了点对点的快速通信。速率轻松跑到几十兆赫兹，是I2C的几十倍，所以高速传感器、Flash存储、屏幕驱动这些场景基本都是SPI的天下。

2.1 SPI四种模式：CPOL和CPHA

SPI没有像I2C那样复杂的起始停止条件和ACK机制，它的核心是时钟极性和时钟相位。CPOL（Clock Polarity）决定空闲时SCLK是高电平还是低电平，CPHA（Clock Phase）决定数据是在时钟的哪个边沿被采样。两者组合出四种模式，对应SPI Mode 0到Mode 3。

我在实际项目中总结出来的规律：Mode 0（CPOL=0, CPHA=0）是默认最常用的，大多数Flash、SD卡、LCD屏都支持；Mode 1和Mode 2比较容易踩坑，一般是某些特定芯片要求；Mode 3和Mode 0一样常见，很多射频芯片喜欢用。关键是查器件手册，看到“CPOL=1, CPHA=1”就是Mode 3，不要自己猜。

这里有个常见bug：主从配置不一致时，从机读到的数据完全乱掉，但电平看起来是好的。我在用示波器排查时遇到过几次，最后发现就是CPOL/CPHA错了。排查方法很简单：用示波器抓SCLK空闲电平和数据变化时刻，对照数据手册确定应该用哪种模式。

2.2 硬件片选与软件片选的取舍

片选（CS）的作用是告诉从机“该你上场了”。实现方式有两种：硬件片选和软件片选。

硬件片选，就是MCU的SPI外设自带NSS引脚，启动传输时硬件自动拉低片选。好处是时序精确，从机响应快，尤其适合高速通信；坏处是灵活性差，比如有的MCU只支持固定引脚做NSS，不支持任意引脚映射，或者当总线上挂多个设备时硬件片选管理起来麻烦。

软件片选，就是用普通GPIO手动控制片选。这是我最常用的方式。好处是极大灵活：任何GPIO都可以做片选，总线上挂多少设备都不怕；坏处是时序上可能引入延迟，因为GPIO翻转速度不如硬件外设。这个延迟一般在几百纳秒级别，对几MHz的SPI通信完全足够，但对十几MHz以上的高速Flash读写，需要留意时序余量。

还有一个容易忽略的点：片选电平在两次传输之间是否需要恢复为高电平。有些从机（比如某些Flash芯片）要求片选在高电平后保持一段时间才能进行下一次操作，如果两次通信之间片选拉高时间太短，芯片状态机可能无法复位。我一般会在软件里保证两次CS激活之间至少间隔几个微秒，尤其是同一颗芯片连续读写的场景。具体时长以数据手册为准，不同芯片差异很大。

2.3 SPI的传输结构：上升沿/下降沿采样和MSB/LSB顺序

SPI的数据是按位串行传输的。主控在时钟边沿把MOSI上的数据发出，从机在下一个边沿采样；同时从机在MISO上把数据返回。整个过程是全双工的，主机每发出8位数据的同时，也能收到从机返回的8位数据。

这里有个初学者很容易想不通的问题：为什么读Flash的时候，主控明明只是在发命令，MISO上的数据却是对的？因为SPI是全双工，主机发出的数据就是时钟发生器，从机就是在这个时钟边沿去采样主机发来的命令，同时把自身的数据放到MISO上。所以每次SPI读操作本质上是一个写命令+读数据的同时发生的过程。

MSB（最高位在前）还是LSB（最低位在前）也是常见坑。绝大多数芯片默认MSB first，但有些传感器（特别是国产的某些芯片）默认LSB first。配置错的话，读出来的数据永远是镜像的，比如0x01变成0x80。我在一次调试温湿度传感器时就遇到这个问题，折腾了半小时才发现是字节序反了。

2.4 通过DMA方式读取芯片数据：以STM32F103为例

SPI高速传输时，CPU逐个字节搬运数据会浪费大量算力，所以主流做法是配合DMA（Direct Memory Access）使用。下面我用STM32F103 + CubeMX配置DMA读取一颗SPI Flash为例，讲一下核心步骤。

第一步，在CubeMX里开启SPI外设，配置为主模式，设置时钟极性、相位、波特率，启用DMA请求。SPI的DMA请求有两个方向：RX请求和TX请求。读数据时，RX方向必须开启DMA，并且需要在DMA设置里选择“Normal模式”而不是“Circular模式”。很多初学者在这里用错了模式，导致DMA不收手，内存被写穿。

第二步，生成代码后，在初始化函数里调用HAL_SPI_Receive_DMA(&hspi1, buffer, length)启动接收。但注意，HAL库的SPI DMA模式默认会在传输完成后关闭SPI，而且DMA接收过程中CPU不能直接操作buffer，要在回调函数HAL_SPI_RxHalfCpltCallback或HAL_SPI_RxCpltCallback中处理数据。

第三步，读Flash数据前，主机需要先发送读命令（0x03）和24位地址，这个可以用HAL_SPI_Transmit发送，然后再调用DMA接收。但是坑在这里：如果不想把发送和接收分成两步，可以用HAL_SPI_TransmitReceive_DMA，同时发送命令和接收数据。此时要用一个数组，前几个字节是命令+地址，后面的字节是无效发送（一般填0xFF），接收到的数组前几个字节是无效数据，从第4个字节开始才是真正读到的Flash内容。

我在实际项目中更多是直接操作寄存器或者用LL库来写，因为HAL库的DMA回调机制在某些场景下（比如高频率中断）会有性能瓶颈。但无论用HAL还是LL，核心逻辑是一样的：SPI的DMA传输本质上是“时钟产生器”，主机必须在每个位周期都提供时钟，从机才有机会输出数据。这也是为什么读操作也要发送全0xFF而不是什么也不发。

2.5 STM32半双工SPI：什么时候能用，什么时候别用

STM32的SPI外设支持半双工模式，也就是只使用一根数据线，通过配置方向位选择发送还是接收。这种模式在引脚紧张时可以省一根线，但代价是通信变成半双工，收发不能同时进行。

我的建议是：协议本身就支持半双工的芯片（比如部分LCD驱动、部分传感器）可以用；如果从机是全双工协议，一定不要用半双工模式去驱动，因为从机会同时往MISO上发送数据，但主机根本没有MISO引脚连接，数据没法接收。还有在半双工模式下，由于只需要一根数据线，MOSI和MISO引脚实际上是复用的，如果从机还在等待主机发数据，主机又切到接收，时序上会产生尴尬的中间态。实战中除非引脚确实极度紧张，否则我不推荐半双工模式。

2.6 SPI Flash加载固件的场景：边界与风险控制

热搜词里有个“rtl9071cp-vb 使用spi加载固件”。这指的是从SPI NOR Flash启动的常见设计——主控上电后，通过SPI接口从外接Flash读取固件并搬移到内存里执行。这个机制在路由器、交换机、网卡等设备上非常常见。

这个场景和普通SPI通信最大的区别是：启动阶段主控自身软件还没跑起来，SPI控制器的初始化可能依赖BootROM代码完成，所以硬件上对SPI Flash连接的稳定性、上电时序要求很高。常见的坑包括：Flash芯片的WP（写保护）引脚没有正确上拉，导致固件写入失败；HOLD引脚悬空导致传输时数据被卡死；SPI时钟线走线过长，高速启动时信号反射严重。针对这些我一般会在硬件设计阶段就做三层检查：上电时序是否满足Flash芯片要求、SPI信号线阻抗是否匹配（串联33Ω电阻）、WP和HOLD引脚是否通过10kΩ电阻上拉到VCC。

另外，如果要在应用运行中通过SPI升级固件，必须注意Flash的擦写时间（典型的是几十毫秒到几百毫秒），这段时间内主控不能断电。否则Flash数据会写到一半丢数据，轻则升级失败，重则把Bootloader也冲掉，板子变砖。所以设计固件升级逻辑时，一定要在升级前写入一个“升级标志”，升级完成后清除；重启时检测到这个标志，就等Flash操作完成后才继续启动流程。

3. I2C与SPI的对比与选型决策

很多刚入行的朋友经常纠结“同一个外设芯片，既有I2C版本又有SPI版本，到底选哪个”。这个问题没有标准答案，但可以从几个维度来判断。

选择逻辑我的经验是：低速传感器、寄存器配置、需要省引脚、多设备共享总线，优先I2C；高速数据传输、大容量存储、全双工要求，优先SPI。如果两者都能满足，那就看团队熟悉度和现有代码库。比如你手头已经有一堆封装好的I2C传感器驱动，那新传感器也选I2C，开发效率高很多。

还有一个小知识点：PMBus和I2C的关系。PMBus实际上是在I2C物理层之上定义了一套完整的电源管理命令集，专门用于电源模块（DC-DC、VRM等）的配置和监控。它复用了I2C的物理电气特性和时序，但地址分配、命令格式、状态检测都是独立的规范。所以调试PMBus时，你用的工具和I2C一样，但协议解析要按照PMBus手册来。我之前调过一个数字电源模块，用I2C命令直接读寄存器没问题，但要用PMBus的标准命令（比如READ_VIN）才能拿到正确的电压值，因为寄存器映射和命令解析都是PMBus标准的。

4. 实战排障：I2C和SPI通信问题排查清单与技巧

4.1 排查工具的准备

没有工具的调试就是盲人摸象。I2C/SPI调试我建议至少准备：

• 逻辑分析仪（8通道以上，采样率越高越好，20MHz以上就够用），这是性价比最高的工具，能直观看到时序。
• 示波器（双通道以上，100MHz带宽以上），主要用于看模拟波形质量，比如上升沿是否过缓、振铃是否严重。
• 万用表，检查电压、电阻、短路/断路。

实际调试时，我习惯先用逻辑分析仪抓时序判断通信是否建立，再用示波器看信号质量。不要一上来就拿着示波器去量波形，因为是触发的问题，量半天可能什么都抓不到。

4.2 常见问题速查表

4.3 避坑经验：I2C上拉电阻小了不通信，SPI通信不生效

上拉电阻小了不通信，这个现象听起来反直觉，但我还真遇到过几次。原因在于：阻值太小会导致总线拉低时的灌电流过大，超过从机引脚的IOL额定值，从机引脚驱动能力不足，无法将SDA拉到可靠的低电平。等效看，就是低电平无法达到逻辑阈值。有个典型案例：一块板子上I2C上拉用了330Ω，3.3V系统，总线挂了一颗EEPROM和一颗RTC，EEPROM写操作总是失败。量波形发现SDA低电平是0.8V左右，超过芯片要求的VIL最大值（0.1×VDD≈0.33V）。换成2.2kΩ后低电平降到0.2V以下，问题解决。所以，I2C上拉不是越小越好，要在上升沿和低电平之间找平衡。

SPI通信不生效最常见的因素有两个：一是片选逻辑反了，有人把低有效CS写成了高有效；二是MISO/MOSI接反或者SCLK接错。画板子时如果SPI信号线走了排针或者连接器，特别容易把MOSI和MISO弄混。排查办法：万用表测通断，把主控和从机的引脚关系对一遍；示波器抓CS拉低期间的MISO波形，如果一直为低或一直为高，大概率是MISO接错了。

4.4 逻辑分析仪看时序的实操技巧

用逻辑分析仪抓I2C时，采样率至少设为通信速率10倍以上，100kHz的I2C建议用2MHz采样率；SPI的话20MHz以上比较稳妥。触发条件可以设置为起始条件（I2C）或片选下降沿（SPI），这样抓到的数据正好是通信开始的部分。

拿到波形后先看空闲电平：I2C空闲时SDA/SCL应该都是高；SPI空闲时SCLK电平由CPOL决定，CS必须是高。然后看时序：I2C里找START条件、地址字节、ACK位，确认从机是否应答；SPI里数一下SCLK边沿和数据变化时刻，确认MSB顺序是否正确。对照数据手册一步一步分析，很快就能定位是主机、从机还是接线的问题。

5. 从协议到系统：选择背后的工程思维

聊了这么多I2C和SPI的具体技术点，最后想说的是：协议选择本质上是一个系统工程问题，不单纯是一个“哪个更快”的选择题。

做产品方案设计时，我一般会先列一张需求清单：需要挂多少个外设？每个外设的数据量多大、刷新率多少？引脚资源是否充足？系统的工作电压域是统一的还是要做电平转换？这些约束条件清楚了，才能确定用I2C还是SPI，或者是I2C+SPI混合。

举个例子，我之前设计过一块环境监测主板，上面挂了一颗温湿度传感器、一颗气压传感器、一颗光照传感器、一颗PM2.5激光粉尘传感器、一颗256Mbit Flash、一块LCD屏。方案是：三个慢速传感器全部走I2C，共用一个总线，上拉电阻4.7kΩ；Flash和LCD走SPI，共用一个SCLK/MOSI/MISO，但CS各自独立，软件控制。这样引脚总数最低，传感器读取方便，高速数据不受干扰。这个方案跑了一整年，稳得很。

还有一点是标准化思维。I2C和SPI本身就是标准协议，芯片之间兼容性很好，但你如果在其上定义私有协议，最好遵循一些约定：比如命令头统一为固定字节，加校验（CRC8或CRC16），从机状态上报要有明确的忙/空闲标志。做工业级产品时，这些约定能极大减少后续联调的工作量。

6. 实操心得：调试I2C/SPI的几条铁律

最后再分享几条我这些年在项目里总结出来的调试经验，希望能帮你少走弯路。

第一，代码没问题时先查硬件。程序无法通信时，先用万用表量电压：I2C的SDA/SCL空闲电平是否正常、从机的VCC是否到位、GND是否共地。很多“通信诡异”的问题，最后都是供电或共地问题。特别是两块板子用长线连接时，不共地会导致通信完全瘫痪，这个坑我踩过三次。

第二，遇到时序问题先把速率降到最低。I2C降到10kHz，SPI降到100kHz，看能不能恢复正常。能恢复，说明是信号完整性或器件速度极限的问题；不能恢复，说明是配置错、接线错、或器件本身坏了。这个二分法排查从低速开始，能省很多时间。

第三，把I2C和SPI调试助手练得滚瓜烂熟。无论是逻辑分析仪还是示波器，都要熟练掌握触发、解码、滤波这些功能。很多人买了逻辑分析仪但只会点“Start”，遇到问题抓不到关键波形，等于白买。

第四，也是最重要的一条：从机手册永远是你的第一参考。每个器件的地址、指令集、时序要求都可能存在细微差别，网上不少文章是基于某个特定芯片写的，不一定都适用于你的芯片。花十分钟认真读一遍手册，比在论坛上逛两小时有效得多。

I2C和SPI这两个协议，说到底是嵌入式工程师的必修基本功。它们的原理简单，但要把它们用得稳、用得灵活，还是需要在真实项目里反复打磨。希望这篇总结能帮你在调试的路上少踩几个坑。

如果后面有机会，我再把UART、CAN、USB这些通信协议也整理出来，凑成一套完整的板级通信协议笔记，那时候再跟各位深入聊。