企业官网建设流程全解析

1. 从两根线说起：I2C协议的整体设计思路

搞嵌入式这些年，天天跟各种通信协议打交道。串口、SPI、CAN、USB各有各的用处，但如果让我选一个日常调试中出场率最高、用来读取传感器和配置芯片最顺手的，那一定是I2C。I2C全称Inter-Integrated Circuit，中文常叫集成电路间总线，由飞利浦公司在几十年前提出，初衷特别朴素：让板子上的芯片之间用最少的线完成通信。

I2C最吸引人的地方就是信号线少。整套总线只需要两根线，一根串行时钟线SCL，一根串行数据线SDA，所有挂在总线上的设备都并联到这两根线上。对比一下SPI至少需要三根线还经常要再加片选，UART则是点对点通信不能挂多个设备，I2C这种“两根线挂一堆设备”的拓扑，在节省IO资源和简化PCB布局上的优势是实实在在的。实际项目里，一个MCU通过一组I2C总线挂上温湿度传感器、气压计、OLED屏幕、EEPROM存储芯片，甚至再串一个IO扩展芯片，这种场景太常见了。

和UART、SPI相比，I2C还有一个核心特点就是它是有地址的总线。挂在同一条总线上的每个设备都有唯一的器件地址，主机通过地址来区分当前要和谁通信。也正是这个机制，让I2C天然支持一主多从甚至多主通信。虽然绝大多数实际项目都是单主机模式，但理解多主机和仲裁机制对彻底搞懂协议非常有帮助。

这篇文章适合谁？刚接触I2C、被时序图和ACK应答搞晕的入门开发者，想在STM32、ESP32或者Linux环境下把I2C用得明明白白的嵌入式工程师，还有写Verilog想在FPGA里自己实现I2C控制器的同学。我会从头到尾把协议拆开讲清楚，再穿插一些实际调试中踩过的坑和心得，争取让大家看完之后不仅能看懂别人的代码，还能自己动手排查问题。

2. 物理层与时序基础：理解I2C为什么是开漏结构

2.1 两根线与开漏输出，I2C电气层面的关键设计

I2C的两根线SCL和SDA，在电气上都是开漏输出结构。所谓开漏，就是芯片内部并不主动输出高电平，而是只能把引脚拉低到地，或者释放引脚。释放的时候，引脚的电平由外部上拉电阻决定。

为什么要设计成这样？这就要说到I2C的一个核心机制：时钟同步和总线仲裁。如果引脚像普通GPIO那样推挽输出，一个设备输出高电平、另一个设备输出低电平，两个设备同时操作时会直接短路，轻则逻辑错误，重则烧毁芯片。而开漏结构天然规避了这个问题，因为“输出高”是靠外部电阻实现的，任何设备都只是“拉低”或者“不拉低”。多个设备同时拉低时，只有线与关系，谁也不会受损。

上拉电阻的取值是有讲究的，不能随便选。电阻太小，灌电流太大，不仅费电，还可能超出芯片的IO驱动能力；电阻太大，总线电容的充电时间变长，上升沿变缓，高速通信时波形就不达标了。实际操作中，4.7kΩ是经典的通用值，适用于100kHz标准模式和大多数400kHz快速模式场景。如果总线上的设备比较多，总线上等效电容变大，可以适当减小到2.2kΩ甚至1kΩ；如果追求低功耗，设备又少，10kΩ也能用，但要注意高速时上升沿是否满足要求。

上拉电阻的计算逻辑大致是这样：最小阻值受IO灌电流限制，最大阻值受总线上升时间要求限制。快速模式400kHz要求上升时间不超过300ns，总线上挂的设备多、走线长，等效负载电容可能到100pF甚至更多，如果上拉电阻太大，RC充电时间就会超过规格要求，波形上就能看到明显的圆角。所以调试这类问题时，用示波器看SDA和SCL的上升沿是非常直观的手段。

2.2 起始、停止与数据有效性，时序里的几个关键节点

I2C通信的时序起点是START条件，也就是在SCL保持高电平期间，SDA发生一个从高到低的跳变。这个下降沿告诉总线上所有设备：主机要开始通信了，大家准备好接收地址。通信结束时主机发送STOP条件，同样是SCL保持高电平期间，SDA发生一个从低到高的跳变。这两个特殊状态之所以要用“SCL高电平时SDA跳变”来表示，是为了和普通数据传输区分开——正常传输数据时，SDA的电平变化必须发生在SCL为低电平的时候。

数据有效性规则也很关键：在SCL的高电平期间，SDA上的数据必须保持稳定；只有在SCL低电平期间，SDA才能切换状态。简单说，从机的采样点就是SCL的上升沿，主机要保证在SCL拉高之前把数据放到位。这意味着所有数据位的变化都集中在SCL低电平窗口内。初学者写软件模拟I2C时最容易犯的错，就是在SCL高电平期间去改SDA的电平，结果从机采到的全是乱码。

一个字节的传输是8个数据位，MSB先行，也就是高位在前。第9个时钟周期是ACK应答位。主机释放SDA，从机如果正常收到了数据，会把SDA拉低，表示“我收到了，继续发”。如果从机没有拉低，SDA保持高电平，就是NACK，通常意味着从机忙、地址不匹配或者数据有误。

整套时序用逻辑分析仪抓出来，就是一组方波。地址字节、数据字节、ACK位依次排列，看多了之后基本一眼就能定位问题在哪一拍上。

2.3 7位地址与读写位，一张地址表看懂寻址机制

I2C寻址最常见的模式是7位地址。所谓7位地址，指的是地址字节的高7位是设备地址，最低位是读写标志位。读标志为1，写标志为0。比如一个设备的7位地址是0x50，那么主机发送的地址字节就是0xA1表示读，0xA0表示写。

很多传感器和存储芯片的7位地址并不完全固定，而是由芯片的引脚电平决定。以AT24C02系列EEPROM为例，它的地址高4位固定为1010，低3位由A2、A1、A0三个引脚的接法决定，所以在I2C扫描时经常会看到0x50、0x51这样连续出现的地址。实际产品里可以通过改硬件跳线来避免同一条总线上挂两个相同地址设备的问题。

I2C也定义了10位寻址模式，用来扩展地址空间。10位寻址时，第一个字节的前5位是固定的11110，后面两位是10位地址的最高两位，最低位仍是读写标志。SPI的设备选择靠硬件片选引脚，每个设备独占一根CS，所以设备多了片选引脚不够用；而I2C的寻址走的是软件协议，硬件上所有设备共享两根线，加设备几乎不占用额外IO，这也是I2C在传感器小型化设备里用得多的原因之一。

3. 完整通信过程拆解：从寄存器读写到OLED刷屏

3.1 向从机写入数据，从寄存器地址到数据字节的完整流程

绝大多数I2C从设备，比如传感器、ADC、EEPROM，内部都有寄存器地址的概念。主机向设备写数据，本质上就是往某个寄存器地址里写值。一次典型的写操作包含如下步骤：主机发送START条件，发送设备地址字节（含写标志），等待从机ACK，发送寄存器地址字节，等待ACK，发送要写入的数据字节，等待ACK，最后发送STOP条件。如果需要连续写多个字节，就在第一个数据字节之后继续发送后续字节，每发一个字节等待一次ACK，直到全部完成再发STOP。

以往AT24C02的0x00地址写一个字节0x5A为例，完整的数据帧是：S，0xA0，ACK，0x00，ACK，0x5A，ACK，P。看起来很简单，但有几个细节值得展开。第一，从机在接收到地址后，如果地址不匹配，它不会拉低ACK位，主机在检测到NACK后应该立刻发STOP终止通信，而不是继续往下传数据。第二，EEPROM这类存储器件写入后需要时间完成内部编程，一般要等5ms左右，如果连续写太快，从机会在写周期结束后才回应ACK，这也是调试时经常遇到“写半天没反应”的原因之一。

对触摸芯片、电源管理芯片、传感器这类寄存器较多的设备，经常需要连续写入多个寄存器来初始化配置。比如我调过的一款气压传感器，上电默认状态不满足需求，需要连续写四五组寄存器配置，每次写入一个寄存器地址加一个数据字节，中间还要稍微加一点延时确保写入稳定。把初始化配置整理成数组，用循环逐个写入，是这类场景最常见的处理方式。

3.2 从设备读取数据，重复起始条件这个关键设计

读操作比写操作复杂一些。因为从机并不知道主机要读哪个寄存器，所以读取之前必须先把寄存器地址告诉从机。标准流程是：主机发送START，发送设备地址（写标志），发送寄存器地址，然后主机会再次发送一个START条件，这个再次发送的START在协议里叫做重复起始条件（Repeated START），英文缩写Sr。接着主机发送设备地址（读标志），此时从机开始输出数据，每发送一个字节后主机需要回复ACK表示“继续发”，直到主机回复NACK并发送STOP，读操作结束。

问一个问题：为什么不能用STOP加START来代替重复起始条件？因为I2C总线是支持多主机的，如果主机在中间发送了STOP，就意味着释放了总线，其他主机可能趁机抢占总线发起自己的通信。使用重复起始条件，主机在整个读操作过程中始终握有总线控制权，不会被其他主机打断。这个设计在多主机系统中非常关键。

以读取AT24C02的0x00地址为例，完整数据帧是：S，0xA0，ACK，0x00，ACK，Sr，0xA1，ACK，数据字节，NACK，P。注意最后一个字节主机要回NACK，目的是告诉从机“这是最后一个字节，我读完了”，如果这里回了ACK，从机会继续输出下一个字节，主机的读时序就乱套了。这是写驱动时特别容易犯的一个逻辑错误。

3.3 把读写串起来，看I2C OLED、传感器和BQ76952的实际应用

理解了单个寄存器的读写，很多设备的驱动代码就只是在这两个基本操作上增加封装。比如SSD1306驱动的OLED屏，它内部有一个显存区，主机要做的就是把整帧图像数据按页和列地址顺序写入。屏幕的分辨率通常是128×64，显存总计1024字节，刷屏就是一次长达1024字节的连续写操作，中间不需要任何额外的控制逻辑，前提是主机和从机的时钟速率、从机内部缓冲区都跟得上。

传感器类设备读数据的典型场景是：先写配置寄存器，再等待数据准备好，然后按上面讲的“写寄存器地址→重复起始→读N个字节”的流程把数据读回来。很多传感器芯片还支持自动地址自增，也就是说，如果主机连续读多个字节，从机会自动把寄存器地址递增，这样一次就可以把加速度计的X、Y、Z三个轴的六个字节全部读出来，效率非常高。

再举一个实际项目中的例子，板级电源管理芯片BQ76952在调试时经常遇到“I2C没反应”的问题，大概率不是协议本身的问题，而是芯片处于休眠模式或者寄存器地址需要先解锁。还有IP5306这类充放电管理芯片，I2C更多用于读取电量状态和设置参数，它的寄存器比较少但地址映射有讲究，建议拿到芯片先翻数据手册重点看“Register Map”部分，不要只看引脚定义。总的来说，无论设备多复杂，只要掌握“先写寄存器地址、再读写数据”的总线操作模型，就能应对绝大多数场景。

4. 进阶机制与硬件设计：时钟同步与总线扩展

4.1 时钟同步与仲裁，多主机共存的核心机制

I2C支持多主机，多个主机可以挂在同一条总线上，这就要解决两个问题：争用总线时谁来用？传输的位流是否会被破坏？

时钟同步机制是这样的：I2C的SCL是线与结构，所有设备都在拉低SCL，总线上的实际SCL电平是所有设备钟控信号的逻辑与。如果设备A的时钟周期短，设备B的时钟周期长，两者在各自低电平阶段都会把SCL拉低，总线SCL的低电平时间就会一直持续到所有设备都释放为止。最终效果是，速度较慢的设备会把整体的高速设备时钟拖慢，总线自动同步到最慢的那个设备。这个设计非常优雅，不需要额外的握手信号，纯靠电气特性完成同步。

总线仲裁则发生在SDA上。两个主机同时发数据时，如果一位一位地发送，总线上是线与关系。设备在发送数据的同时会监视SDA的电平，如果发现自己想发高电平，但总线上却是低电平，说明有其他主机在发送，它就会立即退出竞争，停止传输。因为I2C是高电平靠上拉、低电平靠主动拉低，所以低电平优先，多主机仲裁时数据为0的那一方会获胜。这套机制保证了总线上的数据不会被破坏，输掉仲裁的主机可以等待下一次总线空闲再重试。

实际工程项目里多主机用的并不多，大部分还是单主机带一堆从机的架构。但理解仲裁原理对排查“总线卡死”问题特别有帮助。有一次调试就是两台设备同时都在操作I2C总线，结果时不时出现数据错乱，查了半天才发现是其中一个设备的中断服务函数里也调用了I2C读写函数，主循环和中断服务函数抢总线，导致数据被破坏。后来加了互斥锁，问题彻底消失。

4.2 速率模式与上拉电容，高速设计时怎么选参数

I2C协议规定的传输速率主要有几种：标准模式100kbit/s，快速模式400kbit/s，快速模式加强版1Mbit/s，还有高速模式3.4Mbit/s。大多数传感器和EEPROM支持到400kHz，屏幕刷新或者大数据量传输时可以开到1MHz。

速率越高，对上升沿时间的要求越严格，对总线上拉电阻和等效电容的要求也就越高。实测经验是，400kHz下用4.7kΩ上拉基本没问题；开到1MHz时，如果总线上挂了四五个设备，线长超过20cm，再用4.7kΩ就会看到SDA上升沿明显变缓，甚至从机出现误采样的情况。这时候把上拉电阻换到2.2kΩ或者1kΩ，问题通常迎刃而解。反过来，如果板子是电池供电、设备少、通信不频繁，用10kΩ上拉降低静态功耗完全没问题，只是别把速率提得太高。

总线的等效电容主要来自每个芯片引脚的寄生电容和PCB走线的分布电容。一个引脚的寄生电容通常在几pF到十几pF之间，十个设备加起来就是上百pF。想要计算上拉电阻是否满足上升沿要求，可以用RC充电模型粗略估算：上升时间约等于0.85乘以RC。如果负载电容是150pF，上拉电阻是4.7kΩ，算出来上升时间大约是0.6微秒，对400kHz的300ns上升沿要求来讲就已经超标了。这也是为什么高速场景必须用小电阻、短走线、少设备。

4.3 总线扩展与电平转换，多设备系统里的实用方案

同一条I2C总线上设备多了，会遇到几个问题。一是地址冲突，两个芯片的7位地址相同，在不改硬件跳线的情况下只能换路。二是总线电容过大，极限情况下信号质量严重下降。三是不同器件工作电压不同，3.3V的MCU和5V的传感器不能直接连接。

地址冲突的常用办法是使用I2C多路复用器，比如PCA9548A这类的芯片。它本身在总线上占用一个地址，通过配置它的寄存器，可以选通它的八路下游总线中的任意一路或者多路。这样原本地址冲突的两个设备分别挂在不同下游通道上，主机先选通道0操作完，再选通道1操作，回避了地址冲突问题。这个方案在服务器主板上管理大量EEPROM时非常通用。

电平转换的常见实现是使用双向电平转换芯片，比如TXS0108E或PCA9306。这类芯片内部有自动检测方向的电路，不需要额外的方向控制引脚。设计的时候注意：上拉电阻应该分别连接到各侧的电源电压，转换芯片两侧的电源必须都接好，否则总线会处于不确定状态。还有一个坑是转换芯片的通道数如果多于实际使用的信号线，闲置通道最好也接上上拉，不然悬空的通道可能引入干扰。

5. 代码实现与调试实录：从芯片寄存器到Linux驱动

5.1 软件模拟I2C，时序写不对一切都是白搭

在没有硬件I2C外设的MCU上，或者在某些硬件控制器行为不好控制的场景下，软件模拟I2C是必备技能。用GPIO模拟I2C并不难，难的是把时序写得标准。

以ST公司经典的软件模拟代码为例，核心操作分这么几步。起始条件：先把SDA拉高、SCL拉高，然后SDA拉低，最后SCL拉低，完成一个完整的起始时序。发送一个字节：循环8次，每次先把数据位放在SDA上，然后SCL拉高，延时一会儿，SCL拉低，再进行下一位。接收一个字节类似，只是把SDA设为输入，在SCL高电平期间读取引脚电平。ACK检测则是释放SDA，等SCL高电平期间去读SDA电平，如果是低说明收到ACK。

几个细节直接影响通信稳定性。第一，GPIO方向切换要及时，发送模式下SDA要配置为推挽输出或开漏输出，接收模式下要释放SDA让从机可以拉低，切换不及时会导致最后一个位或ACK采样异常。第二，若MCU的GPIO不支持开漏模式，可以用“输出高”来模拟释放，但前提是IO电平要和总线电平兼容。第三，延时要根据主频和总线上设备的速率要求来评估，别把延时写得太短，特别是偶尔在总线上串联了长线或者下拉配置电容时，波形余量不足就会随机出错。

5.2 硬件I2C控制器与DMA，什么时候用哪种方案

现在绝大多数MCU都自带硬件I2C外设，STM32、ESP32、GD32都有完整的I2C控制器。硬件控制器的好处是时序由硬件产生，CPU只需要操作寄存器或者通过库函数API发起传输，占用CPU时间少。坏处是不同厂商的I2C控制器行为差异很大，有时候时序细节和软件模拟不完全一致，调起来不一定比软件模拟省心。

STM32的硬件I2C曾经被很多人吐槽过，主要是早期标准库的I2C接口用起来容易卡死在事件标志位上，遇到错误状态处理起来比较绕。但换成HAL库或者LL库之后，情况好了很多。使用HAL库的I2C发送函数时，要注意它在内部会等待总线事件，如果总线上从机没有应答，函数会一直阻塞直到超时。所以一定要设置合适的超时参数，避免程序死等在I2C上。

提到I2C和DMA结合，最大的作用是刷屏或者传输大块数据时可以解放CPU。比如用I2C写OLED屏的整帧显存，数据量超过1KB，用阻塞方式发送会占用不少CPU周期。用DMA方式可以在启动传输后继续做其他事情。但DMA方式也有代价：每次发起DMA传输前要把待发送数据放到连续内存缓冲区里，而且必须在DMA传输完成前保持缓冲区内容不被修改，否则发送出去的数据会错乱。项目里如果不需要极致的CPU利用率，用阻塞方式其实更省心，反正一帧数据也才几毫秒的事情。

5.3 Linux下的I2C驱动结构，从设备树到用户空间

Linux系统下使用I2C，首先要把硬件平台上的I2C控制器在设备树中描述清楚。以常见的FPGA+ARM平台为例，设备树里会定义I2C控制器的基地址、中断号、时钟频率，还要描述挂在I2C总线上的从设备节点，包括从设备的地址和使用的驱动兼容字符串。

Linux内核的I2C驱动框架分三层：I2C核心层、I2C总线驱动层（适配器驱动）、I2C设备驱动层。适配器驱动负责和具体硬件控制器打交道，提供收发函数接口；设备驱动则面向具体的传感器或芯片，通过i2c_transfer之类的接口发起传输。编写一个I2C设备驱动时，最核心的是在probe函数里拿到struct i2c_client指针，然后用i2c_smbus_read_byte_data、i2c_smbus_write_byte_data这类API来读写设备寄存器。

有时候不想写内核驱动，只想在用户态快速验证芯片功能，Linux也提供了i2c-dev接口。打开/dev/i2c-N设备节点，用ioctl设置从设备地址，然后用read、write或者i2c_transfer结构体执行非标准传输。调试新传感器时我个人非常喜欢用这个方式，写一个简单的C程序或者用i2c-tools工具包里的i2cdetect、i2cget、i2cset命令，几分钟就能确认设备是否存在、寄存器能不能读写，省去反复编译内核模块的时间。

5.4 用Verilog实现I2C控制器时最需要盯住的状态机

在FPGA里用Verilog自己写I2C控制器是很多人学习状态机的经典项目。核心要盯住的就是状态机的跳转条件、时钟分频后的SCL产生逻辑、三态门的控制。

SCL的产生最好用计数器分频，在一个完整的SCL周期内，把高电平和低电平的时间控制相等，并且保证延时足够。SDA的数据变化必须在SCL低电平时进行，所以可以设计一个二位状态机：IDLE状态下SDA和SCL都拉高，检测到起始条件后进入发送状态。发送状态下每个SCL周期处理一个数据位，计数到8后转入ACK采样状态。读操作还要额外增加重复起始状态和接收字节状态，时序关系比写操作复杂不少。

很多人写Verilog版I2C容易出问题的地方在于三态门控制。SDA引脚必须是inout类型，当输出数据时拉低SDA，当输出1时要释放SDA设置为高阻态而不是直接拉高。这个“释放”和“拉高”的区别一开始特别容易搞混，导致总线上电平不对。另外，ACK采样时SDA也要设为输入，由从机控制电平。如果在FPGA里把SDA直接设成强驱动输出，轻则通信失败，重则可能影响同一总线上其他设备。

6. 调试工具与常见问题排查实录

6.1 逻辑分析仪看I2C波形，这比对着代码猜效率高太多

调试I2C最忌讳的就是对着代码一遍遍看逻辑，看到最后也看不出所以然。建议必备一个逻辑分析仪，几十块钱的就能用，采样率20MHz以上即可。把SCL和SDA两根线接到逻辑分析仪的通道上，抓一次通信过程，用配套软件解析出地址、读写标志、ACK状态、数据内容，问题基本就浮出水面了。

看波形的最基本判断方法很简单：第一看有没有START和STOP条件，第二看地址字节是否正确，第三看ACK位到底是高还是低，第四看每个数据位在SCL高电平时SDA是否稳定。如果SCL一直在跳，SDA也正常变化，但地址位后面出现了NACK，说明地址不对或者总线上根本没有这个设备。如果整个SCL都停止不动，大概率是从机在拉低SCL做时钟扩展，主机在等待。

在实际调试经历里，有一个典型的排查案例：一块板子上的温湿度传感器有时候能读到数据，有时候读不到，看起来像是随机故障。用逻辑分析仪抓了几次波形后发现，出问题的时候SDA总线上多了一个意外的低电平脉冲。顺着查下去才发现是另一个复用引脚被错误初始化成了输出模式，在不该操作的时候把SDA拉低了。没有分析仪的话，这种偶发问题可能要排查好几天。

6.2 没反应、卡死、数据错乱，I2C常见故障速查

I2C通信故障虽然表现多样，但归结起来就那么几类。下面是长期调试中整理出来的速查表，基本覆盖了常见问题。

如果总线卡死了，有一个复位法可以掌握：把SCL手动翻转9个周期，也就是发出9个时钟脉冲，然后发一个STOP条件。因为I2C协议中，从机只有在收到9个时钟后才有可能释放被锁住的状态。如果这个办法仍然无法恢复，直接给从机断电重新上电吧，这也是最彻底的复位方式。

6.3 地址扫描与设备枚举，快速确认总线上挂了什么

在Linux环境或者调试开发板上，地址扫描是确认I2C设备是否存在的首选方法。使用i2cdetect加上总线编号，比如i2cdetect -y 1，它会扫描从0x03到0x77范围内的所有地址，逐一发送地址字节看看有没有设备响应。扫描结果会以表格形式列出哪些地址有设备回应、哪些没有。

STM32或者ESP32环境里，也可以在代码里写一个简单的扫描程序：循环枚举所有可能的7位地址，每次发送设备地址字节（写标志），检测是否有ACK响应，有响应就在串口里打印地址。实测中经常发现一些设备会占用多个地址响应，比如某些芯片在地址线悬空时内部上拉导致地址不唯一，扫描结果里出现多个地址的现象并不罕见，需要结合硬件连接来分析。

有一个很大的坑想提一下：i2cdetect扫描会向总线上所有地址发送数据，有些设备对非法命令比较敏感，可能会因此进入异常状态。特别是某些电源管理芯片，收到不认识的数据可能会改变输出状态，带来意料之外的问题。所以不建议在生产环境或者正在运行的系统上做无差别扫描，最好在开发阶段、系统刚上电时进行，并且扫描完检查一下设备状态。

7. 最后分享一点个人经验

自己从最早用51单片机软件模拟I2C读EEPROM，到后来在Linux下写驱动调一堆传感器，再到在FPGA里用Verilog实现I2C主机控制器，绕了不少弯路，最大的感受是：I2C协议本身并不难，难的是对细节的敬畏。

拿上拉电阻来说，刚学的时候觉得4.7kΩ是标准答案，结果板子设备一多、速率一高就出问题。后来养成一个习惯，每次画板时都给I2C总线预留不同阻值的贴片电阻位置，调试时根据波形实际情况灵活替换。同理，软件模拟I2C时的延时参数，不同主频的MCU差异很大，最好在代码里做成宏定义，方便调。

再分享一个实用的小建议：在支持I2C地址扫描的开发环境中，拿到一块新板子、一个新传感器时，不要急着看驱动源码，先用最原始的方法扫描地址、读一下ID寄存器，确认通信链路是通的，然后再去写业务逻辑。就像盖房子先打地基一样，通信链路通了，后面的一切才有意义。

另外一个屡试不爽的排查经验是：出现问题先降速。把I2C速率从400kHz降到100kHz，很多奇怪的偶发问题会消失。如果降速之后问题还在，那基本就不是时序和信号完整性的问题，而是要回头检查硬件连接、供电、地址配置和寄存器映射了。这个方法虽然听起来土，但排查效率是真的高。

最后关于工具，有条件的话好好用逻辑分析仪，它抓I2C波形比示波器方便很多，自动解码、直接看ACK状态。经历了多次“波形一抓，问题全明白了”的时刻之后，我是真心建议每个做嵌入式的朋友都备一台。I2C调试本来就不该是玄学，掌握了正确的思路和工具，它会是所有总线里最好用、最顺手的那一个。