做OpenHarmony设备开发，从传感器、屏幕到各种外设，八成会遇到I2C。尤其是你想在开发板上接个环境光传感器、姿态传感器的时候，跑一版I2C驱动，反复读不到数据、偶尔死锁、时序不稳，这种问题我想不少人都遇到过。这篇内容我想把I2C总线在OpenHarmony下的开发与排障经验完整捋一遍——协议原理怎么理解，HDI怎么写，以及最容易被忽略的排障手段（比如自己用GPIO模拟一个主机来抓从机）。不分基础，只要你有块板子、有示波器或者逻辑分析仪，这篇文章都能给你实实在在的参考。
1. 项目概述与需求拆解
1.1 为什么I2C是外设驱动开发绕不开的坎
先说个结论：I2C总线的地位，在IoT设备里相当于宿舍楼里的水管——每个房间都要用，看起来简单，一旦堵了，整栋楼都会遭殃。
OpenHarmony现在主攻的领域是智能家居、物联网网关、开发板生态，这类设备上最常见的外设就是传感器、屏幕、触摸屏、IO扩展芯片、EEPROM、RTC时钟。这些芯片的通信接口里，I2C和SPI各占半壁江山。尤其传感器，10颗里有8颗是I2C接口。所以学OpenHarmony驱动，I2C基本是必修课。
但它又是个特别容易出幺蛾子的总线。两根线、一个地址、一堆时序参数，看着简单，把通信波形拉出来一看，各种微妙的问题就藏不住了。这篇教程就是想解决"怎么用、怎么查、怎么排"这三个问题，把从应用层到物理层的链路打开揉碎。
1.2 教程在OpenHarmony实战体系中的位置
OpenHarmony的驱动框架目前是HDF（Hardware Driver Foundation），上层应用通过HDI（Hardware Driver Interface）来调用硬件能力。I2C作为HDI里的一个基础服务模块，链路是：
应用层 -> HDI接口 -> HDF框架映射 -> I2C控制器驱动 -> 物理总线 -> 从设备芯片
这条链路里，任何一个环节出了问题，最终表现都一样：读写失败。所以排障的关键是先定位层级，再逐层排查。这篇教程会按照"协议层、驱动层、物理层"三个维度展开，前面先把I2C协议理顺，中间讲OpenHarmony下的HDI调用方法，后半段全部是实战排障手段和案例。
2. I2C总线核心原理精讲：从协议层面先搞清楚
2.1 两根线怎么跑出数据流
I2C硬件上就两根线：SDA（数据线）和SCL（时钟线）。SCL由主机控制，负责产生时钟脉冲；SDA负责搬运数据。两根线配合工作的方式，可以类比成两个人配合打字：SCL是节拍器，打一下节拍，SDA线上放一个比特，双方按照这个节奏来同步，每一位数据都在SCL高电平期间被采样。
整个通信流程有一组固定动作：
- 起始条件（START）：SCL保持高电平，SDA由高变低，代表一次传输开始
- 地址帧：主机发送7位从机地址，最后一位是读写标志（0写、1读）
- 应答位（ACK）：从机拉低SDA表示"我在，继续发"
- 数据帧：发送或接收8位数据字节，每个字节后跟一个应答位
- 停止条件（STOP）：SCL保持高电平，SDA由低变高，代表传输结束
这个流程是I2C通信的基础，不管上层用什么驱动框架，最终物理层跑的都是这套时序。很多新手写驱动读不到数据，其实不是代码问题，而是时序逻辑没对上——比如读操作之前漏了写从机寄存器地址这一步，后面会在排障章节具体讲。
2.2 电平标准与上拉电阻的讲究
I2C物理层最大的特点就是开漏输出。主机和从机都不能主动输出高电平，只能把线拉低，高电平全靠外部上拉电阻提供。这就是为什么I2C总线必须接上拉电阻，有的开发板自带的模块不需要你额外接，但那是因为板子上已经画了。
上拉电阻阻值的选择会影响通信质量和速率：
| 总线速率 | 推荐上拉电阻范围 | 说明 |
|---|---|---|
| 100 kbit/s（标准模式） | 4.7k~10k | 最保守，兼容性最好 |
| 400 kbit/s（快速模式） | 2.2k~4.7k | 常用组合 |
| 1 Mbit/s（快速模式+） | 1k~2.2k | 对线路电容要求高 |
电阻太小，灌电流变大，低电平可能拉不到标准值；电阻太大，边沿上升时间变长，高速通信时波形跟不上就会出误码。排查I2C问题时，上拉电阻是第一怀疑对象。我遇到过一块板子SCL波形整体像正弦波，后来发现是上拉电阻焊错成了100k，直接换成4.7k问题消失。
2.3 时序参数不能只靠感觉
I2C的时序参数在芯片手册里有一大堆，比如建立时间、保持时间、上升时间、下降时间。我们的设备驱动里一般不用手写这些参数，因为控制器硬件已经帮你处理了，但排障时你得能看懂波形对不对。
几个关键参数与失败现象的对应关系：
- 起始条件保持时间太短，从机可能完全没识别到传输开始，表现为没有任何ACK
- 数据建立时间不够，从机采到的数据就是错的，表现是读回的数据是0xFF或乱值
- SCL高电平时间太短，从机来不及处理上一位数据，表现是ACK后主机收到NACK
- 停止条件如果是主机主动发起的，之前挂起的从机操作没有完全释放，下一次传输就可能卡死
我自己习惯在排障时把逻辑分析仪的采样率开到8M以上，先看整个通信帧的宏观结构对不对，再放大看每一位。因为很多问题你用万用表量电压是看不出来的，时序问题只有看波形才明显。
2.4 动态地址与多设备共存
I2C设计时为每个从机分配一个7位地址，理论上一条总线可以挂128个设备（实际上地址冲突和总线电容会限制数量）。日常开发里我见到最多的地址冲突场景就是同型号传感器贴了两颗，比如板子上放了两颗MPU6050，默认地址都是0x68，那就只能通过AD0引脚改地址，一颗改成0x69。
还有一类是软件可配地址的芯片，比如IO扩展芯片PCF8574，它的A0、A1、A2三个引脚的高低电平决定地址，排障时一定要先确认引脚焊接和跳线帽。OpenHarmony的HDI接口里，向从机发送数据时会在I2cMsg结构体中携带设备地址，地址写错了，总线上的从机根本不响应，表面症状就是ACK永远收不到。
3. OpenHarmony下的I2C开发全景：从HDI到实际读写
3.1 认识HDI的关键接口和数据结构
OpenHarmony的I2C HDI接口是规范化的，不同设备厂商实现的底层驱动可能不一样，但上层接口是统一的。常用接口主要有：
- I2cOpen：打开I2C控制器
- I2cClose：关闭I2C控制器
- I2cTransfer：执行一次传输，支持读、写、复合传输
- I2cSetConfig：设置I2C配置（速率、地址宽度等）
一次实际的读写操作，核心是填充I2cMsg结构体：
struct I2cMsg { uint16_t addr; // 从机7位或10位地址 uint32_t len; // buf长度 uint8_t *buf; // 数据缓冲区 uint16_t flags; // 读写标志：I2C_FLAG_READ为读，0为写 };这个结构体用起来要注意，一次传输可以传一个I2cMsg数组，里面放多个消息，比如"先写寄存器地址，再读数据"这种典型场景，可以直接组合成一个复合传输：
struct I2cMsg msgs[2]; uint8_t regAddr = 0x10; uint8_t dataBuf[2] = {0}; msgs[0].addr = 0x68; msgs[0].len = 1; msgs[0].buf = ®Addr; msgs[0].flags = 0; msgs[1].addr = 0x68; msgs[1].len = 2; msgs[1].buf = dataBuf; msgs[1].flags = I2C_FLAG_READ; I2cTransfer(0, msgs, 2);这里有个坑，个别驱动对flags字段的处理是:0表示写，I2C_FLAG_READ表示读，但你传I2C_FLAG_WRITE（如果有这个宏）时可能被隐藏，设备直接不动作。建议直接翻你手上的OpenHarmony版本头文件，看看宏定义再填。
3.2 编写一个完整的HDI调用示例
写一个实际的例子：通过I2C读取一颗典型温度传感器（比如HDC1080）的温度值。
#include "i2c_if.h" #define I2C_BUS_NUM 0 #define SENSOR_ADDR 0x40 static int32_t ReadTemperature(int16_t *tempRaw) { struct I2cMsg msgs[2]; uint8_t regAddr = 0x00; // 温度寄存器地址 uint8_t dataBuf[2] = {0}; int32_t ret; msgs[0].addr = SENSOR_ADDR; msgs[0].len = 1; msgs[0].buf = ®Addr; msgs[0].flags = 0; msgs[1].addr = SENSOR_ADDR; msgs[1].len = 2; msgs[1].buf = dataBuf; msgs[1].flags = I2C_FLAG_READ; ret = I2cTransfer(I2C_BUS_NUM, msgs, 2); if (ret != 2) { printf("I2C transfer failed, ret=%d\n", ret); return -1; } *tempRaw = (dataBuf[0] << 8) | dataBuf[1]; return 0; }注意I2cTransfer的返回值：成功时返回的是传输的消息条数，不是字节数。有的驱动实现会返回字节数，这个属于厂商实现差异，强烈建议拿到板子后先写个最简单的读取测试打印一下返回值，确认你的板子是哪种行为，不然排查问题时容易被误导。
实际项目中，我这里还会加一个设备存在性检测，就是在初始化时发一个空写帧，看ACK是否成功。很多传感器对不存在地址的响应是直接无响应，能快速确认I2C地址和线路是否正常。
3.3 结合HDF与设备树配置，了解驱动侧注册
在OpenHarmony完整系统里，I2C外设驱动通常挂在HDF框架下，通过hcs配置描述设备信息。以一颗虚拟的I2C传感器驱动为例，hcs片段类似：
sensor_host { device_sensor0 { device0 { deviceInfo = "hdf_sensor_driver"; match_attr = "sensor_cfg"; } } }hcs配置文件里还会关联I2C总线号和从机地址，驱动代码里通过DeviceManager获取对应的I2C设备句柄，再调用HDI接口。这一层的具体文件名和路径会随版本变化，关键是理解：只要你在OpenHarmony系统上写外设驱动程序，大概率要碰hcs配置、驱动编译脚本（BUILD.gn）和HDF驱动框架的Init/Release函数。
给一个小建议：刚开始做I2C驱动，不要陷入hcs配置的细节里。先用应用层直接调用HDI接口验证硬件能通，再去把驱动挂在HDF上。这样排障范围最小，能快速区分是硬件问题还是框架配置问题。
4. 排障方法论与实操：从理论到工具再到实战
4.1 先分清故障层：总线层、协议层、驱动层、应用层
排障第一步不是看代码，而是分层定界。我的个人方法论是这样：
- 物理层问题：设备没上电、SDA/SCL接反、上拉电阻缺失、电平不匹配、接线过长、杜邦线松动
- 协议层问题：地址不对、寄存器地址没写、读时序不对、ACK/NACK异常、启动停止条件缺失
- 驱动层问题：HDI接口调用方式不对、I2cMsg参数填错、I2cTransfer返回值处理不对、缓冲区长度不对
- 应用层问题：采样频率太高、数据处理不对、传感器配置寄存器没初始化
快速定位的方法很简单：先用逻辑分析仪或示波器抓波形，如果波形上连START和地址帧都看不到，说明总线根本没跑起来，大概率是驱动或配置层的问题；如果波形上有完整起始和地址帧但没ACK，大概率是从机地址或物理连接问题；如果波形完整、ACK正常但数据不对，才是协议和数据处理问题。
这个判断逻辑我用了很多年，省下的排查时间非常可观。
4.2 用GPIO模拟I2C主机：十分钟自建排障工具
这个压箱底的方法分享出来之前，先说明为什么需要它：OpenHarmony的I2C控制器一旦不工作或者驱动没适配好，你手上就没有一个正常的I2C主机可用。但排障恰恰需要一个"已知能工作的主机"来测试从机。
解决思路是：用两个GPIO口软件模拟I2C时钟和数据，自己写一个最简化版本的主机协议，从而把"主控I2C控制器硬件"这一变量彻底摘掉。
核心代码逻辑示意（简化版，具体GPIO操作API按开发板适配）：
static void i2c_delay(void) { udelay(5); // 5us，对应约100kHz速率 } static void set_sda(int level) { gpio_write(I2C_SDA_PIN, level); } static void set_scl(int level) { gpio_write(I2C_SCL_PIN, level); } static void i2c_start(void) { set_sda(1); set_scl(1); i2c_delay(); set_sda(0); i2c_delay(); set_scl(0); } static void i2c_stop(void) { set_sda(0); set_scl(1); i2c_delay(); set_sda(1); i2c_delay(); } static void i2c_write_bit(int bit) { set_sda(bit); i2c_delay(); set_scl(1); i2c_delay(); // 从机在SCL高电平期间采样 set_scl(0); } static int i2c_read_ack(void) { int ack; set_sda(1); // 释放SDA，由从机拉低或保持高 i2c_delay(); set_scl(1); i2c_delay(); ack = gpio_read(I2C_SDA_PIN); set_scl(0); return ack == 0 ? 0 : -1; // 低电平为ACK }这套简易主机能干很多活。我的习惯是先用它做一次"地址扫描"：遍历0x01到0x7F所有地址，发送START + 地址 + 读标志，等待ACK，记录所有有ACK的地址。这样能快速找出从机真实地址，排除手册写错、引脚改地址等干扰。
拿C语言在OpenHarmony的shell或者HDF驱动里直接跑这个GPIO版本，只需要几十行代码，但它的价值非常大。举个例子：你的I2C控制器驱动一直报超时，你用这块"软件I2C"去访问同一个从机，如果能正常通信，那就说明主控的I2C控制器配置有问题；如果一样不通，说明从机或物理连接有问题。这种隔离排查的效率比反复改驱动高得多。
4.3 动手排障案例：从白屏到误码，逐个击破
案例一：屏幕白屏，I2C完全无响应
一台设备接了一颗OLED屏幕，上电后白屏。先用逻辑分析仪抓波形，发现SCL和SDA线上连一个时钟脉冲都看不到。查驱动，发现I2C控制器初始化函数返回成功，但总线配置的GPIO引脚复用被占用了——开发板的I2C0引脚同时被配置成了PWM功能。解决方案是把引脚复用关系改回来。这里经验是：OpenHarmony的GPIO复用配置一般分散在board级配置里，查问题别光盯着驱动代码。
案例二：加速度传感器读值偶尔跳变
现象是数据大部分时间正常，但偶尔会跳一个大值。用示波器看波形，SDA上的数据边沿有明显的过冲和振铃，这是接线过长加上拉太小导致信号质量差。换短杜邦线并以双绞方式处理SDA和SCL的走线，并把上拉从10k换成4.7k，问题消失。这类问题是物理层问题里典型的场景。
案例三：EEPROM写入成功但读出全FF
EEPROM（比如AT24C02）写入后读回全FF，看起来像数据丢了。实际排查发现，写入操作后没有等待EEPROM内部的写周期完成（大约5ms），导致写入实际上没生效，但I2C时序上从机会在写周期内不响应，我们没检测就直接返回成功。解决办法是写入后加延时或轮询ACK等待写周期结束。这个案例特别能说明，协议正确不代表操作成功，外设芯片的内部状态同样重要。
案例四：总线死锁，卡在第一次传输
新板子第一次跑I2C就卡死，表现为程序停在I2cTransfer调用里不返回。 查波形，SCL被从机拉低不放。这个现象正是从机的clock stretching（时钟延展）：从机想暂停通信时会把SCL拉低。但我们的主控驱动没有处理时钟延展，直接等待超时。处理方法是：确保I2C控制器支持时钟延展，或者在软件上做超时判断，并且听复位从机（如果有复位引脚）来恢复。更稳妥的做法是每次系统初始化时，先对I2C总线做一次软复位，把可能处于死锁状态的从机释放出来。
4.4 常见问题速查表
| 故障现象 | 大概率原因 | 快速排查方法 |
|---|---|---|
| 读写全部超时 | 接线错误或上拉缺失 | 测SDA/SCL静态电平，正常应均为高 |
| 波形完整但无ACK | 从机地址不对 | 用GPIO模拟I2C扫描地址 |
| 数据读到0xFF | 从机没响应或上拉虚高 | 查看是否有完整ACK，测量VDD |
| 数据偶发错误 | 边沿质量差/总线过长 | 降低速率或调整上拉电阻 |
| 卡死在传输中 | 从机时钟延展未处理 | 检查SCL是否被拉低，加超时 |
| 只有特定寄存器读错 | 寄存器地址/长度不对 | 对照数据手册确认地址映射 |
| 复位后才能通信 | 总线死锁 | 初始化时手动发送STOP信号清理 |
这个表本质上是把经验浓缩成checklist。很多问题出现频率之高，甚至不用上示波器就能按照这个表逐条排查。
5. 排障前的信号时序与数据帧解析：波形与位的微观世界
5.1 从示波器/逻辑分析仪快速定位SDA/SCL异常
学会看I2C波形，是排障能力的分水岭。我从实际项目里总结了一套读波形的方法。
先看基础电平：正常空闲状态下，SDA和SCL都应该是高电平。如果测量时有一个是低电平，说明总线被某个设备占住或者上拉电阻有问题。我会首先断开所有从设备，直接量主控引脚，如果还是低，主控侧就有问题；如果变高，说明是某个从设备把线拉低了，挨个接入排除。
再看传输波形的基本结构：抓到一轮完整的START、地址、ACK、数据、STOP后，放大观察每一位。I2C数据的每一位，在SCL高电平期间SDA必须保持稳定，数据变沿只能出现在SCL低电平期间。如果看到SDA在SCL高电平期间发生跳变，这通常不是一个合法的数据位，更可能是STOP或START条件，需要结合前后文判断。
用逻辑分析仪解析I2C时序时，我习惯设置好起始电压阈值：一般TTL电平用1.5V，3.3V系统用1.65V，5V系统用2.5V。阈值设置不对，逻辑分析仪会把一个实际的高电平误判成低电平，导致解出来的地址全是错的。这个问题看起来很蠢，但实际遇到时真的会让人浪费时间。
5.2 时钟延展与总线死锁
时钟延展（clock stretching）是I2C协议里容易被忽略的机制。 从机可以主动把SCL拉低，迫使主机等待，直到从机准备好再释放SCL。这个机制在低速传感器、EEPROM写入周期中经常出现。
排查手段是抓波形时重点关注SCL低电平时间。如果SCL低电平时间明显长于正常时钟周期，那一定存在时钟延展。主控I2C控制器一般支持该特性，但有些主控可配置选项里有开关，建议打开。对于软件模拟I2C，必须在检测到SCL被拉低后等待其释放，否则时序直接错乱。
总线死锁则是另一个状态：总线在启动条件后异常停止，或者某个从机异常拉低SDA，之后所有通信都无法开始。处理方式是在系统初始化阶段，在I2C控制器上执行一次复位操作，并通过IO口翻转产生一个假的STOP序列（SDA在SCL高电平时从低变高），把总线恢复到空闲状态。这个技巧我推荐放在驱动初始化函数里，哪怕没有死锁，损耗几乎为零。
5.3 位级验证与7位地址匹配，不只是看ACK
很多新手看到ACK就认为通信正常，但实际上，ACK只表示总线有一个设备响应了，并不保证响应的是你想访问的那个设备。举个例子：总线上挂着一颗设备，它的地址恰好是0x50，你的软件配置成了0x51，这时从机同样会NACK。但如果地址重叠（比如你写的是0x68，恰好总线上有一颗0x68的设备），即使不是你想要的那颗，也会给出ACK。
排查这类问题有两个关键手段：
一是使用I2C地址扫描工具，把0x01到0x7F的每一个地址都发一遍START+读标志，记录所有能ACK的地址。这个操作如果在有多个从机的总线上做，输出结果能瞬间暴露实际器件地址和软件配置的差异。
二是读回设备ID寄存器。绝大多数I2C芯片都有device ID或who am I寄存器。比如MPU6050的WHO_AM_I是0x75，正常读回值应该是0x68。这个寄存器可以用来百分百确认你访问的设备就是目标设备。记得在做驱动初始化时，一定要把设备ID校验代码加上，这能省下后面一大半排障时间。
5.4 提升排障效率的3个小习惯，实测有效
第一个习惯：所有I2C驱动初始化时，第一件事先写一个最简单的"地址探测"，只发一个无数据的写帧，检查返回值，并把结果打印到日志。很多问题不用到数据收发那一步就被识别出来。
第二个习惯：必要时给排障预留一个软件I2C后端。我在具体产品调试阶段，经常在代码里编译一个IOCTL接口，可以通过命令行选择使用"硬件I2C"还是"GPIO模拟I2C"。这个设计初期看着像多此一举，等到硬件/驱动反复互咬时才知道它的好处。
第三个习惯：保持一个已知正常的设备作为"黄金参照"。我手头常备一颗MPU6050传感器模块，它的I2C地址固定、手册清晰、时序标准，任何板子出现问题，我会先用它测试主控的I2C控制器是否正常。如果主控连这颗标准模块都通信失败，问题在主控侧；如果能通信，再去检查产品实际使用的传感器。
6. 实操心得与额外建议
6.1 我踩过且最典型的I2C坑（按频率排序）
按实际碰到频率从高到低排个队：
第一名是接线问题，尤其杜邦线接触不良。开发阶段经常用母对母杜邦线，插拔几次以后，线鼻子里的弹片就松了，看着插紧了实际悬空。用万用表通断档去量一根线，或者干脆换一根线，往往就解决了。
第二名是从机地址搞错。7位地址和8位地址混淆是重灾区。比如手册写"0x68"，指的是7位地址，你把它左移一位变成0xD0写入寄存器，结果驱动里直接填0x68当成8位地址，导致地址帧发送的是0x34，总线上的从机全都不认得。每次拿到新芯片，我都会先确认寻址方式，再对照数据手册的计算说明。
第三名是寄存器地址和数据长度不匹配。比如读一个16位传感器数据，寄存器说明里写着"上电后自动转换，读0x00返回2字节温度"，但你只读了1字节，主控会以为传输正常，数据其实只有高字节。这个往往是代码里len写错。
第四名是上拉电阻缺失。这个通常发生在画板子阶段，原理图里忘了给SCL和SDA加上拉，或者等到了调试阶段才发现没有。表现是的波形整体爬升缓慢，甚至高电平顶不上去；最典型的现象是：用万用表量电压时，SDA/SCL会随着从机接入和断开出现不稳定的电压波动。
6.2 值得后来者复制的项目文件结构
如果你是基于OpenHarmony的HDF驱动做I2C外设，我推荐一个经过多个项目验证的代码结构：
i2c_sensor_driver/ ├── BUILD.gn ├── sensor_impl.c # HDF驱动初始化、Release、消息处理 ├── sensor_register.c # HDF配置解析、设备匹配 ├── i2c_common.c # 封装HDI接口的I2C读写函数 ├── i2c_debug.c # GPIO模拟I2C、地址扫描等排障工具 ├── sensor_chip.c # 具体传感器芯片寄存器操作和数据处理 ├── sensor_chip.h └── sensor_config.h # 引脚、地址、速率等参数配置这个结构把"业务协议"和"硬件适配"分开了。遇到新芯片时，只需要改sensor_chip.c和sensor_config.h，i2c_common.c基本不用动。i2c_debug.c里的工具在量产初期产品回归测试阶段，也能持续帮你做通信自检。
再提一个细节：BUILD.gn里需要正确声明依赖库和头文件路径。OpenHarmony的依赖关系里，I2C HDI相关头文件一般在/drivers/peripheral/或系统sdk目录下；如果你引用的是带hdf框架的接口，记得把libhdf相关库写进依赖列表。这个看起来是小事，但新手最容易在编译阶段卡住，建议直接在官方sdk的示例里找现成的BUILD.gn参考，不要自己发明。
6.3 产出角度与后续扩展思路
OpenHarmony的I2C教程写到这里，其实只是一个起点。如果你拿这个流程去套其他外设通信接口，比如SPI、UART，核心方法论是通用的：先确认物理层、再验证协议层、最后调试驱动和应用层。
往深了学，有几个方向值得继续研究：
深入HDF框架：搞明白I2C控制器驱动内部如何通过消息解析、IOMMU、任务调度来处理并发访问。多个进程或线程同时操作同一套I2C总线时，HDF是怎么做互斥的，这对做产品的人来说很重要，因为并发访问I2C的总线冲突是隐蔽且麻烦的。
研究多主控共享I2C总线：某些应用里会有两个主控或一个主控加一个协处理器，同时在一根I2C总线上访问相同或不同的从机。这时I2C仲裁机制的价值就显现出来了，理解总线的多主机仲裁规则，能帮你设计出不会互相干扰的通信策略。
做一本自己的I2C排障手册：把一个个实际案例沉淀成自己的故障库，比什么都管用。每一个案例记录现象、波形、原因、解决方案，一段时间后，你的排障速度会远远超过依赖网上查资料的同行。
我在实际使用中还有一个体验非常深：写I2C驱动时不要一上来就追求功能，先把"自检能力"做进去。就是无论初始化还是运行中，都要有快速验证通信链路的能力。这样后期不管是硬件升级还是软件重构，你都有一把随时可用的标尺。很多看似难查的诡异问题，用这个自检能力一量，几分钟就能锁定方向。
