1. 从一次“挂死”说起：为什么我们要认真学I2C总线的门道

做OpenHarmony系统开发，尤其是涉及外设接入和驱动适配时，I2C总线是个怎么也绕不过去的坎。无论你是接一颗触摸屏控制IC、一颗温湿度传感器，还是读写一块EEPROM存储数据，底层走的十有八九是这个两条线的协议。我在实际项目中见过太多年轻的开发者，拿着官方的传感器例程，改改I2C地址就以为万事大吉，结果上板之后要么读回来的数据全是0xFF，要么总线直接卡死、连带着整颗主控都被“拖下水”。回头排查的时候，因为不了解I2C的工作机制和设备模型，只能东查西查，最后浪费了整整一个下午。

这篇文章不是给你背寄存器手册的，我想用实际项目里“踩坑”和“填坑”的经历，把OpenHarmony下的I2C总线怎么用、怎么排障这件事讲透。适合刚接触鸿蒙驱动开发、被I2C通信搞到头大的人，也适合已经把外设调通、但还想搞清楚底层原理和HDF框架来龙去脉的朋友。看完之后，你至少能回答三个问题：I2C总线在OpenHarmony里是怎么抽象出来的？用户态和驱动态分别怎么操作I2C？板子上的设备不出数、乱出数时，按什么顺序排查最有效？

很多人对I2C的认知停留在“SDA和SCL两根线、设备地址7位”这个层面，这远远不够。尤其在OpenHarmony这种面向万物互联的系统里，I2C的使用深度直接决定了设备的稳定性与开发效率。我们团队在开发一款带多路传感器的数据采集模组时，主控通过三路I2C外挂了十几个设备，如果没有一套清晰的操作和排障思路，单是定位“哪一路总线上的哪个设备丢了应答”就能让人崩溃。

先打个比方帮助理解I2C总线的工作方式：它就像一个公司内部的沟通机制——一条线传数据（相当于员工说话的内容），一条线传时钟（相当于会议主持人喊“大家注意，翻页了”）。公司里每个人有一个工号（设备地址），主持人点谁的名，谁就有资格发言。I2C的通信哲学就是这么朴素，但正是这份朴素，给我们在工程实践中留下了许多需要注意的细节。

2. 打开I2C应用的正确姿势：从协议栈到OpenHarmony抽象

2.1 协议级别的基本功：时序、速率、地址——这些坑是你绕不开的第一层

如果说写应用代码是“开车”，那么理解I2C时序就是“学交规”。在OpenHarmony里做I2C开发，你可以不用自己手写时序翻转GPIO（那是单片机裸机开发的玩法），但你得知道驱动框架帮我们封装了什么、底层在做什么，不然出了问题你还是无从下手。

I2C协议有两个最关键的物理事实：第一，它是半双工的，同一时刻数据只能往一个方向流；第二，SDA数据线的变化必须发生在SCL时钟线为低电平的时候，否则就会被识别为“起始”或“停止”信号。这两个事实决定了所有I2C设备的数据手册上都有那么一张让人头疼的时序图——而这张图，恰恰是排查问题的根本依据。

速率方面，I2C分为标准模式100Kbps、快速模式400Kbps和高速模式3.4Mbps。在OpenHarmony的HDF（HardwareDriverFoundation，硬件驱动框架）配置里，我们通常根据外设数据手册的要求来设定时钟频率。这里有一个经验：不要把频率往高里拉，够用就行。我曾经为了加快一批光学传感器的采样率，把I2C频率从400K拉到了1M，结果数据错误率陡增，排查半天发现是板子上拉电阻和总线电容不匹配，信号边沿变形导致的。降回400K之后，一切正常，采样率其实也没慢多少。

地址这块，I2C设备有7位和10位两种寻址模式，但99%的传感器都是7位地址。注意，数据手册上给你的地址往往是一个8位字节，比如“0xA0”，这实际上已经把读/写位（最低位）算进去了。所以你在驱动代码里写的设备地址往往要右移一位，写成0x50。这个经典错误，几乎是每个新手入坑I2C都会碰到的，包括我自己当年也在这上面栽过跟头——总线上挂着两个器件，逻辑分析仪抓波形发现地址字节发出去就是和手册对不上，查了一上午才发现是地址位宽理解错了。

2.2 OpenHarmony给I2C上了一层什么“壳”：HDF框架下的I2C模块架构

OpenHarmony的驱动开发与传统嵌入式最大的不同，就是引入了HDF驱动框架。它把设备驱动从“裸奔”的内核代码变成了一个“可管理、可配置、可移植”的标准化模块。具体到I2C，HDF框架会为每一条I2C总线抽象出一个控制器设备，并注册到驱动管理器中。当你的外设驱动需要操作I2C传输数据时，走的流程是：外设驱动 -> HDF I2C模块 -> I2C控制器驱动 -> 底层硬件寄存器。

这套层次带来的直接好处是什么呢？是标准化。你在A芯片平台上写的I2C传感器驱动，换到B芯片平台上，只要B平台也适配了HDF的I2C控制器驱动，应用层驱动代码几乎不用改。这对于“万物智能”的愿景来说太重要了——毕竟OpenHarmony要跑在那么多不同厂商的芯片上，没有一套统一抽象，每个芯片一套API，开发者早就被逼疯了。

从代码实现角度来看，HDF里I2C设备管理主要涉及几个关键结构体。一个是I2cCntlr，它代表一个I2C控制器，里面有ops指针，指向实际的总线操作方法集。另一个是I2cMsg，它描述了一次传输的数据内容：设备地址、缓冲区指针、数据长度和传输标志（读还是写）。这个I2cMsg结构体是贯穿整个I2C操作的核心——它有点像一个快递单，上面写着收件人（设备寄存器地址）、包裹内容（要发的数据）和拿取方式（是放进去还是取出来）。

在配置层面，HDF使用.hcs（HDF Configuration Source）配置文件来描述硬件资源。在OpenHarmony的开发板适配中，我们需要在配置文件中把I2C控制器的编号、基地址、时钟频率、中断号等信息配置好。这个配置文件如果你写不准确，后续驱动加载阶段就会直接失败，常见报错会是“failed to get I2C controller”之类的。所以我一直建议团队里新来的同学，先把.hcs里I2C节点配置烂熟于心——这是你在OpenHarmony里使用I2C的第一道门禁。

2.3 用户态API vs HDI接口：两条路怎么选

在OpenHarmony里，普通应用想访问I2C设备有两种方式。一种是走HDI（Hardware Device Interface，硬件设备接口）层，系统会提供统一的I2C HDI接口，比如I2cTransfer等函数，通过服务管理器获取设备服务后直接读写总线。另一种是底层驱动开发时，直接在HDF驱动内部调用I2cTransfer这类底层运算符的API。

这两者的区别，我用一个类比来说：如果说HDI接口是对外开放的“客户接待窗口”，那HDF驱动的内部API就是“后台办公区”。普通应用程序员不会也不应该直接访问后台——这会打乱系统的权限管理和安全机制。正确的做法是，系统服务层封装好HDI接口，应用层通过IDL（Interface Definition Language）生成的代理来调用。这样做既能实现权限管控，又能让设备访问逻辑与业务逻辑解耦。

我遇到不少做应用开发的同事，为了图省事，想跳过系统服务直接操作I2C设备节点，这种思路在OpenHarmony上行不通，也是架构设计上明确不推荐的做法。社区里的一个典型参考是I2C相关的HDI实现仓库，那里面清晰地展示了从服务注册到接口实现的完整链路。如果你打算让你的设备被上层APP控制，那么按HDI的路子走是唯一正解。

3. 手把手实现一个I2C传感器驱动：从HCS配置到上报数据

3.1 环境准备与配置：HCS文件修改的细节决定了成败

先交代一下我实际用的开发环境：OpenHarmony 4.0 Release版本，搭载某国产Cortex-A55架构SoC的评估板，内核是Linux 5.10。下面的操作思路在其他版本的OpenHarmony上大差不差，但是文件路径和接口名可能略有差异，注意以实际SDK为准。

第一步是修改开发板的HCS配置文件。如果你是做标准系统开发，I2C控制器配置一般在device/board/xxx/xxx/device_config/xxx_config.hcs里。配置的核心是把某一个I2C控制器使能，并挂接上外设节点。这里放一个简化的I2C控制器配置片段示例：

i2c_config { i2c0 { controller_num = 0; // I2C控制器编号 bus_reg_base = 0x10020000; // 寄存器基地址 bus_reg_step = 0x1000; // 寄存器地址步进 clock_frequency = 400000; // 总线频率400KHz interrupt = 38; // 中断号 } i2c1 { controller_num = 1; bus_reg_base = 0x10030000; bus_reg_step = 0x1000; clock_frequency = 100000; interrupt = 39; } }

这个配置里有几个关键点需要强调。clock_frequency不是你想写多少就写多少的，它受限于SoC的I2C外设时钟源分频能力和总线上所有设备支持的最高速率。最好查清楚所有外设速率要求的“最小值”，取交集。中断号要跟你使用芯片的datasheet对得上，如果配错，驱动加载时会直接报中断申请失败的日志。

然后还需要在你的外设驱动HCS节点里声明它挂在哪个I2C控制器下。这个挂接关系就类似于你在一个文件系统里把外设“挂载”到总线上：

sensor_xxx { module_name = "sensor_xxx_driver"; i2c_controller = 0; // 挂载到i2c0 i2c_dev_addr = 0x50; // 7位设备地址 i2c_freq = 400000; // 该设备通信速率 }

这里有一个常见陷阱：你在外设节点写的i2c_dev_addr到底是7位地址还是8位地址，取决于你所用HDF版本的I2C操作API怎么处理地址位。大多数底层驱动要求的是7位地址，因为总线协议层面操作时会把地址左移一位并补上读写标志位。如果你按照8位地址写法填了一个奇数，到了总线时序上就全乱套了。

3.2 驱动代码框架搭建：绑定的不是“设备”，而是一整套逻辑

OpenHarmony HDF驱动采用“驱动模型”的思想，一个驱动模块需要在代码中声明一个DriverEntry结构体，并在其中绑定Bind、Init和Release三个函数。这就像你入职一家公司，需要先办理入职手续（Bind阶段绑定设备和驱动），然后参加岗位培训（Init阶段初始化软硬件资源），离职时再办理交接（Release阶段释放资源）。

以我这里要驱动的温度传感器为例，驱动源码结构大概是这样的：

/* sensor_xxx_driver.c */ #include "hdf_device_desc.h" #include "hdf_log.h" #include "i2c_if.h" static int32_t SensorXxxInit(struct HdfDeviceObject *device) { DevHandle handle = NULL; handle = I2cOpen(0); // 打开I2C控制器0 if (handle == NULL) { HDF_LOGE("I2cOpen failed"); return HDF_FAILURE; } g_sensorHandle = handle; /* 后续可以对传感器上电、配置寄存器等 */ HDF_LOGI("SensorI2cInit success"); return HDF_SUCCESS; } static int32_t SensorXxxBind(struct HdfDeviceObject *device) { (void)device; return HDF_SUCCESS; } static void SensorXxxRelease(struct HdfDeviceObject *device) { if (g_sensorHandle != NULL) { I2cClose(g_sensorHandle); g_sensorHandle = NULL; } } struct HdfDriverEntry g_sensorXxxDriverEntry = { .moduleVersion = 1, .moduleName = "sensor_xxx_driver", .Bind = SensorXxxBind, .Init = SensorXxxInit, .Release = SensorXxxRelease, }; HDF_INIT(g_sensorXxxDriverEntry);

在这个框架里，I2cOpen的入参是控制器编号，它和我们在HCS里配置的i2c0对应。如果你只有一个I2C控制器，控制器编号通常从0开始。这里补充一点：I2cOpen拿到的是一个DevHandle句柄，可以把它理解成一个“遥控器”，后续所有的I2C读写都得通过这个遥控器来按按钮。

3.3 数据传输实现：写寄存器、读数据，一次传输和多次传输的恩怨

传感器驱动里最频繁的操作就是：向寄存器地址写配置、从寄存器地址读数据。I2C协议里读操作是一个比较绕的组合动作：先发送起始信号 + 设备地址写位 + 寄存器地址，然后重新发送起始信号 + 设备地址读位，最后读取数据。这个过程在HDF里通常用两个I2cMsg结构体组成的数组来表示。

static int32_t SensorXxxWriteReg(uint8_t regAddr, uint8_t value) { struct I2cMsg msgs[1]; uint8_t buf[2] = {regAddr, value}; msgs[0].addr = SENSOR_I2C_ADDR; // 7位地址 msgs[0].flags = I2C_FLAG_WRITE; // 写标志 msgs[0].len = 2; // 先发寄存器地址，再发数据字节 msgs[0].buf = buf; int32_t status = I2cTransfer(g_sensorHandle, msgs, 1); if (status != 1) { HDF_LOGE("I2cTransfer write failed, status = %d", status); return HDF_FAILURE; } return HDF_SUCCESS; }

读操作要复杂一些，因为要先写寄存器地址，再读数据回来。实际的代码里可能需要两次I2cTransfer调用，或者通过flags字段中的I2C_FLAG_READ配合I2C_FLAG_REPEATED_START构成一次原子性的复合操作。

static int32_t SensorXxxReadReg(uint8_t regAddr, uint8_t *value) { struct I2cMsg msgs[2]; uint8_t regBuf = regAddr; msgs[0].addr = SENSOR_I2C_ADDR; msgs[0].flags = I2C_FLAG_WRITE; msgs[0].len = 1; msgs[0].buf = &regBuf; msgs[1].addr = SENSOR_I2C_ADDR; msgs[1].flags = I2C_FLAG_READ | I2C_FLAG_REPEATED_START; msgs[1].len = 1; msgs[1].buf = value; int32_t status = I2cTransfer(g_sensorHandle, msgs, 2); if (status != 2) { HDF_LOGE("I2cTransfer read failed, status = %d", status); return HDF_FAILURE; } return HDF_SUCCESS; }

这里我想多说一句对I2cTransfer返回值的理解。它返回的是成功传输的消息数量，而不是传输的字节数。如果你传入的是2个I2cMsg，只有全部成功才是2，返回1代表第一条写地址发出去了，但后续操作失败了。不要只看“返回值不等于-1”就认为成功——我在读一个声称返回4字节的寄存器时，就遇到过返回1的情况，日志里看起来没报错，实际数据根本不更新。

另外，关于I2C_FLAG_REPEATED_START这个标志，值得展开讲一下。为什么读寄存器需要“重复起始信号”？因为在I2C协议里，一次完整的传输以“停止信号”终结。如果读寄存器时不做重复起始，而是直接发停止再重新启动，那中间就会有一个总线释放的空窗期。在这期间，如果总线上有其他主设备（听起来不可思议，但多主场景确实存在），可能会抢占总线，导致你的读写操作被拆得七零八落。所以规范的做法是使用重复起始信号，把“指定寄存器地址”和“读取数据”捆绑成一个不可分割的原子操作，同理，写入操作也应该在一个消息序列内完成，避免中间被其他设备插足。

我见过很多人在裸机开发的时候对这个细节不以为意，到了带操作系统的环境里就踩坑。在OpenHarmony这种多任务环境下，I2C总线是有可能被不同驱动共享的，而这些驱动可能运行在不同的线程上下文中。如果对“原子性”没有敬畏，数据竞争和总线错乱只是时间问题。所以请记住：往总线上发送的每一个消息序列，都要尽量做到“在一个事务里完成”。HDF的I2cTransfer允许一次传递多个消息，这个能力就是为此设计的。

在实际测试中，我还发现有些传感器芯片要求写入配置后有一个稳定的延时，超过10毫秒甚至20毫秒才能完成内部校准。这种时候，你的驱动里应在写完寄存器后适当等待，而不是立刻发起读操作。否则读出的是芯片上一次的旧数据或全0，让你误以为是I2C总线出了问题。总线的原理再正确，也要结合器件的物理特性来综合判断。

4. 排障实录：市面上看不到的I2C问题排查经验

4.1 第一现场：用逻辑分析仪和Shell命令锁定故障源

排障这个话题，我一般不建议开发者在代码里瞎加打印碰运气。最高效的方式是“多管齐下”：观察内核日志、测量物理信号、拆解协议内容。在OpenHarmony环境里，你可以通过hdc shell进入系统的命令行，然后使用一些底层的调试工具来查看I2C总线状态。比如在Linux内核下，/sys/bus/i2c/devices/目录会列出当前注册在总线上的I2C设备。你可以查看这个目录下的信息，第一波判断驱动和设备的挂载关系是否正常。

但判断物理层面的问题，必须借助示波器或逻辑分析仪。这里也分享一个我自己的设备选型建议：如果你经常和I2C打交道，买一个几十块钱的8通道逻辑分析仪，搭配开源的sigrok软件或厂商配套上位机，抓I2C波形完全够用，比上万块钱的示波器在协议解码这个维度上更直观。逻辑分析仪的探头一边接SCL，一边接SDA，在系统运行期间抓取通信波形，可以一目了然地看到：总线是否有起始、停止信号？地址字节是否为0xA0？ACK/NACK位是高还是低？数据字节是否和期望值一致？

用逻辑分析仪排查I2C故障有一个原则：先看帧格式有没有错，再看内容对不对。如果帧格式错了，比如地址字节之后没有等来ACK而是一直高电平，那大概率是设备没在位、地址不对或者总线被拉死。如果帧格式正确，ACK也正常，但读出数据不对，那问题往往出在寄存器地址、数据长度、字节序或者设备内部状态等更高层的地方。

为了说明问题，我列一个真实案例。在调试某款六轴惯性传感器时，数据手册上的设备地址写的是0x68，我按7位地址填进去之后，逻辑分析仪抓到总线上出现的地址字节却是0xD0。原来，I2C总线上发送的地址字节，最低位被用作读写标志位，所以7位地址0x68左移一位后是0xD0。理论上这个0xD0正是我们期望的。如果没有逻辑分析仪，你只会盯着代码里的0x68发愣，想不通为什么设备始终无应答。

4.2 经典故障分类：从“总线挂死”到“数据错乱”的应对手册

经验多了之后，我发现I2C故障虽然表象各异，但归类起来就那几大类。我整理了一张排查表，基本可以覆盖绝大多数开发阶段的I2C问题。

在这张表里出现频率最高的是“总线挂死”。I2C是一种漏极开路的通信方式，设备只能把总线拉低，不能主动拉高，高电平全靠上拉电阻。为什么上拉电阻偶尔会失效？大部分原因是板级设计和物料问题。有人把上拉电阻焊错位置，或者漏焊，结果总线静态时悬空，电平不稳定，自然什么也传不了。如果遇到这种问题，你光在软件层面调驱动，永远调不出来。所以排障时不要迷信代码，第一件事就应该拿起万用表，量一量SCL、SDA的对地电压。这两根线静态应该在1.8V或3.3V左右（取决于你的系统电压）。如果量出来只有零点几伏，或者一直在跳，那毫无疑问是硬件问题，跟驱动代码没有半点关系。

还有一种“总线挂死”是协议层面的：我们平时在写驱动时，如果几个I2C消息在一个传输数组中，中间某一个消息出现了NACK，那么整个传输会被底层中止。上层驱动如果没有正确地处理中止状态，会导致总线仲裁状态机混乱。遇到这种情况，最简单的恢复手段是调用I2C控制器的复位接口，或者给设备重新上电。在HDF框架里，这类复位能力一般由SoC的I2C控制器驱动暴露出来，你在自己的外设驱动中要记得处理对应的错误路径。

4.3 实测中最隐蔽的坑：上拉电阻、地址位宽与系统调度的叠加效应

我前面提了两个经典坑，一个是上拉电阻，一个是地址位宽。但实战中让人头皮发麻的是它们叠加起来的场景。有次我们给一款新板子做BringUp，传感器怎么调都稳定不下来，逻辑分析仪显示数据正常，但应用层总是隔几十秒出一笔错数据。排查了供电干扰、软件逻辑，最后定位到是因为I2C的SDA线走线过长，且中途穿过了一块开关电源区域，严重的EMI干扰导致偶发的位错误。后来除了缩短走线布局，还在SDA/SCL上各加了一颗几十欧姆的串联电阻，配合上拉，信号边沿明显变干净了，问题就此解决。这个案例充分说明，I2C虽然协议简单，但在工程现场，它考验的是你对电路、信号和系统的综合理解。

还有一个容易忽略但影响极大的坑，是系统的调度延迟。在设计硬件I2C控制器时，大部分SoC都会内置FIFO缓冲区。如果缓冲区不够大，或者某个时刻系统CPU繁忙，DMA/中断响应不及时，数据传输就可能出现“欠载”或“过载”，导致数据错位。OpenHarmony的HDF I2C模块会尽量使用同步阻塞的方式处理事务，但对于一些需要高频读写的传感器，我们往往会考虑放到独立的中断上下文或增加缓冲区来处理。所以，如果你的I2C设备在某些高负载场景下出现间歇性异常，别急着怀疑I2C协议本身，先想想是不是系统调度让数据“迟到”了。我自己的做法是在驱动代码里加入合理的超时机制，并对高频访问做统计，一旦发现某次传输耗时超过正常值几十倍，就主动复位I2C控制器，而不是默默接受一个可能错误的数据。

4.4 高频问题：OpenHarmony环境下I2C查询与FTF传输现象的关系提示

在OpenHarmony的实际应用场景中，I2C不仅用于控制外设，也可能用于传输实时数据。经常有人拿“I2C传文件”来说事，这其实是对它的误用。I2C本身的设计目标是低速控制、配置和状态读取，它的带宽优势在于实时性好、可靠性高、协议简单，而不是吞吐量大。所以我一般在项目中严格区分用途：传感器配置和状态读取走I2C，大批量数据的传输用SPI或SDIO。如果你硬要用I2C去传音频流或者图像数据，那你很快就会被速度和E2E可靠性问题教做人。

具体到OpenHarmony系统里，I2C访问的中断和DMA资源本身也是由内核统一管理的。驱动开发者要时刻谨记：HDF驱动是运行在操作系统环境下的，不是裸机上的一个while循环。多线程、内存屏障、中断优先级这些东西都会影响I2C通信的稳定性。比如，你的驱动在上层读取传感器数据时，如果是在用户态通过HDI调用，那每一次调用都会经历用户态到内核态的切换，这会带来微秒级的额外延迟和不确定性。在一次高分辨率数据采集的项目里，我们就发现HDI调用的抖动直接影响了传感器数据的时间戳准确性，最终是在内核态做了时间戳记录才解决。所以，如果你追求的是极致的时间确定性，路径设计时就要想清楚：你的I2C传输是在哪个上下文发生的？它和业务逻辑的执行同步关系如何？

在OpenHarmony里还有一个常见的开发困惑：为什么I2C设备驱动已经加载，但/dev/i2c-x节点并不存在？这是因为OpenHarmony标准系统的设备节点管理方式和传统Linux文件系统不太一样。很多设备节点是动态生成的，或者需要上层服务去创建链接。如果你习惯性想用用户态的i2c-tools去读写外设（比如i2cdetect、i2cget这些命令），在标准OpenHarmony版本里通常会因为权限或节点缺失而失败。这种情况下，正确的做法是按HDF/HDI的“正规军”方式，写一个小工具或者通过系统提供的测试程序来访问I2C设备。这也提醒了我们：OpenHarmony不是让你把Linux的玩法原封不动搬过来的，它有自己的驱动架构哲学，你要入乡随俗。

5. 给排障工具箱加点料：经验总结与习惯养成

排障这件事，方法论比天赋更重要。经历了几轮产品迭代之后，我给自己定下几条I2C开发的“军规”，也分享给大家。

第一条，一切以波形为准。软件日志里的错误码往往只能告诉你“出了错”，不能告诉你“为什么错”。逻辑分析仪上SDA和SCL的每一帧波形，是唯一不会说谎的第一现场，说实话，逻辑分析仪的协议解码功能要用得很熟，包括起始条件、停止条件、ACK/NACK、重复起始以及读写标志的判定，这样才能快速跟代码里的每一步操作对应起来。别太依赖逐个打印寄存器值，那些打印本身就可能改写通信的时序。

第二条，先硬件后软件，先静态后动态。硬件问题没有排查清楚之前，不要浪费时间反复编译固件。万用表量供电、量上拉、量电平，示波器看波形，Linux内核日志中找i2c相关报错，按这个顺序走一遍，基本能筛掉90%的问题。动态问题（比如偶发的数据错乱）不要急着看代码逻辑，先想想总线上有多少设备、谁是主、谁是从，甚至想想附近有没有电机或天线在干扰。

第三条，保持最小复现。如果总线上挂了多个设备，出了故障，不要一开始就在复杂场景里找问题。把无关的设备物理摘除，只留故障设备和最少的必要外设，跑一个最简单的读写测试。如果简单场景能复现，问题就在这个设备本身；如果不能复现，就要考虑设备和设备之间的互动——地址冲突、总线仲裁、主设备负载等。这个习惯帮我省了无数个“加班到深夜”的夜晚。

OpenHarmony的I2C驱动开发，说到底就是一场和“细节”的较量。千万不能因为它只有两根线就掉以轻心——它连接的是复杂的芯片逻辑和物理世界，把这两根线搞明白了，你会发现其它总线（SPI、UART、I2S）的学习成本也一下子降下来了。希望这篇文章里的思路和排障表格，能让你在下次面对“为什么我的I2C设备没反应”的时候，多几分笃定，少几分慌张。

我在实际中还有一个怪癖：每次新板子回来，都会翻出仓库里的I2C测试驱动，针对每一路总线挂上所有外设跑一遍回环检测。这个动作看似笨拙，却让很多潜在问题在项目早期就暴露出来。你永远不知道下一块板子的走线会不会给你挖一个大坑，提前知道，总比进了终端客户手里再来返修强得多。