I2C 总线怎么用怎么排障—万物智能之开源鸿蒙 OpenHarmony 系统实战开发系列教程一块开发板摆在我面前主控是 OpenHarmony 标准系统外挂一颗常见的六轴传感器。系统起来了HDF 驱动也注册了设备节点看着都在可最后一读寄存器返回值要么超时要么干脆是 0xFF。我盯着屏幕半天最后拿万用表测了一下 SDA 引脚的电压——1.8V 都不到。问题不在代码在硬件但如果你不先把 I2C 总线的时序和电平整明白了这个问题你查一天都可能查不出来。这篇文章不打算给你念协议规范而是想把我在 OpenHarmony 上做 I2C 设备开发时真正会用到的知识梳理一遍先从协议本身说起再讲 OpenHarmony 侧怎么把 I2C 用起来然后给一套从外设接线到寄存器读取的完整实战流程最后重点讲排障。排障是很多人最头疼的部分我给你一套能直接照着走的排查方法外加一个真实的“幽灵总线”问题复盘。无论你是刚接触 OpenHarmony 驱动开发还是已经被 I2C 折磨过几个通宵这篇都应该能帮到你。1. 先把 I2C 时序吃透排障全靠它打底1.1 一条总线、两根线、若干从机I2CInter-Integrated Circuit总线的物理层简单得让人怀疑就两根线SCL时钟线和 SDA数据线。所有设备都挂在这两根线上主机负责产生时钟、发起通信从机通过地址被寻址。OpenHarmony 的嵌入式设备上主控通常就是主机外设传感器、EEPROM、显示驱动芯片、RTC都是从机。关键点是这两根线都是开漏结构。开漏意味着设备只能把线拉低不能主动拉高所以必须靠外部上拉电阻把线拉高。这个细节是后续很多排障问题的根源——上拉电阻缺失、上拉电阻过大导致信号上升沿太缓都会引发莫名其妙的通信失败。一根总线上挂多个从机靠的是地址区分。绝大多数 I2C 从机是 7 位地址有的芯片支持 10 位地址模式。主机发送地址时前 7 位是地址第 8 位是读/写标志位0 表示写1 表示读。你可能会在数据手册里看到“0x68”或者“0xD0”这样的地址前者通常是 7 位地址后者是把读写位拼上后的 8 位地址。比如常见的 MPU6050 陀螺仪7 位地址是 0x68写地址就是 0xD0读地址就是 0xD1。OpenHarmony 的 I2C 接口里填的通常是 7 位地址这个坑我见过不少人踩。1.2 四个必须看懂的时序状态排障的时候你不可能每次都拿示波器去量波形但你必须能看懂波形或者至少在脑子里模拟出时序过程。I2C 通信中最重要的几个时序状态说穿了就四个第一个是起始条件。SCL 保持高电平的时候SDA 产生一个下降沿。这个下降沿告诉所有从机“注意主机要开始通信了。”所有挂在总线上的设备都会在此时被唤醒开始监听地址。第二个是停止条件。SCL 保持高电平的时候SDA 产生一个上升沿。这个上升沿告诉从机“通信结束总线释放。”如果在传输过程中总线错误地产生了停止条件比如主控的干扰、SDA 电平不稳整个通信就会被打断从机会以为主机放弃了当前的操作。第三个是数据采样。SDA 上的数据必须在 SCL 低电平期间变化在 SCL 高电平期间保持稳定。因为从机是在 SCL 的上升沿或者高电平期间采样 SDA 的。也就是说你在代码里往寄存器写入的值在硬件上表现为一个个数据位它们必须严格遵守“SCL 低时变SCL 高时稳”的规则。写驱动时如果因为中断延迟、GPIO 模拟时序时抖动太大导致 SDA 在 SCL 高电平期间发生了跳变从机就会采到错位的数据。第四个是应答位。每发送完 8 个数据位第 9 个时钟周期是 ACK/NACK 位由接收方控制。主机发送完一字节后从机如果收到了会在第 9 个时钟把 SDA 拉低表示应答ACK。如果从机没有响应SDA 保持高电平就是 NACK。读设备探测不到、地址错误、设备不在总线上最直接的表现就是收到 NACK。反过来主机读数据时读完最后一字节后主机要主动释放 SDA不发 ACK让从机知道“这是最后一个字节了”随后产生停止条件。很多刚接触 I2C 的开发者最大的问题就是把协议当成一个“黑盒”来用只调 API 不管时序。一旦 API 调用失败就完全无从下手。我把时序单独拎出来讲就是希望你遇到问题时能退一步想总线上到底发生了什么是起始条件没发出来是地址阶段就没得到应答还是数据阶段 ACK 丢失了1.3 速率、上拉电阻和总线电容I2C 有几种标准速率模式整理一下你就知道模式速率典型应用场景标准模式100 kbit/s老式 EEPROM、RTC快速模式400 kbit/s绝大多数传感器、显示驱动快速模式1 Mbit/s高刷新率传感器、触控 IC高速模式3.4 Mbit/s高速存储类外设较少见OpenHarmony 上的 I2C 控制器一般默认工作在 100kHz 或 400kHz具体看 SoC 平台和驱动配置。从机支持不了太快主机这边时序不准就降速。实际开发中如果通信不稳定先把速率降到 100kHz 试试——这一步能排除大量“从机跟不上主机”的问题。上拉电阻的选择也有讲究。总线空闲时靠上拉电阻把 SDA 和 SCL 拉到高电平电阻太大会造成上升沿变慢电阻太小会加大灌电流。经验值3.3V 系统配 4.7kΩ 到 10kΩ5V 系统配 2.2kΩ 到 4.7kΩ。如果总线上挂了很多设备总线电容增大上拉电阻就要适当减小。快速模式 400kHz 的典型上升沿时间要求是 300ns你可以用阻值乘以总线等效电容来估算RC 时间常数越接近 1/3 的上升沿时间越稳。我在实际调试中常干的一件事是直接拿示波器探针测 SCL 的上升沿如果上升沿慢得像个梯形第一反应就是上拉电阻太大。在 OpenHarmony 的开发板上I2C 引脚可能已经被板级设计接好了上拉电阻但如果你是通过排线外接传感器模块很多时候模块上自带 10k 上拉板子上的上拉也在两个并联后就变成 5k 左右这种经验值是允许的。真正怕的是某些模块上完全没有上拉而开发板的 I2C 引脚恰好没有内部上拉那就等着通信失败吧。2. OpenHarmony 侧 I2C 接入驱动框架与 API 调用链路2.1 HDF 框架下的 I2C 平台驱动OpenHarmony 的设备驱动主要跑在 HDFHardware Driver Foundation框架之上。HDF 把驱动分成几个层次平台驱动由 SoC 厂商负责实现管理 I2C 控制器硬件外设驱动是你自己要写的管理具体的传感器、EEPROM 等设备。两者之间通过 HDF 提供的接口通信这样 SoC 换了你的外设驱动不用大改。I2C 控制器在 OpenHarmony 里一般按编号区分比如 I2C 0、I2C 1、I2C 2每个控制器对应一条物理总线也可能通过复用扩展出多条。当你写外设驱动时你在配置文件里指定总线号、从机地址、通信速率等参数。HDF 的 match 机制会把你的外设驱动绑定到对应的 I2C 控制器驱动上。这里有个常见的认知偏差有人以为 OpenHarmony 里操作 I2C 就像在 Linux 用户态一样open(/dev/i2c-x)然后用 ioctl 发消息。那是在传统 Linux 环境下的玩法。OpenHarmony 标准系统里如果走 HDF通常是你自己的 HDF 驱动通过平台接口去和 I2C 控制器交互。当然OpenHarmony 也有类似 i2c-tools 的能力可以把 I2C 设备抽象成某个节点但从驱动开发的角度核心还是 HDF 外设驱动 I2C 平台接口这套组合。2.2 核心接口的使用逻辑HDF 的外设驱动要操作 I2C思路大概是下面这四步第一步在 HDF 驱动初始化时获取 I2C 控制器的句柄。你可以通过 HDF 的设备管理接口按照你在配置文件中声明的总线号和设备名去获取对应服务。代码看起来像这样#include hdf_io_device.h #include i2c_if.h static struct I2cDevice *i2c_dev NULL; int32_t MySensorInit(void) { // 第一个参数是总线号第二个是设备地址7位 i2c_dev I2cOpen(0, 0x68); if (i2c_dev NULL) { HILOG_ERROR(I2cOpen failed); return HDF_FAILURE; } return HDF_SUCCESS; }第二步配置通信参数。部分平台驱动支持配置传输速率、地址位宽等信息。如果平台驱动默认配置就能满足需求这一步也可以跳过。第三步核心操作发送数据、接收数据、或者一次组合传输。I2C 的读取通常是“先写寄存器地址再读数据”这两个操作要组合在一次传输里完成才能保证总线上没有其他设备插入操作。HDF 的 I2C 接口一般会提供一个消息列表式的接口让你把多个 I2C 消息组合起来一次完成复合操作。// 组合操作先向设备写入寄存器地址 0x3B再读取 6 字节数据 uint8_t reg_addr 0x3B; uint8_t buffer[6] {0}; struct I2cMsg msgs[2]; msgs[0].addr 0x68; msgs[0].flags 0; // 0 表示写 msgs[0].len 1; msgs[0].buf reg_addr; msgs[1].addr 0x68; msgs[1].flags I2C_FLAG_READ; // 读标志 msgs[1].len 6; msgs[1].buf buffer; int32_t ret I2cTransfer(i2c_dev, msgs, 2); if (ret ! 2) { HILOG_ERROR(I2cTransfer failed, ret%d, ret); return HDF_FAILURE; }这里有几个细节值得注意。第一ret的返回值表示成功传输的消息条数不是字节数。你发了 2 条消息返回 2 才是全部成功返回 1 说明第二条读消息失败了返回负数说明更底层的错误。第二addr填的是 7 位地址不要左移一位也不要拼上读写位。这个问题我在别处见过一堆人栽跟头因为传统 i2c-dev 的 ioctl 里地址是 8 位的被左移过的但 HDF 接口一般要求 7 位原始地址。第三读操作和写操作的组合顺序很关键你写的就是从机寄存器地址所以必须先写再读这个顺序不能反。第四步使用结束后释放句柄跟其他资源一样I2cOpen和I2cClose要成对出现。驱动卸载时别漏了。2.3 内核态和用户态的取舍OpenHarmony 上做 I2C 开发你还会面临一个选择把逻辑放内核态驱动还是放用户态服务两者各有适用场景我按实际项目经验给你一个参考场景推荐方案原因需要极高的可靠性和实时性比如 IMU 数据采集、电机控制反馈内核态 HDF 平台驱动减少用户态到内核态的切换开销响应更稳定业务逻辑复杂、需要频繁改策略比如环境传感器周期性上报用户态服务 HDF 用户态接口开发效率高崩溃不影响系统稳定系统已经有标准 HDF 驱动封装只需要上层调用优先沿用已有封装无需重复造轮子对于多数 OpenHarmony 项目我不建议一上来就在内核态写一堆业务逻辑。内核态驱动负责和硬件打交道把数据往上送业务逻辑放用户态好调试、好迭代。I2C 本身速率不高大多数传感器产品的数据量也很小用户态多一次 IPC 的开销完全不是瓶颈反而是内核态代码写错了直接拉起 Kernel Panic调试成本高得多。3. 实战给开发板接一颗 I2C 外设从配置到读数这一部分我们走一遍完整流程。我拿一个常见的 EEPROM比如 AT24C02和一个数字温湿度传感器比如 SHT30做例子因为这两种设备都是典型的小型 I2C 从机时序要求明确各家的实现也差不多。你只要照着这个流程走换什么外设都是同样的套路。3.1 电路连接和引脚确认先说硬件。从机设备需要 4 个引脚VCC、GND、SDA、SCL有的还有地址选择引脚A0/A1/A2和写保护引脚WP。连接的时候注意三点VCC 和 GND 要共地。这个听起来像废话但外接模块供电没和开发板共地的话SDA/SCL 的高低电平没有一个统一的参考点通信必然失败而且失败得很随机。SDA 和 SCL 要接到开发板上真正的 I2C 引脚不是随便找两个 GPIO。OpenHarmony 标准系统的 SoC 通常有专门的 I2C 引脚复用功能你得查板级配置确定引脚被配置为 I2C 功能而不是 GPIO。上拉电阻确认好。开发板原理图上标着有上拉但实际板卡由于版本差异可能会有改动最好万用表量一下SDA 到 VCC 之间应该有 2k~10k 左右的电阻值。以 SHT30 为例它默认的 7 位地址是 0x44还有一颗可选地址 0x45。接线就是 VCC-3.3V、GND-GND、SCL-I2C0_SCL、SDA-I2C0_SDA标准四线制。3.2 板级配置让引脚变成 I2C在 OpenHarmony 的板级配置中你需要确认 I2C 控制器对应的引脚复用已被配置。这块和具体的开发板、HDF 平台驱动相关但思路是共通的找到板级配置中 I2C 控制器相关的节点确认它没有被 GPIO 等其他功能占用。比如你在调试中发现 I2C 不通可以用hdf相关工具看一下 I2C 设备是否已经注册# 在 OpenHarmony 的 shell 中查看 HDF 设备 hdc shell hidumper -s I2cService # 或查看 /dev 下是否有对应的 I2C 设备节点 hdc shell ls /dev/i2c-*如果系统编译时根本没有使能 I2C 控制器驱动或者引脚被其他外设占了后面代码写得再对也没用。这一步排障时优先级很高。3.3 写一个地址扫描程序外设接好了系统起来了先别急着写驱动先写个 I2C 地址扫描程序看看总线上能不能探测到你的设备。这个思路源自 Linux 的 i2cdetect 工具OpenHarmony 上即使没有现成工具你也可以在自己的 HDF 测试驱动里实现同样的逻辑遍历 0x03~0x77 范围内的地址向每个地址发一个写请求看有没有 ACK。核心逻辑很简单打开 I2C对每个地址发一条 0 字节消息SMBus 风格或者发一个单字节读。有 ACK 返回的地址就被视为有设备int32_t ScanBus(uint32_t busNum) { struct I2cDevice *dev I2cOpen(busNum, 0x00); if (dev NULL) { return HDF_FAILURE; } for (uint16_t addr 0x03; addr 0x77; addr) { struct I2cMsg msg; msg.addr addr; msg.flags 0; // 写方向 msg.len 1; uint8_t buf 0x00; msg.buf buf; int32_t ret I2cTransfer(dev, msg, 1); if (ret 1) { HILOG_INFO(Found device at 0x%02X, addr); } } I2cClose(dev); return HDF_SUCCESS; }这里的一个细节有些设备对单字节写操作不响应但对特定寄存器读会响应。所以扫描不到不一定说明设备不在总线上也可能设备比较“挑食”。不过对绝大多数从机来说一字节写是能收到 ACK 的你可以先用这个扫一遍心里有个底。3.4 读寄存器和校验数据扫到地址之后就是正式的读写了。继续用 SHT30 举例我们要读取它的温度数据。SHT30 的过 程是主机发送一条“软复位”命令或者“测量命令”等待测量完成后主机读取 6 字节数据温度 2 字节 CRC 1 字节 湿度 2 字节 CRC 1 字节。代码逻辑用 HDF 接口来实现就是两条消息的组合先写命令0x24 0x00 表示周期测量模式延时一小段时间再发起一次读 6 字节的传输uint8_t cmd[2] {0x24, 0x00}; struct I2cMsg writeCmd; writeCmd.addr 0x44; writeCmd.flags 0; writeCmd.len 2; writeCmd.buf cmd; struct I2cMsg readData; uint8_t data[6] {0}; readData.addr 0x44; readData.flags I2C_FLAG_READ; readData.len 6; readData.buf data; // 先写命令 struct I2cMsg msgs[1] {writeCmd}; if (I2cTransfer(dev, msgs, 1) ! 1) { // 错误处理 } OsDelay(10000); // 等待测量完成单位是 tick需根据系统配置换算 // 再读数据 struct I2cMsg msgs2[1] {readData}; if (I2cTransfer(dev, msgs2, 1) ! 1) { // 错误处理 } // 数据解析SHT30 返回的原始温度值换算 uint16_t rawTemp (data[0] 8) | data[1]; float temp -45.0f 175.0f * (rawTemp / 65535.0f);这里做个小提醒I2C 传送的数据是大端序多字节数据一般是高字节在前。你读到的data[0]是高位字节data[1]是低位字节别倒过来算。换算公式各传感器手册都有照着手册来就行。4. I2C 排障方法论五类高频故障的定位顺序排障是最考验经验的部分。I2C 的故障现象来来回回就那么几种但背后的原因千奇百怪。我总结了一套排查顺序你按这个顺序查至少能排除 80% 的问题。4.1 故障现象和直接原因先给你一张对照表遇到现象直接定位方向现象最可能原因建议排查手段地址扫描不到任何设备共地问题、上拉电阻缺失、引脚复用错误、总线未使能万用表量电平、查板级配置、确认 HDF 设备节点扫描到了地址但读寄存器超时从机电源不稳、SCL 频率过高、从机处于休眠状态降速到 100kHz、检查从机供电时序、确认唤醒引脚读到数据全是 0xFF 或全 0x00上拉电阻问题全 FF 多为 SDA 悬空、地址错误、寄存器地址没写对测 SCL/SDA 静态电平、逐字节打印传输过程数据读到一半出错偶尔好偶尔坏时序竞争、中断影响、总线电容过大抓波形、排查中断优先级、减小上拉电阻总线挂死SDA 被拉低无法释放从机进入了异常状态、主机未正确释放总线、总线上有设备吐数据给从机断电重启、检查起始/停止条件是否完整4.2 从代码到波形的三级排查法遇到问题先别慌按三个层次逐级排查第一级代码层。检查参数总线号对不对设备地址填对没有flags 是否正确transfer 返回值是什么有时候问题就出在你自己写的代码上比如把 7 位地址左移了一位导致地址阶段一直 NACK。返回值为负数时HDF 平台驱动的错误码也能提供线索比如ENODEV可能是 I2C 控制器没有打开EBUSY可能是总线正被其他设备占用。第二级系统层。用设备节点、日志、HDF 调试接口确认系统侧的 I2C 状态。比如用hidumper查看 I2C 控制器的注册信息确认平台驱动已经正确枚举了这条总线。同时检查 dmesg 里有没有 I2C 相关的错误打印。很多问题在系统层就能发现比如引脚复用冲突I2C 引脚被另一个驱动申请成了 GPIO 功能这在日志里通常有线索。第三级波形层。用逻辑分析仪或者示波器抓 SCL 和 SDA 的实际波形。这一级能做出最终的判决。逻辑分析仪建议买 24MHz 起步的抓 I2C 足够用了。不一定要多贵的设备我用过的 200 块钱左右的 8 通道逻辑分析仪配合 sigrok 就干过不少活。接线时把两个探头夹到 SCL 和 SDA 上触发条件设成下降沿然后启动你要测试的程序抓到一帧完整的通信波形。4.3 怎么看抓到的波形拿到波形之后按下面的顺序依次检查看有没有起始条件。波形最开始应该是 SCL 高电平期间 SDA 出现一个下降沿。如果程序跑了但总线上啥也没有说明代码根本没发起传输问题在主控侧。看地址字节对不对。SCL 第 1 个到第 7 个上升沿之间SDA 的电平组合就是地址。对照你填写的地址确认硬件上发的和代码里填的一致。特别注意字节序高位在前。看 ACK 位。第 9 个时钟周期 SDA 是否被拉低。如果拉低了说明从机应答了链路是通的如果没有说明地址不对或者从机没上电。看数据字节。按照每字节 8 位 ACK 的节奏把数据一个个解出来对照你期望写入的寄存器值。这里最容易发现“写命令没执行”、“寄存器地址偏移一位”这类问题。看停止条件。传输结束应该有一个 SCL 高电平期间 SDA 上升沿。如果停在了半路总线会一直处于占用状态下一次传输就可能失败。我在项目里遇到过一次很典型的情况代码逻辑完全正确但逻辑分析仪上第一个字节的地址总是变成 0xD1 而不是 0xD0。后来发现是 GPIO 模拟 I2C 的驱动里字节传输的第一位没有正确驱动 SDA导致最高位丢失。这类问题光看代码是看不出来的波形一抓就现形。5. 一个真实“幽灵总线”问题从头到尾的排查过程这一部分我想给你完整复盘一次我遇到过的 I2C 疑难杂症。这种问题现象不固定、复现率低、网上也搜不到现成答案非常折磨人。把它写出来是希望你能建立一套自己的排查直觉。5.1 现象设备偶尔丢失重启后恢复产品是一个带温湿度传感器和 EEPROM 的 OpenHarmony 设备。正常跑着没问题但只要系统一开机或者在某个特定时间点传感器读数会突然变成 0xFFFF再往后就一直失败直到重启系统才恢复。一开始我以为是驱动代码的并发问题。因为系统里多个任务会同时访问 I2C 总线一个任务周期性读传感器另一个任务偶尔写 EEPROM。如果两个任务没有正确同步消息可能交错导致从机进入不可预期状态。我把驱动里的 I2C 操作加上了互斥锁满心期待地跑了一个晚上结果问题照样出现。5.2 第一轮排查怀疑驱动和并发既然问题还在我就开始怀疑是不是读写操作本身破坏了从机的状态机。我把驱动的日志打开在每次 transfer 前后都打印时间戳和参数。结果发现每次传感器出错之前都会发生一次 EEPROM 写入操作。这进一步强化了并发冲突的猜测但我加了锁之后问题还在那要么是锁没加全有其他路径绕过锁要么根本不是并发问题。既然代码层已经查不出啥我开始查电气层。我量了 SCL 和 SDA 的静态电平总线空闲时都是 3.3V正常。然后用示波器长时间抓波形终于在一次故障发生时抓到了关键证据SDA 被永久拉低SCL 还能正常翻转但 SDA 始终是低电平总线进入了挂死状态。5.3 第二轮排查抓到总线挂死波形SDA 被拉低并且无法恢复这很典型地说明总线上某个设备进入了异常状态一直占用着 SDA。正常情况下主机发出停止条件后 SDA 应该释放为高。但此时 SDA 被某个从机死拽着谁来传输都会失败。我当时的第一个想法是某个从机收到了不合法的数据触发了内部异常把 SDA 锁死了。这在我之前用过的某颗 EEPROM 上看过——如果 WP 引脚电平不稳定EEPROM 在写入过程中断电内部状态机会卡住SDA 就死锁了。我开始排查 EEPROM 的 WP 引脚。结果发现电路设计上这个引脚的驱动是由主控的另一个 GPIO 负责的而那个 GPIO 在某个初始化步骤里被复用成了其他功能导致 WP 电平在高阻和低电平之间漂移。EEPROM 在写入中途失去写保护又恰好在那个时刻总线有干扰就把自己的内部状态机搞乱了SDA 拉死不松手。5.4 根因与修复从机锁死背后的连锁反应修复分两步第一步是应急让设备能自动恢复——驱动里增加总线恢复逻辑当检测到 SDA 长时间为低时对 SCL 连续翻转 9 个时钟周期让锁死的从机退出异常状态这个技巧在很多现代主控的 I2C 控制器里都有内置。第二步是治本把 GPIO 复用配置修正确保 WP 引脚上电后始终保持确定电平不允许被复用。经过这轮处理问题彻底消失。这个案例给我最大的启发是I2C 排障不能只看一层。第一次失败是因为并发猜测第二次成功是因为抓到了波形但根本原因却是一个 GPIO 复用配置。如果你问我排障最有用的能力是什么我会说是“多准备几个排查维度”代码逻辑查完查系统配置系统配置查完查电路电气特性电气特性查完再回到代码。循环往复总能找到答案。5.5 这类问题的通用解法根据这次经验后来我遇到 I2C 总线挂死直接按下面这套走确认是不是真的挂死用示波器或万用表测 SDA 静态电平如果总线空闲时是低电平 0.2V 以下基本是挂死了。能断电就断电给疑似异常从机断电几秒再恢复看 SDA 是否释放。如果释放了说明就是那台设备锁死了。代码层补救I2C 控制器如果支持总线清零BUS CLEAR特性驱动程序里加上。不支持就在 GPIO 层面手动翻转 SCL 来触发从机复位。防患于未然检查每台从机的电源、复位引脚、写保护引脚确保上电时序正确主机和从机之间的时序冲突尽量在驱动里用锁和超时机制兜住。注意手动翻转 SCL 来解锁总线只适用于从机被异常状态卡住的情况而且翻转前一定要确保 SDA 已经被释放否则反而可能制造出意外的起始/停止条件让问题更复杂。我个人在实际操作中的体会是I2C 排障九成靠思路清晰一成靠运气。别被“疑难杂症”吓住按代码、系统、波形三个层次一步步走绝大多数问题都会在某个层次上露出马脚。最后再分享一个小技巧如果你经常跟 I2C 打交道逻辑分析仪一定要备一个而且抓波形的时候不要只抓一帧多抓几帧把故障前后的波形都录下来对比着看很多“偶发”问题其实藏在你没注意的那一两个时钟周期里。
OpenHarmony I2C总线开发与排障实战：时序、驱动与应用
I2C 总线怎么用怎么排障—万物智能之开源鸿蒙 OpenHarmony 系统实战开发系列教程一块开发板摆在我面前主控是 OpenHarmony 标准系统外挂一颗常见的六轴传感器。系统起来了HDF 驱动也注册了设备节点看着都在可最后一读寄存器返回值要么超时要么干脆是 0xFF。我盯着屏幕半天最后拿万用表测了一下 SDA 引脚的电压——1.8V 都不到。问题不在代码在硬件但如果你不先把 I2C 总线的时序和电平整明白了这个问题你查一天都可能查不出来。这篇文章不打算给你念协议规范而是想把我在 OpenHarmony 上做 I2C 设备开发时真正会用到的知识梳理一遍先从协议本身说起再讲 OpenHarmony 侧怎么把 I2C 用起来然后给一套从外设接线到寄存器读取的完整实战流程最后重点讲排障。排障是很多人最头疼的部分我给你一套能直接照着走的排查方法外加一个真实的“幽灵总线”问题复盘。无论你是刚接触 OpenHarmony 驱动开发还是已经被 I2C 折磨过几个通宵这篇都应该能帮到你。1. 先把 I2C 时序吃透排障全靠它打底1.1 一条总线、两根线、若干从机I2CInter-Integrated Circuit总线的物理层简单得让人怀疑就两根线SCL时钟线和 SDA数据线。所有设备都挂在这两根线上主机负责产生时钟、发起通信从机通过地址被寻址。OpenHarmony 的嵌入式设备上主控通常就是主机外设传感器、EEPROM、显示驱动芯片、RTC都是从机。关键点是这两根线都是开漏结构。开漏意味着设备只能把线拉低不能主动拉高所以必须靠外部上拉电阻把线拉高。这个细节是后续很多排障问题的根源——上拉电阻缺失、上拉电阻过大导致信号上升沿太缓都会引发莫名其妙的通信失败。一根总线上挂多个从机靠的是地址区分。绝大多数 I2C 从机是 7 位地址有的芯片支持 10 位地址模式。主机发送地址时前 7 位是地址第 8 位是读/写标志位0 表示写1 表示读。你可能会在数据手册里看到“0x68”或者“0xD0”这样的地址前者通常是 7 位地址后者是把读写位拼上后的 8 位地址。比如常见的 MPU6050 陀螺仪7 位地址是 0x68写地址就是 0xD0读地址就是 0xD1。OpenHarmony 的 I2C 接口里填的通常是 7 位地址这个坑我见过不少人踩。1.2 四个必须看懂的时序状态排障的时候你不可能每次都拿示波器去量波形但你必须能看懂波形或者至少在脑子里模拟出时序过程。I2C 通信中最重要的几个时序状态说穿了就四个第一个是起始条件。SCL 保持高电平的时候SDA 产生一个下降沿。这个下降沿告诉所有从机“注意主机要开始通信了。”所有挂在总线上的设备都会在此时被唤醒开始监听地址。第二个是停止条件。SCL 保持高电平的时候SDA 产生一个上升沿。这个上升沿告诉从机“通信结束总线释放。”如果在传输过程中总线错误地产生了停止条件比如主控的干扰、SDA 电平不稳整个通信就会被打断从机会以为主机放弃了当前的操作。第三个是数据采样。SDA 上的数据必须在 SCL 低电平期间变化在 SCL 高电平期间保持稳定。因为从机是在 SCL 的上升沿或者高电平期间采样 SDA 的。也就是说你在代码里往寄存器写入的值在硬件上表现为一个个数据位它们必须严格遵守“SCL 低时变SCL 高时稳”的规则。写驱动时如果因为中断延迟、GPIO 模拟时序时抖动太大导致 SDA 在 SCL 高电平期间发生了跳变从机就会采到错位的数据。第四个是应答位。每发送完 8 个数据位第 9 个时钟周期是 ACK/NACK 位由接收方控制。主机发送完一字节后从机如果收到了会在第 9 个时钟把 SDA 拉低表示应答ACK。如果从机没有响应SDA 保持高电平就是 NACK。读设备探测不到、地址错误、设备不在总线上最直接的表现就是收到 NACK。反过来主机读数据时读完最后一字节后主机要主动释放 SDA不发 ACK让从机知道“这是最后一个字节了”随后产生停止条件。很多刚接触 I2C 的开发者最大的问题就是把协议当成一个“黑盒”来用只调 API 不管时序。一旦 API 调用失败就完全无从下手。我把时序单独拎出来讲就是希望你遇到问题时能退一步想总线上到底发生了什么是起始条件没发出来是地址阶段就没得到应答还是数据阶段 ACK 丢失了1.3 速率、上拉电阻和总线电容I2C 有几种标准速率模式整理一下你就知道模式速率典型应用场景标准模式100 kbit/s老式 EEPROM、RTC快速模式400 kbit/s绝大多数传感器、显示驱动快速模式1 Mbit/s高刷新率传感器、触控 IC高速模式3.4 Mbit/s高速存储类外设较少见OpenHarmony 上的 I2C 控制器一般默认工作在 100kHz 或 400kHz具体看 SoC 平台和驱动配置。从机支持不了太快主机这边时序不准就降速。实际开发中如果通信不稳定先把速率降到 100kHz 试试——这一步能排除大量“从机跟不上主机”的问题。上拉电阻的选择也有讲究。总线空闲时靠上拉电阻把 SDA 和 SCL 拉到高电平电阻太大会造成上升沿变慢电阻太小会加大灌电流。经验值3.3V 系统配 4.7kΩ 到 10kΩ5V 系统配 2.2kΩ 到 4.7kΩ。如果总线上挂了很多设备总线电容增大上拉电阻就要适当减小。快速模式 400kHz 的典型上升沿时间要求是 300ns你可以用阻值乘以总线等效电容来估算RC 时间常数越接近 1/3 的上升沿时间越稳。我在实际调试中常干的一件事是直接拿示波器探针测 SCL 的上升沿如果上升沿慢得像个梯形第一反应就是上拉电阻太大。在 OpenHarmony 的开发板上I2C 引脚可能已经被板级设计接好了上拉电阻但如果你是通过排线外接传感器模块很多时候模块上自带 10k 上拉板子上的上拉也在两个并联后就变成 5k 左右这种经验值是允许的。真正怕的是某些模块上完全没有上拉而开发板的 I2C 引脚恰好没有内部上拉那就等着通信失败吧。2. OpenHarmony 侧 I2C 接入驱动框架与 API 调用链路2.1 HDF 框架下的 I2C 平台驱动OpenHarmony 的设备驱动主要跑在 HDFHardware Driver Foundation框架之上。HDF 把驱动分成几个层次平台驱动由 SoC 厂商负责实现管理 I2C 控制器硬件外设驱动是你自己要写的管理具体的传感器、EEPROM 等设备。两者之间通过 HDF 提供的接口通信这样 SoC 换了你的外设驱动不用大改。I2C 控制器在 OpenHarmony 里一般按编号区分比如 I2C 0、I2C 1、I2C 2每个控制器对应一条物理总线也可能通过复用扩展出多条。当你写外设驱动时你在配置文件里指定总线号、从机地址、通信速率等参数。HDF 的 match 机制会把你的外设驱动绑定到对应的 I2C 控制器驱动上。这里有个常见的认知偏差有人以为 OpenHarmony 里操作 I2C 就像在 Linux 用户态一样open(/dev/i2c-x)然后用 ioctl 发消息。那是在传统 Linux 环境下的玩法。OpenHarmony 标准系统里如果走 HDF通常是你自己的 HDF 驱动通过平台接口去和 I2C 控制器交互。当然OpenHarmony 也有类似 i2c-tools 的能力可以把 I2C 设备抽象成某个节点但从驱动开发的角度核心还是 HDF 外设驱动 I2C 平台接口这套组合。2.2 核心接口的使用逻辑HDF 的外设驱动要操作 I2C思路大概是下面这四步第一步在 HDF 驱动初始化时获取 I2C 控制器的句柄。你可以通过 HDF 的设备管理接口按照你在配置文件中声明的总线号和设备名去获取对应服务。代码看起来像这样#include hdf_io_device.h #include i2c_if.h static struct I2cDevice *i2c_dev NULL; int32_t MySensorInit(void) { // 第一个参数是总线号第二个是设备地址7位 i2c_dev I2cOpen(0, 0x68); if (i2c_dev NULL) { HILOG_ERROR(I2cOpen failed); return HDF_FAILURE; } return HDF_SUCCESS; }第二步配置通信参数。部分平台驱动支持配置传输速率、地址位宽等信息。如果平台驱动默认配置就能满足需求这一步也可以跳过。第三步核心操作发送数据、接收数据、或者一次组合传输。I2C 的读取通常是“先写寄存器地址再读数据”这两个操作要组合在一次传输里完成才能保证总线上没有其他设备插入操作。HDF 的 I2C 接口一般会提供一个消息列表式的接口让你把多个 I2C 消息组合起来一次完成复合操作。// 组合操作先向设备写入寄存器地址 0x3B再读取 6 字节数据 uint8_t reg_addr 0x3B; uint8_t buffer[6] {0}; struct I2cMsg msgs[2]; msgs[0].addr 0x68; msgs[0].flags 0; // 0 表示写 msgs[0].len 1; msgs[0].buf reg_addr; msgs[1].addr 0x68; msgs[1].flags I2C_FLAG_READ; // 读标志 msgs[1].len 6; msgs[1].buf buffer; int32_t ret I2cTransfer(i2c_dev, msgs, 2); if (ret ! 2) { HILOG_ERROR(I2cTransfer failed, ret%d, ret); return HDF_FAILURE; }这里有几个细节值得注意。第一ret的返回值表示成功传输的消息条数不是字节数。你发了 2 条消息返回 2 才是全部成功返回 1 说明第二条读消息失败了返回负数说明更底层的错误。第二addr填的是 7 位地址不要左移一位也不要拼上读写位。这个问题我在别处见过一堆人栽跟头因为传统 i2c-dev 的 ioctl 里地址是 8 位的被左移过的但 HDF 接口一般要求 7 位原始地址。第三读操作和写操作的组合顺序很关键你写的就是从机寄存器地址所以必须先写再读这个顺序不能反。第四步使用结束后释放句柄跟其他资源一样I2cOpen和I2cClose要成对出现。驱动卸载时别漏了。2.3 内核态和用户态的取舍OpenHarmony 上做 I2C 开发你还会面临一个选择把逻辑放内核态驱动还是放用户态服务两者各有适用场景我按实际项目经验给你一个参考场景推荐方案原因需要极高的可靠性和实时性比如 IMU 数据采集、电机控制反馈内核态 HDF 平台驱动减少用户态到内核态的切换开销响应更稳定业务逻辑复杂、需要频繁改策略比如环境传感器周期性上报用户态服务 HDF 用户态接口开发效率高崩溃不影响系统稳定系统已经有标准 HDF 驱动封装只需要上层调用优先沿用已有封装无需重复造轮子对于多数 OpenHarmony 项目我不建议一上来就在内核态写一堆业务逻辑。内核态驱动负责和硬件打交道把数据往上送业务逻辑放用户态好调试、好迭代。I2C 本身速率不高大多数传感器产品的数据量也很小用户态多一次 IPC 的开销完全不是瓶颈反而是内核态代码写错了直接拉起 Kernel Panic调试成本高得多。3. 实战给开发板接一颗 I2C 外设从配置到读数这一部分我们走一遍完整流程。我拿一个常见的 EEPROM比如 AT24C02和一个数字温湿度传感器比如 SHT30做例子因为这两种设备都是典型的小型 I2C 从机时序要求明确各家的实现也差不多。你只要照着这个流程走换什么外设都是同样的套路。3.1 电路连接和引脚确认先说硬件。从机设备需要 4 个引脚VCC、GND、SDA、SCL有的还有地址选择引脚A0/A1/A2和写保护引脚WP。连接的时候注意三点VCC 和 GND 要共地。这个听起来像废话但外接模块供电没和开发板共地的话SDA/SCL 的高低电平没有一个统一的参考点通信必然失败而且失败得很随机。SDA 和 SCL 要接到开发板上真正的 I2C 引脚不是随便找两个 GPIO。OpenHarmony 标准系统的 SoC 通常有专门的 I2C 引脚复用功能你得查板级配置确定引脚被配置为 I2C 功能而不是 GPIO。上拉电阻确认好。开发板原理图上标着有上拉但实际板卡由于版本差异可能会有改动最好万用表量一下SDA 到 VCC 之间应该有 2k~10k 左右的电阻值。以 SHT30 为例它默认的 7 位地址是 0x44还有一颗可选地址 0x45。接线就是 VCC-3.3V、GND-GND、SCL-I2C0_SCL、SDA-I2C0_SDA标准四线制。3.2 板级配置让引脚变成 I2C在 OpenHarmony 的板级配置中你需要确认 I2C 控制器对应的引脚复用已被配置。这块和具体的开发板、HDF 平台驱动相关但思路是共通的找到板级配置中 I2C 控制器相关的节点确认它没有被 GPIO 等其他功能占用。比如你在调试中发现 I2C 不通可以用hdf相关工具看一下 I2C 设备是否已经注册# 在 OpenHarmony 的 shell 中查看 HDF 设备 hdc shell hidumper -s I2cService # 或查看 /dev 下是否有对应的 I2C 设备节点 hdc shell ls /dev/i2c-*如果系统编译时根本没有使能 I2C 控制器驱动或者引脚被其他外设占了后面代码写得再对也没用。这一步排障时优先级很高。3.3 写一个地址扫描程序外设接好了系统起来了先别急着写驱动先写个 I2C 地址扫描程序看看总线上能不能探测到你的设备。这个思路源自 Linux 的 i2cdetect 工具OpenHarmony 上即使没有现成工具你也可以在自己的 HDF 测试驱动里实现同样的逻辑遍历 0x03~0x77 范围内的地址向每个地址发一个写请求看有没有 ACK。核心逻辑很简单打开 I2C对每个地址发一条 0 字节消息SMBus 风格或者发一个单字节读。有 ACK 返回的地址就被视为有设备int32_t ScanBus(uint32_t busNum) { struct I2cDevice *dev I2cOpen(busNum, 0x00); if (dev NULL) { return HDF_FAILURE; } for (uint16_t addr 0x03; addr 0x77; addr) { struct I2cMsg msg; msg.addr addr; msg.flags 0; // 写方向 msg.len 1; uint8_t buf 0x00; msg.buf buf; int32_t ret I2cTransfer(dev, msg, 1); if (ret 1) { HILOG_INFO(Found device at 0x%02X, addr); } } I2cClose(dev); return HDF_SUCCESS; }这里的一个细节有些设备对单字节写操作不响应但对特定寄存器读会响应。所以扫描不到不一定说明设备不在总线上也可能设备比较“挑食”。不过对绝大多数从机来说一字节写是能收到 ACK 的你可以先用这个扫一遍心里有个底。3.4 读寄存器和校验数据扫到地址之后就是正式的读写了。继续用 SHT30 举例我们要读取它的温度数据。SHT30 的过 程是主机发送一条“软复位”命令或者“测量命令”等待测量完成后主机读取 6 字节数据温度 2 字节 CRC 1 字节 湿度 2 字节 CRC 1 字节。代码逻辑用 HDF 接口来实现就是两条消息的组合先写命令0x24 0x00 表示周期测量模式延时一小段时间再发起一次读 6 字节的传输uint8_t cmd[2] {0x24, 0x00}; struct I2cMsg writeCmd; writeCmd.addr 0x44; writeCmd.flags 0; writeCmd.len 2; writeCmd.buf cmd; struct I2cMsg readData; uint8_t data[6] {0}; readData.addr 0x44; readData.flags I2C_FLAG_READ; readData.len 6; readData.buf data; // 先写命令 struct I2cMsg msgs[1] {writeCmd}; if (I2cTransfer(dev, msgs, 1) ! 1) { // 错误处理 } OsDelay(10000); // 等待测量完成单位是 tick需根据系统配置换算 // 再读数据 struct I2cMsg msgs2[1] {readData}; if (I2cTransfer(dev, msgs2, 1) ! 1) { // 错误处理 } // 数据解析SHT30 返回的原始温度值换算 uint16_t rawTemp (data[0] 8) | data[1]; float temp -45.0f 175.0f * (rawTemp / 65535.0f);这里做个小提醒I2C 传送的数据是大端序多字节数据一般是高字节在前。你读到的data[0]是高位字节data[1]是低位字节别倒过来算。换算公式各传感器手册都有照着手册来就行。4. I2C 排障方法论五类高频故障的定位顺序排障是最考验经验的部分。I2C 的故障现象来来回回就那么几种但背后的原因千奇百怪。我总结了一套排查顺序你按这个顺序查至少能排除 80% 的问题。4.1 故障现象和直接原因先给你一张对照表遇到现象直接定位方向现象最可能原因建议排查手段地址扫描不到任何设备共地问题、上拉电阻缺失、引脚复用错误、总线未使能万用表量电平、查板级配置、确认 HDF 设备节点扫描到了地址但读寄存器超时从机电源不稳、SCL 频率过高、从机处于休眠状态降速到 100kHz、检查从机供电时序、确认唤醒引脚读到数据全是 0xFF 或全 0x00上拉电阻问题全 FF 多为 SDA 悬空、地址错误、寄存器地址没写对测 SCL/SDA 静态电平、逐字节打印传输过程数据读到一半出错偶尔好偶尔坏时序竞争、中断影响、总线电容过大抓波形、排查中断优先级、减小上拉电阻总线挂死SDA 被拉低无法释放从机进入了异常状态、主机未正确释放总线、总线上有设备吐数据给从机断电重启、检查起始/停止条件是否完整4.2 从代码到波形的三级排查法遇到问题先别慌按三个层次逐级排查第一级代码层。检查参数总线号对不对设备地址填对没有flags 是否正确transfer 返回值是什么有时候问题就出在你自己写的代码上比如把 7 位地址左移了一位导致地址阶段一直 NACK。返回值为负数时HDF 平台驱动的错误码也能提供线索比如ENODEV可能是 I2C 控制器没有打开EBUSY可能是总线正被其他设备占用。第二级系统层。用设备节点、日志、HDF 调试接口确认系统侧的 I2C 状态。比如用hidumper查看 I2C 控制器的注册信息确认平台驱动已经正确枚举了这条总线。同时检查 dmesg 里有没有 I2C 相关的错误打印。很多问题在系统层就能发现比如引脚复用冲突I2C 引脚被另一个驱动申请成了 GPIO 功能这在日志里通常有线索。第三级波形层。用逻辑分析仪或者示波器抓 SCL 和 SDA 的实际波形。这一级能做出最终的判决。逻辑分析仪建议买 24MHz 起步的抓 I2C 足够用了。不一定要多贵的设备我用过的 200 块钱左右的 8 通道逻辑分析仪配合 sigrok 就干过不少活。接线时把两个探头夹到 SCL 和 SDA 上触发条件设成下降沿然后启动你要测试的程序抓到一帧完整的通信波形。4.3 怎么看抓到的波形拿到波形之后按下面的顺序依次检查看有没有起始条件。波形最开始应该是 SCL 高电平期间 SDA 出现一个下降沿。如果程序跑了但总线上啥也没有说明代码根本没发起传输问题在主控侧。看地址字节对不对。SCL 第 1 个到第 7 个上升沿之间SDA 的电平组合就是地址。对照你填写的地址确认硬件上发的和代码里填的一致。特别注意字节序高位在前。看 ACK 位。第 9 个时钟周期 SDA 是否被拉低。如果拉低了说明从机应答了链路是通的如果没有说明地址不对或者从机没上电。看数据字节。按照每字节 8 位 ACK 的节奏把数据一个个解出来对照你期望写入的寄存器值。这里最容易发现“写命令没执行”、“寄存器地址偏移一位”这类问题。看停止条件。传输结束应该有一个 SCL 高电平期间 SDA 上升沿。如果停在了半路总线会一直处于占用状态下一次传输就可能失败。我在项目里遇到过一次很典型的情况代码逻辑完全正确但逻辑分析仪上第一个字节的地址总是变成 0xD1 而不是 0xD0。后来发现是 GPIO 模拟 I2C 的驱动里字节传输的第一位没有正确驱动 SDA导致最高位丢失。这类问题光看代码是看不出来的波形一抓就现形。5. 一个真实“幽灵总线”问题从头到尾的排查过程这一部分我想给你完整复盘一次我遇到过的 I2C 疑难杂症。这种问题现象不固定、复现率低、网上也搜不到现成答案非常折磨人。把它写出来是希望你能建立一套自己的排查直觉。5.1 现象设备偶尔丢失重启后恢复产品是一个带温湿度传感器和 EEPROM 的 OpenHarmony 设备。正常跑着没问题但只要系统一开机或者在某个特定时间点传感器读数会突然变成 0xFFFF再往后就一直失败直到重启系统才恢复。一开始我以为是驱动代码的并发问题。因为系统里多个任务会同时访问 I2C 总线一个任务周期性读传感器另一个任务偶尔写 EEPROM。如果两个任务没有正确同步消息可能交错导致从机进入不可预期状态。我把驱动里的 I2C 操作加上了互斥锁满心期待地跑了一个晚上结果问题照样出现。5.2 第一轮排查怀疑驱动和并发既然问题还在我就开始怀疑是不是读写操作本身破坏了从机的状态机。我把驱动的日志打开在每次 transfer 前后都打印时间戳和参数。结果发现每次传感器出错之前都会发生一次 EEPROM 写入操作。这进一步强化了并发冲突的猜测但我加了锁之后问题还在那要么是锁没加全有其他路径绕过锁要么根本不是并发问题。既然代码层已经查不出啥我开始查电气层。我量了 SCL 和 SDA 的静态电平总线空闲时都是 3.3V正常。然后用示波器长时间抓波形终于在一次故障发生时抓到了关键证据SDA 被永久拉低SCL 还能正常翻转但 SDA 始终是低电平总线进入了挂死状态。5.3 第二轮排查抓到总线挂死波形SDA 被拉低并且无法恢复这很典型地说明总线上某个设备进入了异常状态一直占用着 SDA。正常情况下主机发出停止条件后 SDA 应该释放为高。但此时 SDA 被某个从机死拽着谁来传输都会失败。我当时的第一个想法是某个从机收到了不合法的数据触发了内部异常把 SDA 锁死了。这在我之前用过的某颗 EEPROM 上看过——如果 WP 引脚电平不稳定EEPROM 在写入过程中断电内部状态机会卡住SDA 就死锁了。我开始排查 EEPROM 的 WP 引脚。结果发现电路设计上这个引脚的驱动是由主控的另一个 GPIO 负责的而那个 GPIO 在某个初始化步骤里被复用成了其他功能导致 WP 电平在高阻和低电平之间漂移。EEPROM 在写入中途失去写保护又恰好在那个时刻总线有干扰就把自己的内部状态机搞乱了SDA 拉死不松手。5.4 根因与修复从机锁死背后的连锁反应修复分两步第一步是应急让设备能自动恢复——驱动里增加总线恢复逻辑当检测到 SDA 长时间为低时对 SCL 连续翻转 9 个时钟周期让锁死的从机退出异常状态这个技巧在很多现代主控的 I2C 控制器里都有内置。第二步是治本把 GPIO 复用配置修正确保 WP 引脚上电后始终保持确定电平不允许被复用。经过这轮处理问题彻底消失。这个案例给我最大的启发是I2C 排障不能只看一层。第一次失败是因为并发猜测第二次成功是因为抓到了波形但根本原因却是一个 GPIO 复用配置。如果你问我排障最有用的能力是什么我会说是“多准备几个排查维度”代码逻辑查完查系统配置系统配置查完查电路电气特性电气特性查完再回到代码。循环往复总能找到答案。5.5 这类问题的通用解法根据这次经验后来我遇到 I2C 总线挂死直接按下面这套走确认是不是真的挂死用示波器或万用表测 SDA 静态电平如果总线空闲时是低电平 0.2V 以下基本是挂死了。能断电就断电给疑似异常从机断电几秒再恢复看 SDA 是否释放。如果释放了说明就是那台设备锁死了。代码层补救I2C 控制器如果支持总线清零BUS CLEAR特性驱动程序里加上。不支持就在 GPIO 层面手动翻转 SCL 来触发从机复位。防患于未然检查每台从机的电源、复位引脚、写保护引脚确保上电时序正确主机和从机之间的时序冲突尽量在驱动里用锁和超时机制兜住。注意手动翻转 SCL 来解锁总线只适用于从机被异常状态卡住的情况而且翻转前一定要确保 SDA 已经被释放否则反而可能制造出意外的起始/停止条件让问题更复杂。我个人在实际操作中的体会是I2C 排障九成靠思路清晰一成靠运气。别被“疑难杂症”吓住按代码、系统、波形三个层次一步步走绝大多数问题都会在某个层次上露出马脚。最后再分享一个小技巧如果你经常跟 I2C 打交道逻辑分析仪一定要备一个而且抓波形的时候不要只抓一帧多抓几帧把故障前后的波形都录下来对比着看很多“偶发”问题其实藏在你没注意的那一两个时钟周期里。
