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的HDFHardwareDriverFoundation硬件驱动框架配置里我们通常根据外设数据手册的要求来设定时钟频率。这里有一个经验不要把频率往高里拉够用就行。我曾经为了加快一批光学传感器的采样率把I2C频率从400K拉到了1M结果数据错误率陡增排查半天发现是板子上拉电阻和总线电容不匹配信号边沿变形导致的。降回400K之后一切正常采样率其实也没慢多少。地址这块I2C设备有7位和10位两种寻址模式但99%的传感器都是7位地址。注意数据手册上给你的地址往往是一个8位字节比如“0xA0”这实际上已经把读/写位最低位算进去了。所以你在驱动代码里写的设备地址往往要右移一位写成0x50。这个经典错误几乎是每个新手入坑I2C都会碰到的包括我自己当年也在这上面栽过跟头——总线上挂着两个器件逻辑分析仪抓波形发现地址字节发出去就是和手册对不上查了一上午才发现是地址位宽理解错了。2.2 OpenHarmony给I2C上了一层什么“壳”HDF框架下的I2C模块架构OpenHarmony的驱动开发与传统嵌入式最大的不同就是引入了HDF驱动框架。它把设备驱动从“裸奔”的内核代码变成了一个“可管理、可配置、可移植”的标准化模块。具体到I2CHDF框架会为每一条I2C总线抽象出一个控制器设备并注册到驱动管理器中。当你的外设驱动需要操作I2C传输数据时走的流程是外设驱动 - HDF I2C模块 - I2C控制器驱动 - 底层硬件寄存器。这套层次带来的直接好处是什么呢是标准化。你在A芯片平台上写的I2C传感器驱动换到B芯片平台上只要B平台也适配了HDF的I2C控制器驱动应用层驱动代码几乎不用改。这对于“万物智能”的愿景来说太重要了——毕竟OpenHarmony要跑在那么多不同厂商的芯片上没有一套统一抽象每个芯片一套API开发者早就被逼疯了。从代码实现角度来看HDF里I2C设备管理主要涉及几个关键结构体。一个是I2cCntlr它代表一个I2C控制器里面有ops指针指向实际的总线操作方法集。另一个是I2cMsg它描述了一次传输的数据内容设备地址、缓冲区指针、数据长度和传输标志读还是写。这个I2cMsg结构体是贯穿整个I2C操作的核心——它有点像一个快递单上面写着收件人设备寄存器地址、包裹内容要发的数据和拿取方式是放进去还是取出来。在配置层面HDF使用.hcsHDF Configuration Source配置文件来描述硬件资源。在OpenHarmony的开发板适配中我们需要在配置文件中把I2C控制器的编号、基地址、时钟频率、中断号等信息配置好。这个配置文件如果你写不准确后续驱动加载阶段就会直接失败常见报错会是“failed to get I2C controller”之类的。所以我一直建议团队里新来的同学先把.hcs里I2C节点配置烂熟于心——这是你在OpenHarmony里使用I2C的第一道门禁。2.3 用户态API vs HDI接口两条路怎么选在OpenHarmony里普通应用想访问I2C设备有两种方式。一种是走HDIHardware Device Interface硬件设备接口层系统会提供统一的I2C HDI接口比如I2cTransfer等函数通过服务管理器获取设备服务后直接读写总线。另一种是底层驱动开发时直接在HDF驱动内部调用I2cTransfer这类底层运算符的API。这两者的区别我用一个类比来说如果说HDI接口是对外开放的“客户接待窗口”那HDF驱动的内部API就是“后台办公区”。普通应用程序员不会也不应该直接访问后台——这会打乱系统的权限管理和安全机制。正确的做法是系统服务层封装好HDI接口应用层通过IDLInterface 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在系统运行期间抓取通信波形可以一目了然地看到总线是否有起始、停止信号地址字节是否为0xA0ACK/NACK位是高还是低数据字节是否和期望值一致用逻辑分析仪排查I2C故障有一个原则先看帧格式有没有错再看内容对不对。如果帧格式错了比如地址字节之后没有等来ACK而是一直高电平那大概率是设备没在位、地址不对或者总线被拉死。如果帧格式正确ACK也正常但读出数据不对那问题往往出在寄存器地址、数据长度、字节序或者设备内部状态等更高层的地方。为了说明问题我列一个真实案例。在调试某款六轴惯性传感器时数据手册上的设备地址写的是0x68我按7位地址填进去之后逻辑分析仪抓到总线上出现的地址字节却是0xD0。原来I2C总线上发送的地址字节最低位被用作读写标志位所以7位地址0x68左移一位后是0xD0。理论上这个0xD0正是我们期望的。如果没有逻辑分析仪你只会盯着代码里的0x68发愣想不通为什么设备始终无应答。4.2 经典故障分类从“总线挂死”到“数据错乱”的应对手册经验多了之后我发现I2C故障虽然表象各异但归类起来就那几大类。我整理了一张排查表基本可以覆盖绝大多数开发阶段的I2C问题。故障现象可能原因排查步骤与解决思路设备完全无应答总是NACK设备地址错误设备未上电上拉电阻缺失或失效总线接错引脚先查设备供电用万用表量SDA和SCL静态电平正常时都应为高核对7位地址换算关系示波器查波形有无起始条件总线一直为低电平发送失败SDA或SCL被设备拉死I2C总线死锁片选或中断引脚冲突复位所有设备检查板级设计是否有总线电容过大导致低电平无法释放临时去掉异常设备逐个排除能读写但数据偶尔出错速率过高、信号完整性问题电源噪声总线过长或走线不规范降低I2C频率通常降到100K或400K检查电源纹波必要时在传感器电源端加100nF电容检查SDA/SCL走线是否远离时钟线和高频信号线时序正确但读回数据全是0xFF设备处于复位状态寄存器地址不对上电时序不满足确认芯片上电时序如延时等待逐寄存器读取并对照手册默认值检查芯片的复位引脚是否被拉低多个设备互相干扰地址冲突总线上设备过多导致信号质量差确认每个设备地址是否唯一增加总线隔离芯片或使用I2C开关如TCA9548A来分组管理在这张表里出现频率最高的是“总线挂死”。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测试驱动针对每一路总线挂上所有外设跑一遍回环检测。这个动作看似笨拙却让很多潜在问题在项目早期就暴露出来。你永远不知道下一块板子的走线会不会给你挖一个大坑提前知道总比进了终端客户手里再来返修强得多。
