企业官网建设流程全解析

1. 这个系列为什么突然讲起了片间通信

先交代一下背景。这个“从沙子到车辙”系列的上一期，我们聊的是芯片内部怎么把数据从CPU核心里搬出来——总线、DMA、存储控制器那套东西。到了第4.2篇，视角要从“片内”跨到“片间”了，也就是芯片和芯片之间怎么说话。这个话题的入口，正好就是SPI和I2C这两个名字几乎每个嵌入式工程师都挂在嘴边、但未必真正吃透的协议。

很多人对SPI和I2C的印象停留在“会用就行”：传感器接上去，读个寄存器，出来数据能用就算了。但实际做项目你会发现，同样一颗传感器，挂在SPI总线上和挂在I2C总线上，行为完全不一样；同样是I2C，100K和400K的时序要求不一样，多主机和单主机的处理更是两码事。这篇我不打算只罗列协议特性，而是想把两条协议从“为什么会出现”讲到“实际调板时怎么避坑”，补齐那些手册里不会写、但调试时一定会撞上的细节。

适合谁看？正在学嵌入式的学生、刚接触驱动开发的初级工程师，以及那些天天写逻辑但没深究过信号时序的“应用层玩家”。不会涉及太难的高频信号理论，但读完你应该能说清楚：为什么SPI没有应答机制也能活得很好，为什么I2C用两根线就能挂几十个设备，以及你的下一个项目到底该选哪个。

2. 整体思路：从片内总线的尾巴说起

2.1 片内通信的“家规”为什么不能直接搬出去

上一期提到过，片内的数据传递靠的是总线矩阵、AHB/APB这类的并行总线。特点很鲜明：线多（几十根起）、速度快、时序极短，而且芯片内部的走线很短，信号同步性好。这套机制如果直接拿来做芯片间通信，会遇到一个现实的物理问题：引脚不够。

你去看看一颗MCU的封装，通用型号通常在48到144个引脚之间，去掉电源地、复位、晶振、调试口，能做通用IO的撑死也就一半。如果每接一个外部芯片都要拉30根并行线，那接一个外部ADC，你的GPIO就快没了，更别提还要同时挂Flash、屏幕、传感器。所以片间通信的第一诉求不是极致速度，而是“用尽量少的线，完成控制的活”。

这就解释了为什么SPI和I2C都是串行协议——一根数据线代替八根并行线，代价是速度下降，但对绝大多数外设（传感器、EEPROM、ADC、DAC、RTC）来说，几十K到几十M的速率已经够用。另一个关键差异是同步方式：片内总线有全局时钟，所有模块共享同一个节拍；片间则必须由主机主动产生时钟，从机跟着节拍干活，于是就有了“主从模式”这个最基本的结构。

2.2 两条路线的设计哲学差异

SPI和I2C是在同一个历史时期为了解决同样的问题（串行外设互连）而出现的，但设计思路完全相反，这在电气层面就直接分道扬镳。

SPI走的是“简单粗暴”路线：至少四根线，SCLK提供时钟，MOSI和MISO各管一个方向的数据，CS片选负责点名。它不管从机地址，不管总线冲突，各设备自主死，各自占各自的CS。实现简单，性能上限高，代价是引脚多、无错误反馈、一主多从时CS线数量跟着设备数涨。

I2C走的是“精打细算”路线：只有两根线，SDA送数据、SCL送时钟。所有设备并挂在同一条总线上，靠7位地址来区分。为了做到真正的“总线”形态，它发明了开漏加外部上拉的电气结构，还设计了ACK应答、仲裁、时钟拉伸这一整套协议层机制。线省了，但软件和硬件的复杂度上来了，速度还被上拉电阻和总线电容卡住。

这两条路线没有谁绝对优于谁，只有是否适合场景。我做方案选型的时候，基本就看三件事：通讯距离、从机数量和速度要求。器件间距离不超过10厘米、从机数量在4个以下、单次传输几百字节以内，两边都能干，差别不大；但一旦从机超过5个或者速率要求超过10Mbps，我基本会倒向SPI，因为I2C在高速下对PCB走线、上拉阻值的容错率太低了。

3. SPI核心细节：四根线背后没那么简单

3.1 主从拓扑和数据交换机制

先建立一个基本认知：SPI是同步、全双工、主从架构的串行通信协议。同步的意思是发送和接收由同一个时钟驱动，主机发SCLK，从机在时钟的边沿采样和移位数据。全双工是说MOSI和MISO独立，主机发数据的同时也能收数据，收发在同一个时钟周期内完成。

把SPI想象成两个移位寄存器首尾相连的环形结构：主机的移位寄存器移位到MOSI时，从机的移位寄存器同时通过MISO把数据送回主机。所以SPI的每一次传输，交换字节数一定是相等的——你想从从机读回1个字节，主机也必须要“发”出去1个字节，哪怕这个字节是废的0x00。初学者最容易犯的错就是只发不收、只收不发，导致读出来的数据永远错位，就是没理解这条“交换”逻辑。

CS（片选）线的意义是：低电平有效，选中谁谁就参与传输。之所以叫“片选”而不是“使能”，是因为它同时承担了总线占用声明和从机内部逻辑复位的职责。高强度项目里，CS的建立时间（CS拉低到第一个时钟边沿的时间）和保持时间（最后一个时钟边沿到CS拉高的时间）都有具体指标，搞错了从机可能直接收不到数据。

3.2 CPOL和CPHA：四个Mode的区分不是玄学

SPI的时序核心是时钟极性（CPOL）和时钟相位（CPHA）。CPOL决定空闲时SCLK是高还是低；CPHA决定数据在哪个边沿被采样。这两个比特组合出Mode 0到Mode 3，绝大多数的从机设备默认支持的是Mode 0（CPOL=0, CPHA=0），也就是空闲时钟为低、第一个边沿（上升沿）采样数据。

我建议你写驱动前，先翻数据手册看时序图，而不是直接问“这个设备用哪个Mode”。因为不同厂商画的时序图风格千差万别，有些把MOSI和MISO画得含混不清，有些甚至不标注CPOL/CPHA，只给出“Data shifted in on falling edge”之类的文字。对照“数据在哪个沿变化、在哪个沿采样”这两个信息去核对，比死记模式编号可靠得多。

调试时遇到数据错位、乱码，第一个要排查的往往是匹配主机和从机的Mode。我踩过一次很典型的坑：某国产温度传感器手册里推荐Mode 3，但它的示例代码按Mode 0初始化，结果读出来的温度每隔几个样本就会跳一次大数，看起来像硬件问题，实际上就是采沿采在了数据变化的瞬间，属性和时序竞争导致的偶发毛刺。

3.3 速率上限和时钟极性带来的隐患

SPI的速率上限不像I2C那样由协议规定，而是取决于从机能跑多快、PCB走线又多长。常规板级通信，10M到几十M都很正常，但速度上去之后会开始碰到信号完整性问题：走线长了会出现振铃和过冲，SCLK和数据之间的时序偏差会导致采样失败。这时候可以适当降速、缩短走线、加串阻，或者用示波器查看实际信号质量，再做调整。

另外有一个容易被忽略的点：SPI是全双工同步传输，主机和从机如果都工作在极速状态，从机的处理跟不上，会在MISO半路变数据，导致前半段有效、后半段无效。很多外设手册会给一个“maximum SCLK frequency”参数，那个是电气上限；软件上还要给从机留出“数据准备好”的时间，比如读ADC转换结果之前，先等转换完成标志。这类等待直接体现在业务层状态机里，而不是SPI控制器本身。

4. I2C核心细节：两根线省出来的麻烦

4.1 开漏结构、上拉电阻与“线与”逻辑

I2C最值得玩味的硬件设计是开漏输出加外部上拉。每个器件只是把SDA和SCL拉低，释放后靠上拉电阻把电平拉回高，这就是所谓的“线与”逻辑：只要有一个器件拉低，总线就是低电平。

这套结构带来的第一个直接好处是支持多主机仲裁和从机时钟拉伸。第二个隐性好处是电平转换容易——只要上拉电阻接到目标电压的电源，总线就会是那个电压电平，不同电压域的设备也能共存于一条总线上。比如3.3V主控和5V传感器之间，只在I2C信号线上用开漏结构加上拉到5V，就能安全通信，不需要额外的电平转换芯片。

上拉电阻的取值不是随便选的。电阻太小，总线低电平拉不低、静态功耗大，严重时直接拉坏器件；电阻太大，上升沿变缓，高速模式根本无法建立有效时序。工程经验上，100K模式配10K上拉，400K模式配2.2K到4.7K，前提是整个总线的等效电容不超过400pF。总线上的设备数量、走线长度、每个引脚的寄生电容都会加总，设备挂多了就得“电阻换小”或者“降速跑”。你可以用RC充电时间去估算：上升沿大约是0.7倍的上拉电阻乘以总线电容，保守做法是让上升沿时间不超过位周期的四分之一。

4.2 7位地址、写死地址和寻址冲突

I2C有两种地址长度：7位和10位。绝大多数普通传感器和EEPROM用的是7位地址，10位地址主要用于地址资源不够的场合。7位意味着理论上一条总线上最多可以挂128个设备，但实际因为A0/A1/A2引脚通常只引出3个引脚，一般同型号设备最多只能挂8个，再多就地址冲突了。

器件手册里常写的地址是一个8位的“写地址”或“读地址”，比如0xA0是写、0xA1是读，其实是7位地址0x50左移一位加读写位得到的。写驱动时千万要看清：你的代码里填的地址，到底是完整的8位地址还是7位地址。很多开发库按7位处理，你填0xA0进去，多出的方向位会被当成地址的一部分，分分钟总线NACK。我自己就在某存储芯片上因为这个问题折腾过半个晚上，后来换用示波器抓波形才明白是自己地址填翻车了。

挂多个相同型号器件时，A0/A1/A2的接法决定了可用地址范围。有的芯片支持地址内部分配，有的则焊死固定，采购和PCB设计时就要先把编址方案定下来，避免软件里改地址、硬件上又要飞线。

4.3 ACK/NACK、时钟拉伸和多主机仲裁

I2C的应答机制是强制性的：每个字节传输之后，接收方必须在第9个时钟位上拉低SDA来回应ACK，如果接收方主动拉高SDA（也就是NACK），就表示“我不想收了”或者“我收出错了”。主机读到NACK，基本可以判定从机地址错、器件不存在，或者从机忙到拒绝响应。

时钟拉伸是I2C里比较特殊但实际非常常见的机制：从机发现自己处理不过来，可以把SCL拉低，强制主机暂停。比如某些寄存器需要内部EEPROM刷新时间，刷新期间访问就会时钟拉伸，主机等它释放时钟再继续。如果主机侧用的是不带时钟拉伸感知的软件模拟I2C，很容易在高速下超时，所以写软件I2C时一定要把等待SCL释放的逻辑写上。

多主机仲裁解决的是两个主机同时在总线上发言的问题。逻辑是“低电平优先”：谁先把SDA拉低，谁就赢得总线。另一台主机在发送数据时会不断监测SDA，发现总线电平和自己预期不符，就退出竞争。这套机制在很多实时系统里有实际意义，比如一个MCU按需做主、一个平时只做从，需要切换时直接做仲裁，不扯皮。但要注意的是，多主机I2C的软件状态机复杂度比单主机高得多，如果一个项目没有必要，别给自己找活干，老老实实单主机。

5. 实操对比：SPI和I2C的选型与现场调参

5.1 一张表看懂关键差异

5.2 什么时候选SPI：高吞吐是硬指标

SPI适合对吞吐有明确要求的场景。最典型的是驱动一个带帧缓冲的彩色LCD屏或者一颗高速ADC；一次要传的数据是几十到几百字节，而且每个字节都是有效数据，I2C每发送一帧还要先传地址、寄存器地址、再传数据，有效载荷比例明显偏低。

另一个选SPI的理由是你的从机数量少，但要求“独占通道”。比如板载一颗带中断输出的传感器，又有一颗Nor Flash，如果都挂I2C，传感器频繁中断时可能要和Flash的数据传输抢总线时序，尤其Flash搞页编程的时候，动不动时钟拉伸几十毫秒，传感器侧的数据刷新就会卡顿。改成SPI之后，每颗器件各用各的CS，DMA传输也完全独立，互不干扰，实时性更好。

SPI也适合做主控和无“智能”外设之间的桥梁，比如和FPGA做板级数据交换。FPGA侧往往把SPI接口做成简单的FIFO读写逻辑，数据吞吐量可以做得很大，甚至有人用SPI跑几十Mbps的连续流，I2C在这种场景下基本没有竞争力。

5.3 什么时候选I2C：省引脚才是王道

I2C的杀手锏是省引脚和总线复用。我做过一个项目，主控除了常规的MCU外设，还要挂六个I2C器件：三个温湿度传感器、两个EEPROM、一个RTC。如果全用SPI，CS线就要六根，加上时钟和数据线，引脚直接爆炸；而I2C只需要两根线，最多再加两个中断响应引脚。

I2C的“线少”还带来一个工程红利：PCB布线好走，双面敷铜的板子也能在不破坏电源平面完整性的前提下把两条信号线走得干净。另外I2C天然支持总线枚举，调试时可以写一段扫描代码，把总线上所有响应地址列出来，核对硬件接线是否和你预期一致，比SPI一根根CS去试快得多。

如果你做的是多板互联系统，I2C的地址机制同样有用。比如子板上放一个微控制器做I2C从机，主控通过I2C去读写它的寄存器，两条线就把“控制通道”打通了。这种情况下，I2C的ACK机制其实帮了大忙，主机能直接确认究竟有没有子板在线上，SPI则做不到——你只能看CS拉低后从机有没有响应，而大部分SPI从机不会主动报错。

5.4 速度路线的取舍：一个真实例子

举个我调过的具体例子：某数据采集板，主控和一块高速ADC之间，ADC输出8位并行数据，我选了SPI读（如果ADC支持串行模式的话）。ADC本身是1M采样率，每样本12位，SPI时钟我配到32MHz，一次读一个样本只要不到0.5微秒，DMA搬运完全不用CPU介入，主控可以一边采集一边跑浮点算法。

同一个板子上的RTC和EEPROM，我则全部走I2C。因为它们一天最多被读写几次，用SPI纯属浪费引脚；而且I2C的ACK和重传机制在低频小数据包场景下非常可靠，不会因为传输速率过高产生边缘毛刺。

这种“一板双协议”其实最能说明问题：SPI和I2C不是替代关系，而是互补关系。选型的本质是算清楚你的数据速率需求、设备数量、引脚预算、信号完整性风险，四者权衡之后再落方案。

6. 实操体验：波形怎么看、代码怎么写

6.1 用一个最小例程打通SPI读写

我以最常见的“主机读一颗传感器寄存器”为例讲一下SPI主机侧的操作流程。这里先假设传感器挂在SPI总线上，CS接普通GPIO，控制器用原生SPI外设。

第一步，初始化SPI外设：时钟分频要算，目标速率用“系统时钟 / 分频系数”得到，不能直接写目标频率；Mode根据传感器手册选；数据大小一般是8位，少数12位或16位的ADC要对应改。第二步，初始化和CS相关的GPIO，默认输出高电平，不选中设备。第三步是每个读写事务的标准动作：拉低CS，发命令字节，发寄存器地址字节，然后连续发N个0x00字节，同时在MISO上收数据，收完拉高CS。

提示：如果从机要求命令和地址之间、地址和数据之间需要延时，一定要在状态机里显式写us级延时，别指望SPI控制器自动处理。这是新手容易漏的。

关键点是SPI的DMA传输可以整段安排：用DMA把发送数组和接收数组配对好，一个传输完成后产生中断，CPU只在最后做一次数据解析。吞吐率差距非常大，如果用中断逐字收发，每字节都会被中断代码拖慢，高时钟就白配了。

6.2 软件模拟I2C和硬件I2C的坑

I2C这个协议在MCU上实现有两种方式：硬件外设或软件模拟（GPIO翻转+延时）。硬件I2C占用CPU少，但每个厂家的控制器寄存器风格不同，遇到无应答自动重试、中断标志位不清、FIFO溢出这类问题，排查起来非常费劲，且各平台差异大。软件I2C的稳定性和可调试性反而更好，尤其遇到地址有歧义、总线上有多个不同电压的设备，逐一翻转波形看数据，心里非常有底。

软件I2C要正确实现，核心是状态机的严谨性。标准的写时序是：起始条件（SCL高时SDA拉低）→发送7位地址+写位→等待ACK→发送寄存器地址→等待ACK→发送数据（每个字节后等待ACK）→停止条件（SCL高时SDA拉高）。读时序稍微复杂一点，读到最后一个字节后主机要发NACK，再发停止条件，告诉从机别再发了。

很多人软件模拟I2C翻车，问题大多出在“SCL和SDA操作顺序”上。每次数据变化必须发生在SCL低电平期间，SCL从低变高之后总线电平就必须稳定下来。如果操作顺序反了，会在SCL上升沿前后出现数据跳变，直接把I2C时序破坏。写代码时，每一位的处理建议顺序是：SDA先设好输出值，再延迟；SCL拉高，再延迟；SCL拉低，再延迟；这样保证采样窗口内数据稳定。

6.3 示波器看波形的几个判断点

调通信时，示波器是最好的朋友。建议至少看这几个点：

先看波形整体——SCL是否连续，SDA电平是否在SCL低电平期间才跳变。随便卡一处“在SCL高时SDA变了”，就说明代码顺序或者时钟相位有严重问题。再看地址阶段的ACK位：第9个时钟后SDA有没有被拉低。如果没有，要么从机地址错，要么从机压根不在线上。然后看停止条件：主机结束传输时有没有正确地“在SCL高时SDA拉高”，很多从机依赖于这个条件提交内部操作，如果停止条件有问题，寄存器写入会莫名其妙地不生效。

用逻辑分析仪比示波器更高效，可以直接解码出I2C的地址和操作序列，哪一步错了一目了然。调SPI时同理，逻辑分析仪能看到CS波形和时钟脉冲个数，快速判断是不是多传或少传了一个字节。

6.4 讲讲DMA和中断的分工

无论是SPI还是I2C，一次传大量数据时都建议用DMA，这个在上一期聊过总线矩阵时有提过。SPI的DMA通常最简单，外面两个缓冲区一个配置发送、一个配置接收就可以；I2C的DMA则要注意，很多硬件I2C控制器在每字节ACK/NACK处理上和DMA之间有配合关系，用DMA时直接关掉字节中断，只在传输完成时开一个完成中断，能省掉很多重复的ISR调度开销。

中断回调里能做的事要尽量少，只做标志位设置、数据搬运，把解析放主循环。如果中断里做浮点运算或调用延迟函数，系统整体响应会变得不可预期，尤其是多设备共享总线时，慢中断会显著拖平均传输间隔。

7. 常见问题与排查技巧实录

7.1 一抖一个坑：我实测中遇到的问题速查表

7.2 总线死锁的“9脉冲恢复法”和软件处理

I2C总线被从机拉死这个问题，处理过生产环境的人应该都熟。SPI这种主从强控制的协议天然不会遇到，因为CS直接重置了从机状态机的所有状态；I2C则不同，只要总线上出现残次时序，有些从机就会把SDA拉死，表现为总线SCL正常，但SDA一直是低、且你发任何东西都不ACK。

常规对策是标准的总线恢复序列：把SCL当作普通GPIO，主动翻转9个时钟脉冲，同时监测SDA是否在某个脉冲后释放。这个操作能够把残次状态机推回到空闲状态。但要注意，恢复之前必须先确认没有其它设备正在占用总线，否则会把别人的正常事务打断。生产代码里建议把总线恢复逻辑做成独立任务，检测到锁死时自动触发，避免设备死等。

软件层的处理同样重要：每次I2C事务之前和之后，都要保证总线上没有“半途而废”的传输，尤其不要在中断里突发读写。中断里做I2C，一旦被更高优先级的中断打断，SCL和SDA操作序列就会错位，代码写完发现只有低速模式能跑，高速模式随机挂，基本就是这个原因。

7.3 换了个从机型号，同样的代码却不好使

不同厂商的从机在同一个协议框架下的行为差异很大，这个坑比想象中常见。换器件后，首先要重新核对地址位宽、寄存器映射、命令格式和从机支持的时钟频率，特别是I2C的不少新器件开始支持“高速模式”或者“超快速模式”，你要确认主机能力是否匹配；而SPI则是Mode和位宽的差异。

其次是命令的“组合形式”不同。有的EEPROM写一个字节需要“写指令+地址+数据”三条时序完成，另一家的逻辑可能是“地址+数据”就行。如果你的驱动是从之前某个项目复制过来的，建议别省看数据手册那几分钟。我就遇到过换上某国产存储芯片后，读ID一直失败，折腾了一个下午，最后发现这个芯片要求CS拉低后先发一个特殊的“读取ID使能”命令，而原来那家根本不需要。

7.4 电平不匹配：看似能通实则随时可能炸

现在不少设备支持宽电源电压，但还远不是全部。I2C靠开漏上拉的电气结构能够实现不同电压域共存，但仍需确认引脚是否“真正支持开漏”。有些MCU的IO在做开漏输出时，如果没有设置成“开漏模式”，实际输出的是推挽结构，总线拉低速度极快，但释放时只能由外部上拉慢慢抬，逻辑上能用、信号上却丑，长线时偶发误码。

SPI的情况更苛刻：协议本身没有任何电平协商机制，主机3.3V直接接从机5V，从机的内部钳位二极管可能被灌电流反复冲击，短期不出问题，时间久了器件性能退化或直接击穿。跨电压做SPI必须上电平转换芯片，或者选带电平转换功能的IO扩展器，千万不能靠“电阻分压”偷懒，因为MOSI、MISO、SCLK、CS四个信号方向各不相同，单靠分压很容易把后沿搞缓。

8. 最后说点个人习惯和小技巧

我调板多年，有个习惯：每一个用到SPI或I2C模块的项目，原理图阶段就把CS或I2C地址的分配规划写在设计文档里，排查问题时直接对着文档核对，而不是临时翻数据手册。别小看这一步，多人协作时它避免了一堆无谓的“地址冲突”“CS错位”争执。

另一个小技巧是调试时先跑最低速。SPI先跑1MHz、I2C先跑100K，验证逻辑无误之后再把时钟拉上去，这样能有效隔离“逻辑错误”和“信号质量错误”两件事。如果你一上来就高速，出错了整个问题空间就大了，很难分清到底代码错、时序错还是布线错。

还有一个非常实用的习惯：把所有I2C设备的地址扫描做成一个开机自检函数，每次上电自动跑一遍，把扫描到的设备地址、响应时间打印出来。这既能在产线测试时快速发现焊错、贴错的板子，也能在后期维护时判断是不是有器件老化到不响应。SPI侧则可以在自检里做“回环测试”——把MISO和MOSI短接，发一串测试数据，读回来比对，有出入就说明链路有问题。

这两个协议的本质区别我总结成一句话：SPI追求速度和简单，适合一对一、高速、大批量的数据搬运；I2C追求布线和寻址效率，适合一对多、低速、控制型的小包交互。把这句话刻在脑子里，做选型判断时就不会纠结太久了。