1. 为什么I2C调试总是卡在第一步

搞嵌入式的人都有一个共识：I2C这东西，协议简单到半天就能背下来，但真到了板子上跑不通的时候，能把你折腾到怀疑人生。我做嵌入式也有十来年了，从8位机到Cortex-M再到嵌入式Linux，I2C外设调试始终是绕不过去的一道坎。你翻开任何一本讲I2C通信协议的书，无非就是起始条件、地址帧、读写位、ACK/NACK、停止条件这几个东西，时序图画得清清楚楚。但实际项目里，示波器一挂，波形要么出不来，要么出来了设备不响应，要么读回来全是0xFF，要么偶尔能通但跑几个小时就死掉。

这篇内容我想把I2C设备调试这件事从头到尾捋一遍，不是照本宣科讲协议，而是按照一个嵌入式工程师在真实项目里排查问题的思路来展开。不管你是刚入行的嵌入式软件工程师，还是做了几年主要跟SPI、UART打交道、突然被安排调I2C传感器的人，又或者是在嵌入式Linux下通过i2c-dev操作外设的开发者，这里面的思路和踩坑记录应该都能对你有用。核心关键词就三个：嵌入式、I2C、外设调试。我会围绕这三个词，把硬件层、驱动层、应用层的调试方法都覆盖到，尽量做到你拿着这篇内容就能对着自己的板子一步步排查。

先说一个基本认知：I2C调试的本质不是“写代码”，而是“定位问题在哪一层”。很多新手一遇到I2C读不到数据，第一反应是改代码、换驱动、翻数据手册，但真正高效的调试是先判断问题出在硬件连接、时序参数、地址配置还是软件流程上。这个判断过程需要你对I2C的物理层和协议层都有清晰的认识，并且手边要有趁手的工具。下面我按自己的调试习惯，从整体思路到具体实操，一步步拆开讲。

2. 调试思路的整体框架与工具准备

2.1 先分层再定位：I2C调试的四个观察点

我习惯把I2C调试分成四层来看，从下往上依次是：电气层、时序层、协议层、应用层。每一层都有对应的观察手段和典型故障模式。

电气层关注的是电压、上拉电阻、走线电容这些物理量。I2C是开漏输出，SDA和SCL都必须接上拉电阻，典型值4.7kΩ，但在高速模式或者总线电容较大的情况下需要减小到2.2kΩ甚至1kΩ。很多人忽略的一点是：上拉电阻是接到3.3V还是5V，取决于你的MCU和从设备的IO电平。如果MCU是3.3V而从设备是5V tolerant的，上拉接到3.3V没问题；但如果从设备要求5V逻辑高电平，你上拉到3.3V就可能识别不到。这个在混装器件的板子上特别常见。

时序层关注的是SCL频率、建立时间、保持时间、起始和停止条件的时序余量。标准模式100kHz、快速模式400kHz、快速+模式1MHz，不同从设备支持的最高频率不一样。你配置了400kHz但从设备只支持100kHz，通信就会时好时坏。更隐蔽的是时序余量不足：比如你的上拉电阻太大导致上升沿太缓，在示波器上看波形像锯齿波，从设备采样时可能刚好采到阈值附近，造成随机错误。

协议层关注的是地址、读写位、ACK/NACK、寄存器地址、数据格式。7位地址和8位地址的混淆是新手最常见的坑，很多数据手册给的是8位地址（包含读写位），而驱动API通常要的是7位地址，你得右移一位。还有大小端问题、寄存器地址宽度问题（8位还是16位）、连续读写的自动递增问题，这些都在协议层。

应用层关注的是你的业务逻辑是否正确，比如初始化序列有没有遗漏、配置寄存器的值是否合理、读取数据的时机是否恰当。有些传感器上电后需要等待一段时间才能访问，有些需要先写配置寄存器再触发测量，然后延时等待转换完成再读结果。这些流程上的细节，数据手册里都有，但很容易被忽略。

2.2 必备工具清单与选型理由

调试I2C，光靠printf是不够的。以下是我实际项目中用得最多的几样工具，按重要性排序。

示波器是第一位的。不需要多高端，带宽100MHz以上、双通道就够了。关键是能看波形，判断有没有起始条件、时钟频率大概多少、数据线有没有被拉低。我用的是一台老款DS1054Z，虽然只有50MHz带宽，但看100kHz到400kHz的I2C波形绰绰有余。如果你手头没有示波器，逻辑分析仪是退而求其次的选择，但逻辑分析仪只能看逻辑电平，看不到上升沿的斜率，在排查电气层问题时不如示波器直观。

逻辑分析仪是第二位的，推荐带I2C协议解码功能的。Saleae或者国产的Kingst都不错，配合上位机软件可以直接把波形翻译成地址、数据、ACK/NACK，省去手动解读的麻烦。特别是在分析复杂的读写序列时，协议解码能帮你快速定位到哪一帧出了问题。

万用表用来测电压和通断。上电第一件事就是量SDA和SCL的静态电平，正常应该是接近VCC的高电平。如果量出来是0V或者中间值，说明总线被拉死了或者上拉有问题。

USB转I2C适配器，比如常见的CH341或者FT232H方案，可以在不写MCU代码的情况下直接跟从设备通信。这个在验证从设备是否正常工作、确认地址是否正确时特别有用。你可以先用PC端的工具跟设备通上，确认设备没问题，再去调MCU端的代码，这样就把问题范围缩小了一半。

数据手册和原理图不用多说，但我要强调一点：一定要看原厂英文数据手册，不要只看中文翻译版或者网上抄来抄去的笔记。很多关键时序参数和寄存器定义，只有原厂手册才准确。

2.3 调试前的静态检查清单

在给板子上电之前，我通常会做以下几项静态检查，能排除掉相当一部分低级问题。

• 用万用表蜂鸣档测SDA、SCL对VCC和对GND是否短路。I2C走线上如果有一个器件焊反了或者损坏了，可能把整条总线拉死。
• 确认上拉电阻的阻值和连接。有些开发板把上拉电阻做成可选，通过跳线帽选择，出厂时可能没插。
• 确认所有I2C设备的地址不冲突。同一个总线上挂两个相同地址的器件是常见错误，比如两个AT24C02都默认地址0x50。
• 确认从设备的供电电压和IO电平与MCU匹配。3.3V的MCU直接连5V的从设备，长期运行可能损坏MCU的IO。
• 检查从设备的地址选择引脚（A0/A1/A2）是否正确接地或接VCC。

这些检查花不了十分钟，但能省下你几个小时甚至几天的调试时间。我见过太多案例，最后发现是上拉电阻没焊、地址引脚悬空、供电没接对这类问题。

3. I2C通信协议核心细节与常见误区

3.1 起始、停止与ACK：三个最容易出错的信号

I2C的起始条件（START）是SCL为高时SDA由高变低，停止条件（STOP）是SCL为高时SDA由低变高。这两个条件必须由主机产生，从设备只负责检测。实际调试中，起始条件出不来通常有两个原因：一是GPIO配置不对，SDA/SCL没有配置成开漏输出模式；二是总线上有器件把SDA或SCL拉低，导致主机无法产生正确的电平变化。

ACK/NACK是第9个时钟周期，主机发送完8位数据后释放SDA，从设备如果正确接收就把SDA拉低表示ACK，否则保持高电平表示NACK。这里有一个非常容易混淆的点：在读操作中，主机接收完8位数据后，需要主动发送ACK（继续读）或NACK（结束读）。很多新手写的读函数最后忘了发NACK，导致从设备一直等待，总线挂死。

我建议在调试初期，用逻辑分析仪把每一次通信的ACK/NACK都看清楚。如果主机发送地址后收到NACK，说明从设备没有响应，问题可能在地址不对、从设备没上电、或者从设备正在忙。如果数据阶段收到NACK，可能是从设备内部寄存器地址越界或者写保护。

3.2 7位地址与8位地址的换算陷阱

这是I2C调试中出现频率最高的错误之一。以常见的EEPROM AT24C02为例，数据手册上写的地址是1010xxx，其中xxx由A0/A1/A2引脚决定。如果A0/A1/A2都接地，7位地址是1010000，即0x50。但很多数据手册在描述读写操作时，会给出8位地址：写操作是0xA0，读操作是0xA1。这是因为8位地址的最低位是读写位，0表示写，1表示读。

在STM32的HAL库中，HAL_I2C_Master_Transmit函数的第二个参数是7位地址左移一位后的值，也就是0xA0。而在Linux的i2c-dev接口中，ioctl的地址参数是7位地址，即0x50。如果你在Linux下用了0xA0，就会通信失败。这个差异一定要根据你使用的平台来确认。

我个人的习惯是：在代码里统一用宏定义来管理地址，比如#define AT24C02_ADDR 0x50，然后在调用底层API时根据平台要求进行移位。这样即使换平台，也只需要改一处。

3.3 时钟拉伸与总线死锁的处理

时钟拉伸（Clock Stretching）是从设备在需要更多时间处理数据时，主动把SCL拉低的行为。主机必须检测SCL是否被拉低，如果是，就等待从设备释放。很多MCU的硬件I2C外设支持时钟拉伸，但有些低端MCU的硬件I2C不支持，或者软件模拟I2C时没有处理这个情况，导致通信失败。

总线死锁是另一个常见问题。典型场景是：主机在发送数据的过程中被复位，此时从设备还在等待第9个时钟，SDA被从设备拉低，主机重新初始化后无法产生起始条件，因为SDA一直是低的。解决方法是主机在初始化时发送9个时钟脉冲，让从设备完成当前字节的接收并释放SDA，然后发送停止条件。

在STM32的HAL库中，HAL_I2C_IsDeviceReady函数内部就包含了总线恢复的逻辑。如果你自己写GPIO模拟I2C，一定要在初始化函数里加上这个恢复流程。我踩过这个坑：一块板子跑了好几天都正常，突然某次热插拔传感器后I2C就死了，重启MCU也不行，最后发现是总线死锁，加了9个时钟脉冲的恢复逻辑后就再也没出现过。

4. 硬件层调试实操：从波形到参数计算

4.1 上拉电阻的计算与实测验证

上拉电阻的取值不是随便选一个4.7kΩ就完事。它需要满足两个条件：一是上升时间不能太长，二是功耗不能太大。上升时间由RC时间常数决定，R是上拉电阻，C是总线电容。I2C规范要求标准模式下上升时间不超过1000ns，快速模式下不超过300ns。

假设你的总线电容是200pF（包括走线、引脚、器件输入电容），快速模式要求上升时间小于300ns。RC时间常数τ=RC，上升时间约为2.2τ（从0.3VCC到0.7VCC）。所以2.2×R×200pF < 300ns，算出来R < 682Ω。这个值比常用的4.7kΩ小很多，说明在总线电容较大的情况下，4.7kΩ可能不满足快速模式的要求。

实际项目中，我通常先用4.7kΩ试，如果波形上升沿太缓，就并联一个2.2kΩ或者1kΩ。但要注意，电阻越小，器件拉低时的灌电流越大。I2C规范要求器件拉低时电压不超过0.4V，如果灌电流太大，低电平可能抬高，导致识别错误。所以这是一个折中：电阻小则上升快但低电平可能不够低，电阻大则低电平好但上升慢。

我的经验值是：3.3V系统、总线电容100pF左右、100kHz频率，4.7kΩ完全够用；400kHz频率建议用2.2kΩ；如果总线上挂了多个器件或者走线较长，用1kΩ到2.2kΩ之间。5V系统可以适当增大到4.7kΩ到10kΩ。

4.2 用示波器抓取I2C波形的正确姿势

用示波器看I2C波形，探头的地线要尽量短，最好用弹簧地针，避免长地线引入的振铃。触发方式设置为SDA下降沿触发，因为起始条件是SDA在SCL高时下降。时基设置为100μs/div左右，可以看完整的字节传输；如果要看上升沿细节，时基调到100ns/div。

一个健康的I2C波形应该是：SCL和SDA的高电平接近VCC，低电平接近0V，上升沿和下降沿干净利落，没有明显的过冲和振铃。如果看到上升沿有明显的圆弧，说明上拉电阻太大或者总线电容太大。如果看到低电平抬到了0.5V以上，说明灌电流太大或者器件有问题。

我还会用示波器的余晖模式观察波形的稳定性。如果波形在余晖模式下显示出一条粗带，说明时序有抖动，可能是时钟源不稳定或者中断干扰。如果波形很干净，只有一条细线，说明时序很稳定。

4.3 电源与地噪声对I2C的影响

很多人忽略电源质量对I2C通信的影响。I2C的阈值电平是相对于VCC的，如果VCC上有纹波或者噪声，阈值就会跟着波动，导致误判。特别是在电机、继电器、DC-DC开关电源附近，电源噪声可能达到几百毫伏。

我遇到过一个案例：一块板子上有I2C温度传感器和一个小型直流电机，电机不转的时候I2C通信正常，电机一转就频繁出错。用示波器看电源轨，发现电机启动瞬间VCC有大约300mV的跌落。解决方法是在传感器电源引脚旁边加一个100nF加10μF的退耦电容，并且把传感器的电源走线单独从LDO拉过来，不跟电机共用。

所以调试I2C时，如果通信时好时坏，一定要检查电源质量。用示波器AC耦合看VCC纹波，正常应该在几十毫伏以内。如果超过100mV，就要考虑加退耦电容或者改善电源布局。

5. 软件层调试实操：从寄存器到完整读写流程

5.1 寄存器读写的基本流程与代码示例

以常见的I2C传感器为例，读写寄存器的流程通常是：发送起始条件、发送从设备地址加写位、等待ACK、发送寄存器地址、等待ACK、发送数据（写操作）或者重复起始条件加读地址（读操作）、接收数据、发送NACK、发送停止条件。

下面是一个基于STM32 HAL库的写寄存器函数示例：

uint8_t I2C_WriteReg(uint8_t devAddr, uint8_t regAddr, uint8_t data) { uint8_t buf[2]; buf[0] = regAddr; buf[1] = data; if (HAL_I2C_Master_Transmit(&hi2c1, devAddr << 1, buf, 2, 100) != HAL_OK) { return 1; // 错误 } return 0; // 成功 }

读寄存器稍微复杂一些，需要先写寄存器地址，然后重复起始条件读数据：

uint8_t I2C_ReadReg(uint8_t devAddr, uint8_t regAddr, uint8_t *data) { if (HAL_I2C_Master_Transmit(&hi2c1, devAddr << 1, &regAddr, 1, 100) != HAL_OK) { return 1; } if (HAL_I2C_Master_Receive(&hi2c1, (devAddr << 1) | 1, data, 1, 100) != HAL_OK) { return 1; } return 0; }

注意这里devAddr << 1是因为HAL库要求传入的是8位地址。如果你用的是LL库或者寄存器操作，地址处理方式可能不同。

在Linux下通过i2c-dev操作，代码风格完全不同：

int fd = open("/dev/i2c-1", O_RDWR); ioctl(fd, I2C_SLAVE, 0x50); // 7位地址 uint8_t reg = 0x00; write(fd, &reg, 1); uint8_t data; read(fd, &data, 1); close(fd);

Linux的i2c-dev接口把读写分成了两个系统调用，中间的总线状态由内核维护。这种方式简单直接，但性能不如直接操作硬件寄存器，适合低速传感器。

5.2 连续读写与页写入的边界处理

很多I2C器件支持连续读写，比如EEPROM的页写入和传感器的突发读取。但连续读写有边界限制，超过边界后会回卷到页首或者产生未定义行为。

以AT24C02为例，页大小是8字节。如果你从地址0x07开始写8个字节，前1个字节写到0x07，后面7个字节会回卷到0x00到0x06，覆盖掉原来的数据。这个行为在数据手册里通常有说明，但很容易被忽略。

我的做法是：在写函数里加入边界检查，如果写入长度超过页边界，就拆分成多次写操作。读操作一般没有页边界问题，因为读是顺序递增的，但也要注意有些器件的地址计数器会在到达末尾后回卷。

对于传感器，连续读通常用于读取多个数据寄存器，比如三轴加速度计的X/Y/Z六个字节。这种情况下，你只需要确保从正确的起始寄存器开始读，长度不超过器件支持的最大连续读长度即可。

5.3 超时与重试机制的设计

I2C通信失败是常态，特别是在电磁环境复杂的工业现场。没有超时和重试机制的代码，一旦某次通信失败，整个系统可能就卡死了。

我在所有I2C读写函数里都会加超时参数。STM32的HAL库超时单位是毫秒，我通常设置为100ms。如果100ms内没有完成，就返回错误。上层调用者收到错误后，可以选择重试或者上报故障。

重试次数一般设为3次。第一次失败可能是偶发的干扰，第二次失败可能是从设备忙，第三次还失败就基本可以确定是硬件问题或者配置错误了。重试之间加一个短延时，比如10ms，给从设备恢复的时间。

但要注意：不是所有操作都适合重试。写操作重试可能导致数据重复写入，比如EEPROM的写操作，如果第一次写成功了但ACK丢失，重试会再写一次相同的数据，结果是一样的，没问题。但如果是计数器或者FIFO类的寄存器，重试可能导致数据错乱。所以重试策略要根据具体器件来定。

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

6.1 典型故障速查表

6.2 那些数据手册不会告诉你的坑

第一个坑：有些传感器的I2C地址在数据手册里写的是7位，但示例代码里用的是8位，而且没有明确说明。你照着示例代码写，换一个平台就出错。我的建议是：拿到任何I2C器件，先用USB转I2C适配器扫描地址，确认实际响应的是哪个地址，然后再写代码。

第二个坑：0.9寸OLED的I2C兼容性问题。很多0.9寸OLED用的是SSD1306驱动芯片，标称支持I2C，但实际上它的I2C时序要求比较特殊，特别是在上电初始化阶段，需要严格按照数据手册的初始化序列来，否则屏幕不亮或者显示乱码。我遇到过用硬件I2C怎么都不亮，换成GPIO模拟I2C就正常的情况，后来发现是硬件I2C的时钟频率在初始化阶段太快了，SSD1306反应不过来。解决方法是在初始化阶段降低时钟频率到100kHz以下，初始化完成后再提高到400kHz。

第三个坑：I2C扩展芯片的中断处理。像PCA9555这类I2C扩展IO芯片，中断引脚是开漏输出，需要上拉。如果你忘了上拉，中断就永远触发不了。而且中断触发后，你必须通过I2C读取输入寄存器才能清除中断，如果只处理中断引脚而不读寄存器，中断会一直保持。

第四个坑：嵌入式Linux下的I2C时钟频率配置。在设备树里配置I2C控制器时，clock-frequency属性设置的是总线频率，但实际频率还受时钟源分频的影响。有些SoC的I2C控制器在特定分频下无法得到标准的100kHz或400kHz，需要根据时钟树计算最接近的值。如果频率偏差太大，某些从设备可能无法正常通信。

6.3 从失败案例中总结的排查顺序

我总结了一个排查顺序，每次遇到I2C问题就按这个顺序走一遍，基本能覆盖90%以上的情况。

第一步，量电压。SDA和SCL的静态电平是否接近VCC，从设备VCC是否正常。这一步能排除供电和上拉问题。

第二步，看波形。用示波器或逻辑分析仪抓一次完整的通信过程，确认起始条件、地址、ACK、数据、停止条件是否都符合预期。这一步能定位到具体是哪一帧出了问题。

第三步，换设备。用USB转I2C适配器直接跟从设备通信，如果PC端能通，说明从设备没问题，问题在MCU端；如果PC端也不通，说明从设备或连接有问题。

第四步，降速。把I2C时钟降到100kHz甚至更低，如果降速后能通，说明是时序余量问题，需要调整上拉电阻或改善电源。

第五步，换引脚。如果以上都不行，换一组GPIO重新配置I2C，排除引脚损坏或复用冲突的可能。

这个顺序的核心逻辑是：先排除最简单的硬件问题，再逐步深入到软件和时序问题。很多新手一上来就改代码，结果改了半天发现是上拉电阻没焊，白白浪费时间。

7. 进阶话题：从裸机到嵌入式Linux的I2C调试差异

7.1 裸机环境下的直接寄存器操作

在裸机环境下，I2C调试的主动权完全在你手里。你可以直接操作寄存器，精确控制每一个时钟周期。以STM32为例，I2C控制器的CR1、CR2、DR、SR1、SR2、CCR、TRISE这几个寄存器就涵盖了所有功能。

直接寄存器操作的好处是响应快、没有中间层，适合对时序要求严格的场景。比如某些传感器要求在特定时间窗口内完成读写，用HAL库的函数调用可能因为层层封装导致超时。但坏处是可移植性差，换一个MCU就要重新看手册。

我的建议是：调试阶段可以用HAL库快速验证功能，功能通了之后如果对性能有要求，再考虑优化到LL库或者直接寄存器操作。不要一上来就啃寄存器，那样效率太低。

7.2 嵌入式Linux下的i2c-dev与设备树配置

在嵌入式Linux下，I2C设备的访问方式主要有两种：通过i2c-dev接口在用户空间操作，或者通过内核驱动在设备树里描述设备。

i2c-dev的方式前面已经给了代码示例，优点是简单灵活，不需要写内核驱动，适合快速验证和低速传感器。缺点是不能利用内核的中断和DMA机制，每次读写都要经过系统调用，开销较大。

设备树的方式需要在.dts文件里描述I2C设备和驱动匹配信息，然后写一个内核驱动来注册i2c_driver。这种方式适合需要高性能或者需要与内核其他子系统交互的场景。设备树里要配置I2C控制器的时钟频率、引脚复用、从设备地址等。

一个常见的坑是：设备树里配置了I2C设备，但内核启动后/dev/i2c-x不存在。这通常是因为I2C控制器驱动没有加载，或者引脚复用没有正确配置。检查dmesg里有没有I2C相关的错误信息，确认内核配置里使能了对应的I2C控制器驱动。

7.3 用Python在Linux下快速验证I2C设备

在嵌入式Linux下做原型验证，Python的smbus2库是个利器。它封装了i2c-dev的ioctl调用，用起来比C语言方便得多。

from smbus2 import SMBus bus = SMBus(1) addr = 0x50 reg = 0x00 value = bus.read_byte_data(addr, reg) print(f"Register 0x{reg:02X} = 0x{value:02X}") bus.close()

用Python脚本可以快速扫描总线上的设备地址，确认哪些地址有响应：

from smbus2 import SMBus bus = SMBus(1) for addr in range(0x03, 0x78): try: bus.read_byte(addr) print(f"Device found at 0x{addr:02X}") except: pass bus.close()

这个扫描脚本在调试新板子时特别有用，几秒钟就能知道总线上挂了哪些设备、地址分别是多少。比一个个查数据手册快多了。

但要注意：Python的I2C操作速度较慢，不适合高速连续读写。验证阶段用Python，正式产品还是用C或者内核驱动。

8. 调试习惯与经验沉淀

8.1 建立自己的I2C调试日志模板

我每调一个I2C设备，都会在项目文档里记录以下信息：器件型号、7位地址、8位地址、支持的最高时钟频率、上拉电阻值、电源电压、初始化序列、关键寄存器说明、调试过程中遇到的问题和解决方法。

这个习惯看起来麻烦，但下次再用到这个器件或者遇到类似问题时，翻一下记录就能快速上手。我见过太多人调完一个传感器就把代码扔在一边，过几个月再用，又得从头看数据手册。

日志模板可以很简单，用Markdown表格就行：

8.2 代码复用与抽象层设计

I2C设备的读写函数有很多共性，可以抽象出一层通用的I2C访问接口，然后针对不同器件写具体的寄存器操作函数。这样换器件时只需要改器件相关的部分，底层的I2C读写不用动。

我的做法是定义一个结构体来描述I2C设备：

typedef struct { uint8_t devAddr; uint32_t timeout; uint8_t (*writeReg)(uint8_t addr, uint8_t reg, uint8_t data); uint8_t (*readReg)(uint8_t addr, uint8_t reg, uint8_t *data); } I2C_Device;

然后每个器件实现自己的writeReg和readReg函数，注册到这个结构体里。上层业务代码只跟结构体打交道，不关心底层是硬件I2C还是软件模拟。

这种设计在项目里有多个I2C器件时特别有用，代码结构清晰，维护方便。

8.3 从调试中积累的几条硬核经验

第一条：永远不要相信“这个器件是标准的I2C”。I2C规范只定义了协议框架，具体到每个器件，时序要求、地址格式、寄存器定义都可能不同。有的器件支持时钟拉伸，有的不支持；有的器件在特定条件下会拉低SCL，有的不会。拿到新器件，先花半小时把数据手册的时序章节和寄存器章节看一遍，比盲目调试省时间。

第二条：示波器比逻辑分析仪更重要。逻辑分析仪能告诉你协议对不对，但示波器能告诉你信号质量好不好。很多“协议正确但通信失败”的问题，根源在信号质量上。如果只能买一台设备，先买示波器。

第三条：降速是万能的排查手段。通信不稳定时，先把时钟降到100kHz甚至50kHz。如果降速后稳定了，说明是时序余量问题，再逐步提高频率找到临界点，然后留出足够的余量。如果降速后还是不稳定，说明问题不在时序上，继续查硬件和配置。

第四条：I2C总线上不要挂太多器件。理论上I2C可以挂127个设备，但实际项目中，总线电容会随着器件数量增加而增大，导致上升沿变缓。我一般建议一条总线不超过4到5个器件，超过的话用I2C多路复用器扩展。

第五条：写EEPROM一定要加延时。EEPROM的写周期典型值是5ms，在这5ms内器件不响应任何I2C请求。如果你写完立刻读，会收到NACK。正确的做法是写完延时5ms，或者用ACK轮询的方式等待器件就绪。

这些经验都是我在实际项目中踩坑踩出来的，每一条背后都有至少一个加班到深夜的故事。希望你看完之后，能少走一些弯路。I2C调试这件事，说难不难，说简单也不简单，关键在于有没有一套系统的排查思路和足够的耐心。工具备好，思路清晰，剩下的就是逐个排除可能性。