做过嵌入式的人大多碰过这种场面：板子焊回来上电，屏幕不亮、传感器读不到数，第一反应是芯片坏了，万用表一量电源正常，逻辑分析仪一挂发现 SDA 被拉死在低电平，再回头看代码——IIC 驱动里那个等 ACK 的 while 循环一直转不出来。IIC（很多人习惯写成 I2C，本质是同一条两线总线）驱动算是嵌入式里最"入门"的一类驱动：两根线、几个时序、读几个寄存器，看起来比 USB、PCIe 简单太多。可真要在量产产品上把它写稳，坑一点不比复杂总线少，从地址搞错、上拉选错、时钟延展不兼容，到多设备共总线互锁、休眠唤醒后总线假死，每一类都能让人熬夜。这篇内容把 IIC 驱动从物理电平和时序讲起，一路捋到 Linux 下的三层驱动框架、设备树写法、裸机状态机实现、软件模拟总线的精度问题，最后落到调试排错和长期稳定性上。刚接触驱动的新人可以把前面几节当入门地图，从裸机转 Linux 的朋友重点看第三章和第四章，被总线莫名锁死折磨过的老手建议直接翻到第六、七章。
1. IIC 驱动到底在驱什么：先把三层概念分清楚
1.1 两根线背后的完整链路
很多人写 IIC 驱动写不顺，根子不在代码，而在概念没分层。一条 IIC 总线上其实叠了三层东西：最底下是控制器（芯片内部那个 IIC 外设，管时序生成、时钟分频、中断、DMA），中间是总线（SCL/SDA 两根线加上拉电阻，以及挂在上面的所有从设备），最上面才是设备驱动（针对某颗 EEPROM、某颗温湿度传感器、某颗 IO 扩展芯片写的业务逻辑）。
裸机时代这三层通常混在一起写：初始化寄存器、发起始条件、发地址、等 ACK、读数据，全部堆在一个函数里。这样能跑，但一旦总线上挂了五六颗不同芯片，代码就会变成一坨互相纠缠的状态机，改一处惊一片。Linux 把这三层拆得很干净：控制器驱动注册i2c_adapter，负责"怎么把字节变电信号"；i2c-core负责总线管理和消息调度；设备驱动注册i2c_driver，只关心"给我地址我读寄存器"。分层之后，同一份设备驱动可以跑在不同厂商的控制器上，换主控几乎不用改业务代码，这就是分层的价值。
我在带新人时经常用一个类比：控制器是"快递小哥"，负责把包裹按规矩送到门口；总线是"小区道路"，宽度、限速、有没有堵车都在这层；设备驱动是"下单的人"，只管说清收件地址和要寄什么。你下单的人天天去研究小哥骑什么车、路上几个红绿灯，效率不会高，还容易把责任搞混——很多"驱动写不通"的锅，其实最后查出来是上拉电阻或者地址焊错。
1.2 为什么 IIC 驱动特别"娇气"
IIC 用的是一主多从、开漏输出加外部上拉的电气结构。开漏意味着任何设备只能把线拉低，不能主动推高，高电平完全靠上拉电阻把线"拽"上去。这个设计带来两个后果：一是总线上任意一台设备拉低，整条线就是低，谁也别想通信；二是高电平的上升沿是 RC 充电过程，上升时间跟总线电容和上拉阻值直接相关。
所以 IIC 的"娇气"是物理层面的：总线电容大了、上拉阻值选大了，波形上升沿变缓，从机就可能把高电平误判成低电平，读出来全是 0xFF；上拉阻值选小了，灌电流变大，有些低功耗芯片直接拉不到标准的低电平门限，通信时好时坏。这些问题在实验室桌面上通常不会暴露，因为线短、设备少、电容小，一上整机、线束拉长、挂满十几个从设备，问题立刻冒出来。我做过一个项目，样机阶段一切正常，转量产换了更长的柔性排线之后，同一条 IIC 上两颗传感器的读取失败率从 0 涨到 3%，最后就是总线电容从 80pF 涨到 300pF，上拉没改。
1.3 硬件 IIC 还是软件模拟：三种实现怎么选
| 实现方式 | 优点 | 代价 | 适合场景 |
|---|---|---|---|
| 控制器硬件 IIC | 时序精准、CPU 占用低、支持中断与 DMA | 引脚固定、灵活性差、部分控制器有硬件缺陷 | 主控有可用 IIC 外设、速率 >= 400kHz |
| GPIO 软件模拟 | 引脚随便挑、时序可调、易调试 | 占用 CPU、高速率下时序抖动 | 引脚冲突、需要非标准时序、低速从设备 |
| 半硬件（硬件起停 + 软件数据） | 折中方案 | 依赖具体控制器能力 | 特定平台迁移 |
选型的判断依据其实就三条：速率要求、引脚资源、CPU 负载。跑 100kHz 读几颗传感器，软件模拟完全够用，还能省一个外设给更吃紧的接口；跑 400kHz 以上、或者需要连续大批量读数据（比如某些 6 轴 IMU 的 FIFO 突发读），硬件控制器加 DMA 才是正解。还有一种情况必须用软件模拟：从设备要求非标准的时序，比如某些老式芯片要求停止条件后保持一段时间的总线空闲，硬件控制器改不了，只能用 GPIO 手动打波形。
2. 写驱动之前必须记住的协议细节
2.1 起始、停止、应答：三件事决定成败
IIC 的通信单元不是"帧"，而是"条件 + 字节 + 应答"。起始条件（START）是 SCL 高电平期间 SDA 由高变低，停止条件（STOP）是 SCL 高电平期间 SDA 由低变高，这两个条件必须由主机产生，而且电平变化的时间窗口有硬性要求——标准模式 100kHz 下，起始条件的建立时间不小于 4.7μs，保持时间不小于 4.0μs；快速模式 400kHz 下这两个值分别缩到 0.6μs。
每个字节 8 位，高位在前，第 9 个时钟由接收方拉低 SDA 表示应答。这里最容易踩的坑是应答的方向搞反：主机写数据时，从机拉低 SDA 应答；主机读数据时，是主机在最后一个字节回 NACK 告诉从机"别再发了"。我见过不少手写模拟代码，读最后一个字节时忘了发 NACK，从机继续往总线上推数据，下一轮通信直接错位。
注意：很多控制器在"读最后一个字节"时要求软件显式设置
I2C_M_NOSTART或采用i2c_smbus_read_i2c_block_data这类封装，具体看控制器手册。别假设控制器会自动帮你发 NACK。
2.2 七位地址、读写位、寄存器地址：三层寻址别混
第一次写 IIC 驱动最容易晕的就是地址。从设备有一个 7 位地址，比如某颗 EEPROM 的地址引脚全接地时是 0x50。这个 7 位地址在总线上传输时要左移一位，最低位放读写标志：写是 0，读是 1。所以总线上实际出现的字节是 0xA0（写）和 0xA1（读）。
坑在于不同工具和不同 API 对"地址"的定义不一致：Linux 的i2c_client.addr和i2c-tools用的是 7 位地址；而不少裸机例程、某些厂商的 SDK 直接用 8 位地址（已经左移过的）。你要是把 0xA0 填进设备树的reg，内核会按 7 位地址解释成 0x20，然后一直等不到应答。这类问题排查起来特别费劲，因为地址"看着没错"。
还要再叠加一层：寄存器地址。传感器类的从设备内部通常有一张寄存器表，通信格式是"写寄存器地址（1 或 2 字节）+ 读/写数据"。真正的通信结构是：START → 从机地址+W → 寄存器地址 → 重复 START → 从机地址+R → 数据 → NACK → STOP。四段拼在一起，任何一段的字节序或长度错了，读回来就是 0xFF 或 0x00。
2.3 时钟频率与上拉电阻：算一遍比试十次快
上拉电阻的取值不是凭感觉，有明确的计算区间。上限由上升时间决定：
Rp(max) = tr / (0.8473 × Cb)
下限由低电平灌电流决定：
Rp(min) = (VDD − VOL) / IOL
举个例子：3.3V 系统，总线电容估 200pF（长排线 + 8 个器件，这个数一点不夸张），快速模式上升时间上限 300ns。代入得 Rp(max) = 300ns / (0.8473 × 200pF) ≈ 1.77kΩ。再算下限，VOL 取 0.4V，IOL 取 3mA，Rp(min) = (3.3 − 0.4) / 3mA ≈ 967Ω。所以合理区间是 0.97k ~ 1.77k，取 1.5k 比较稳妥。换成短排线、电容只有 80pF，Rp(max) 就变成 4.4kΩ，这时候用 4.7k 也勉强能跑，但余量不大。
| 总线电容 | 模式 | 上升时间上限 | Rp 上限计算值 | 推荐取值 |
|---|---|---|---|---|
| 80pF | 100kHz 标准 | 1000ns | 14.7kΩ | 4.7kΩ |
| 80pF | 400kHz 快速 | 300ns | 4.4kΩ | 3.3kΩ |
| 200pF | 400kHz 快速 | 300ns | 1.77kΩ | 1.5kΩ |
| 400pF | 400kHz 快速 | 300ns | 0.88kΩ | 已超出规范，需减小电容或降速 |
上表最后一行值得特别说：400pF 是 IIC 规范给出的总线电容上限，超过这个值就不该硬撑，应该降速到 100kHz，或者加 IIC 缓冲/中继器件把总线分段。硬顶的后果是通信"大部分时候正常"，偶尔丢一帧，这种偶发问题在量产里最难定位。
2.4 时钟延展与重复起始：两个常被忽略的兼容性问题
时钟延展（clock stretching）是从设备在还没准备好数据时把 SCL 拉低，强制主机等待。协议是允许的，但很多控制器的硬件实现不支持，或者支持得不好——一旦从机拉低 SCL 超过控制器内部超时，控制器就报总线错误。某些温湿度传感器、某些电量计在转换期间就会延展时钟。遇到这类从机，要么换支持延展的控制器，要么改用 GPIO 模拟（模拟代码里必须真的去读 SCL 电平再决定是否继续拉高）。
重复起始（repeated START）是在不发 STOP 的情况下重新发起始条件，用于"写地址 → 读数据"的原子操作。有些从设备在 STOP 之后会释放内部状态机，如果中间插了 STOP，第二次通信就要重新配置，读回来的数据是错的。写驱动时看到i2c_transfer里传两条 msg 且没有中间 STOP，就是这个道理——内核的i2c_transfer在两条消息之间默认发重复起始，除非你显式设置标志位。
3. Linux 下 IIC 驱动的三层框架怎么配合
3.1 控制器驱动与设备驱动的分工
Linux 的 IIC 子系统抽象得非常干净。控制器驱动负责实现struct i2c_algorithm里的master_xfer（传一组消息）和functionality（报告支持的能力，比如是否支持 SMBus 块读、是否支持 10 位地址），然后调用i2c_add_adapter把适配器注册进内核。设备驱动则是实现struct i2c_driver的probe、remove，以及of_match_table/id_table，然后module_i2c_driver注册。
匹配过程是这样的：内核解析设备树里的compatible字符串，和驱动里的of_match_table对比，匹配成功就调用probe，并把一个已经初始化好的struct i2c_client *传进来。这个 client 里已经填好了addr（7 位地址）和adapter指针，驱动完全不需要自己去碰控制器寄存器。这也是为什么同一个传感器驱动能同时跑在几家不同主控上的原因。
3.2 设备树节点怎么写才不出错
&i2c1 { status = "okay"; clock-frequency = <400000>; pinctrl-names = "default"; pinctrl-0 = <&i2c1_pins>; eeprom@50 { compatible = "generic,i2c-eeprom"; reg = <0x50>; pagesize = <32>; }; sensor@48 { compatible = "generic,i2c-sensor"; reg = <0x48>; interrupt-parent = <&gpio1>; interrupts = <12 2>; vdd-supply = <&vcc_3v3>; reset-gpios = <&gpio1 13 1>; poll-interval-ms = <100>; }; };几个必须检查的点：reg填 7 位地址，不是左移过的 8 位；clock-frequency写在控制器节点上，写进从设备节点是无效的（很多人在这里栽过）；中断触发类型要和芯片手册一致，边沿触发和电平触发搞错，表现为中断风暴或者一次中断都进不来；reset-gpios这类复位脚一定要接上，很多传感器上电后处于复位态，不主动拉一次就永远不应答。
还有一个易漏项：上电时序。有些芯片要求 VDD 稳定后延迟 10ms 以上才能访问，或者要求某个使能脚先拉高再等 5ms。设备树里描述不了这种时序，只能在probe里用msleep加regulator的enable顺序处理。我个人的习惯是把上电、复位、等待、验证 ID 这四步封装成一个power_on()函数，probe里失败就返回-ENODEV，同时打印实测到的 ID 值——这个打印在调试期救命，能一秒区分"没焊好"和"驱动写错"。
3.3 先别写代码：用 i2c-tools 把硬件验证一遍
这一步能省掉大量时间。板子起来之后，先确认适配器编号，再扫地址。
i2cdetect -l # 列出所有适配器 i2cdetect -y 1 # 扫描 i2c-1 总线上的设备输出里地址位置显示UU表示该地址已被内核驱动占用，显示具体数值表示探测到了设备但没驱动接管。如果整行全是--，不用怀疑代码，问题一定在硬件或引脚复用：引脚复用没配对、上拉没焊、器件没供电、地址引脚接错，这四种占了绝大多数。
再往下验证寄存器读写：
i2cget -y 1 0x50 0x00 # 读 1 字节 i2cset -y 1 0x50 0x00 0x5A # 写 1 字节 i2cdump -y 1 0x50 # 整页 dump，看 ID 寄存器i2cdump特别好用，很多传感器的 ID 寄存器在固定偏移上，dump 出来一眼就能确认型号对不对、通信通不通。这一步通了再写驱动，心里就有底了。
3.4 寄存器访问封装：裸 i2c_transfer 还是 regmap
内核提供两种常见写法。一种是直接用i2c_transfer拼消息：
static int sensor_read_reg(struct i2c_client *cli, u8 reg, u8 *val) { int ret; struct i2c_msg msgs[2] = { { .addr = cli->addr, .flags = 0, .len = 1, .buf = ® }, { .addr = cli->addr, .flags = I2C_M_RD, .len = 1, .buf = val }, }; ret = i2c_transfer(cli->adapter, msgs, 2); return (ret == 2) ? 0 : (ret < 0 ? ret : -EIO); }另一种是用regmap：
static const struct regmap_config sensor_regmap_cfg = { .reg_bits = 8, .val_bits = 8, .max_register = 0x7F, .cache_type = REGCACHE_RBTREE, }; priv->map = devm_regmap_init_i2c(cli, &sensor_regmap_cfg);我现在的默认选择是regmap，理由有三个：自带寄存器缓存，读多写少的场景能少发很多总线事务；统一的调试接口，/sys/kernel/debug/regmap/下能直接看寄存器快照；换总线（SPI 换 IIC）时只改初始化那一行。代价是多一层间接调用，单次访问开销略大，对时序敏感的场合（比如要求两次读之间必须间隔固定时间）要小心缓存导致的"看起来没访问"。
4. 从零写一个 IIC 设备驱动：完整实操流程
4.1 驱动骨架与 probe 的关键顺序
#include <linux/module.h> #include <linux/i2c.h> #include <linux/regmap.h> #include <linux/gpio/consumer.h> #include <linux/regulator/consumer.h> #include <linux/delay.h> struct sensor_priv { struct i2c_client *client; struct regmap *map; struct gpio_desc *reset_gpio; struct regulator *vdd; struct mutex lock; }; static int sensor_power_on(struct sensor_priv *priv) { int ret, id; ret = regulator_enable(priv->vdd); if (ret) return ret; if (priv->reset_gpio) { gpiod_set_value_cansleep(priv->reset_gpio, 0); msleep(5); gpiod_set_value_cansleep(priv->reset_gpio, 1); msleep(20); } regmap_read(priv->map, 0x0F, &id); dev_info(&priv->client->dev, "chip id = 0x%02X\n", id); return 0; } static int sensor_probe(struct i2c_client *cli) { struct sensor_priv *priv; priv = devm_kzalloc(&cli->dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; priv->client = cli; mutex_init(&priv->lock); priv->vdd = devm_regulator_get(&cli->dev, "vdd"); if (IS_ERR(priv->vdd)) return PTR_ERR(priv->vdd); priv->reset_gpio = devm_gpiod_get_optional(&cli->dev, "reset", GPIOD_OUT_LOW); priv->map = devm_regmap_init_i2c(cli, &sensor_regmap_cfg); if (IS_ERR(priv->map)) return PTR_ERR(priv->map); sensor_power_on(priv); i2c_set_clientdata(cli, priv); return 0; }顺序上有个原则：先电源、再复位、后通信。看起来是废话，但我见过太多代码把regmap_init放在regulator_enable之前就去读寄存器，读回来自然是 0xFF，然后一脸困惑。另一个细节是错误路径，devm_系列能自动回收，但regulator_enable这种显式调用的必须在remove里配对的disable，否则休眠时漏电，待机功耗直接翻倍。
4.2 读写接口与并发保护
驱动对外通常暴露成sysfs属性、hwmon、iio或者字符设备。不管哪种，底层都得加锁。IIC 总线是共享资源，两个线程同时调用i2c_transfer会导致消息交错，轻则数据错乱，重则总线锁死。加锁的粒度要覆盖"整组消息"，而不是单个字节，因为多字节寄存器（比如 16 位 ADC 值）的高低位必须保证来自同一次转换。
static int sensor_read_value(struct sensor_priv *priv, int *out) { unsigned int lo, hi; int ret; mutex_lock(&priv->lock); ret = regmap_read(priv->map, 0x10, &lo); if (!ret) ret = regmap_read(priv->map, 0x11, &hi); mutex_unlock(&priv->lock); if (ret) return ret; *out = ((hi << 8) | lo); return 0; }regmap内部也有自己的锁，但那是保护单次访问的，跨寄存器的一致性还得自己管。这一点在中断触发读取时尤其要注意：中断上下文不能睡眠，所以要么用regmap_read的原子版本配合工作队列，要么在threaded_irq里做实际读取。我的习惯是request_threaded_irq，硬中断里只做regmap_write清状态位和disable_irq_nosync，实际读数据丢给线程处理函数，既保证实时性又避免睡眠问题。
4.3 中断还是轮询：选之前先看数据率
数据率低于 20Hz 的场景，轮询完全够用，代码简单，还少一个中断线的硬件调试环节。数据率高、或者对延迟敏感（比如运动检测、过阈值告警），才需要中断。用中断要确认三件事：中断触发类型与芯片手册一致、中断状态位必须显式清除（否则电平触发的中断会一直挂住）、中断引脚上有时需要外部上拉。
还有一种情况是"中断 + 轮询"混用：平时靠中断唤醒，唤醒后连续轮询读若干帧确认有效数据。某些 IMU 的 FIFO 水位中断就是这样用的。
5. 裸机与 RTOS 下的 IIC 驱动实现
5.1 状态机写法比阻塞写法更稳
裸机里最常见的写法是阻塞式：拉起始、发字节、死等 ACK、超时返回 0。这种写法在小系统里没问题，但一旦总线上有设备偶尔不响应，整个主循环就被卡住，看门狗直接复位。更稳的做法是把一次传输拆成状态机，每个状态在一次调用里向前推进一步，主循环里周期性调用。
typedef enum { IIC_ST_IDLE, IIC_ST_START, IIC_ST_ADDR, IIC_ST_REG, IIC_ST_RESTART, IIC_ST_DATA, IIC_ST_STOP, IIC_ST_ERROR, } iic_state_t; typedef struct { iic_state_t state; uint8_t addr; uint8_t *buf; uint16_t len; uint16_t idx; uint32_t tick; int result; } iic_xfer_t; int iic_poll(iic_xfer_t *x) { switch (x->state) { case IIC_ST_START: iic_gen_start(); x->state = IIC_ST_ADDR; x->tick = tick_now(); break; case IIC_ST_ADDR: if (iic_send_byte(x->addr)) { x->state = IIC_ST_REG; } else if (tick_now() - x->tick > TIMEOUT_MS) { x->state = IIC_ST_ERROR; x->result = -1; } break; /* ... 后续状态同理 ... */ default: break; } return x->result; }状态机的好处是把"等待"变成了"稍后再来"，超时逻辑也能统一在一处处理。代价是代码变长，可读性依赖状态命名清晰。我一般会配一张状态迁移表写在注释里，后来接手的人看得懂。
5.2 总线死锁：九脉冲恢复是必修课
从机在传输中途被复位（比如电源抖动、看门狗复位了从机而主机没复位），它可能正处于"正在输出 0"的状态，把 SDA 一直拉低不放。主机这时发起始条件没用，因为总线已经被占死。标准恢复流程是：主机把 SCL 当作普通 GPIO，手动打最多 9 个时钟脉冲，让从机把剩余的位数走完，松开 SDA，然后发一个 STOP 条件复位总线状态机。
void iic_bus_recover(void) { gpio_set_output(SCL); gpio_set_input(SDA); for (int i = 0; i < 9; i++) { gpio_write(SCL, 0); delay_us(5); gpio_write(SCL, 1); delay_us(5); if (gpio_read(SDA)) break; } /* 补一个 STOP：SCL 低 -> SDA 低 -> SCL 高 -> SDA 高 */ gpio_write(SCL, 0); gpio_write(SDA, 0); delay_us(5); gpio_write(SCL, 1); delay_us(5); gpio_write(SDA, 1); delay_us(5); }这段代码建议直接放进项目模板里，所有 IIC 初始化前先跑一遍。我在三个不同项目里都靠它救回了"开机偶发不亮"的现场，事后定位都是从机复位时序和主机不同步。
5.3 GPIO 模拟 IIC 的时序精度陷阱
软件模拟的时序靠delay_us或循环空转实现，问题在于编译器优化等级一变，循环耗时全变。Debug 版本能通信，Release 版本直接挂，这种"换个编译选项就坏"的诡异现象，八成是模拟时序的延时不准。
两个缓解办法：一是用硬件定时器做微秒延时，别用空循环；二是在起始/停止条件的电平切换之间留足余量，标准模式要求 4.7μs，实际跑到 6~8μs 更保险，反正 100kHz 的位周期有 10μs，余量够。还有人会关掉对应函数的编译优化（__attribute__((optimize("O0")))），这种做法我不推荐，因为它把不确定性藏起来了，移植到别的编译器上照样炸。
6. 调试排错实录：常见故障速查
6.1 故障现象与原因对照表
| 现象 | 高概率原因 | 排查动作 |
|---|---|---|
扫描总线全-- | 引脚复用未配置 / 器件未供电 / 上拉缺失 | 量电压、查 pinctrl、量上拉阻值 |
| 扫描到地址但读写全 0xFF | 设备未退出复位 / 上电延时不足 | 加复位时序，读 ID 寄存器确认 |
| 偶尔丢帧，重试即好 | 总线电容过大 / 上拉偏大 / 干扰 | 降速到 100kHz 验证，缩短排线 |
| 首字节正确，后续全错 | 重复起始缺失 / 字节序错 / NACK 位置错 | 逻辑分析仪抓完整时序逐位比对 |
| 运行几小时后总线卡死 | 从机复位不同步 / 缺少超时保护 | 加九脉冲恢复 + 传输超时 |
| 休眠唤醒后不工作 | 控制器掉电未重初始化 / 从机状态丢失 | 唤醒回调里重新配置并重读 ID |
| 多设备时好时坏 | 地址冲突 / 时钟延展不被支持 | 逐个摘除设备定位，查手册是否延展时钟 |
6.2 逻辑分析仪怎么抓才有意义
抓 IIC 波形别只看有没有波形，要抓"完整的传输单元"。触发条件设成 SDA 下降沿（起始条件），采样率至少是时钟频率的 10 倍（400kHz 总线用 10MS/s 以上），采集长度覆盖一次完整的读写。看的时候重点看四个地方：起始条件的建立/保持时间是否达标；第 9 个时钟 SDA 是否被正确拉低（ACK）；重复起始的位置对不对；停止条件后总线是否释放。
有些分析仪自带 IIC 协议解码，能直接把地址、数据、ACK 列出来，这时候对着从机手册比对字节序，几秒钟就能看出问题。我习惯把解码结果和驱动里的i2c_transfer消息数组摆在一起看，一眼就能发现"驱动以为发了 2 字节，总线上只有 1 字节"这类错误。
6.3 一个真实的排查记录
某次调试一颗姿态传感器，现象是能读到 WHO_AM_I 正确值，但连续读数据寄存器时，第一组数据正确，第二组开始全是 0。查了两小时代码，regmap配置没问题，锁也加了。最后抓波形发现：两次读之间没有 STOP 条件，而从机要求每次读操作后必须收到 STOP 才更新内部数据指针。原因是i2c_transfer传了两条消息（写寄存器地址 + 读数据），内核默认在两条之间发重复起始，但从机不支持——它要的是"写地址、STOP、再起始、读"。
解决办法是拆成两次独立的i2c_transfer调用，各自带完整起停：
/* 第一次：写寄存器地址，带 STOP */ struct i2c_msg m1 = { .addr = cli->addr, .flags = 0, .len = 1, .buf = ® }; i2c_transfer(cli->adapter, &m1, 1); /* 第二次：独立读，带自己的 START/STOP */ struct i2c_msg m2 = { .addr = cli->addr, .flags = I2C_M_RD, .len = len, .buf = buf }; i2c_transfer(cli->adapter, &m2, 1);代价是两次调用之间总线可能被别的设备抢占，所以必须放在同一把锁里。这个坑教科书上不会写，只能靠抓波形定位。后来我把"从机是否支持重复起始"写进了项目 checklist，每接一颗新器件都先验证这一点。
7. 从能跑到跑得稳：稳定性设计要点
7.1 超时是底线，不是可选项
所有 IIC 传输都必须带超时。硬件控制器一般有自己的超时寄存器，配成几毫秒即可；GPIO 模拟必须自己数循环。没有超时的 IIC 代码等于给产品埋了一颗定时炸弹——从机某次没响应，主线程永远卡在等 ACK，看门狗复位后由于从机状态未清，又卡一次，形成死循环。我给团队定的规范是：任何 IIC 访问函数的返回值必须能被上层区分成"成功"、"总线错误"、"设备无响应"三类，上层据此决定重试还是上报。
重试策略也有讲究。单次失败立即重试一次是合理的，连续三次失败就应该走总线恢复流程，而不是无限重试。无限重试在总线上有短路时会变成 CPU 满载，反而掩盖了真实故障。
7.2 电源管理与休眠唤醒
带电池的产品里，IIC 相关的外设通常要参与低功耗管理。休眠时的关键是：控制器时钟是否关闭、从设备是否断电、唤醒后从设备是否需要重新配置。很多从设备掉电后寄存器全部回到默认值，包括量程、采样率、中断使能这些业务相关的配置，唤醒后不重配就会出现"数据看着有但量程不对"的隐蔽故障。
我的做法是把"配置寄存器列表"抽成一张表，probe和resume都调用同一个sensor_apply_config()函数，避免两处配置不一致。同时在suspend里把中断屏蔽掉，否则休眠期间中断线抖动可能把系统反复唤醒，待机电流直接从微安级飙到毫安级。
7.3 多设备共总线的资源竞争
一条总线上挂多颗器件时，除了地址不能冲突，还要注意带宽分配。400kHz 总线的理论吞吐是 40KB/s 左右，扣掉地址、ACK、起停开销，实际有效数据率大概只有一半。如果总线上有一颗高频采样传感器在持续占用总线，其他设备的响应延迟会被拉长。这时候要么给高频设备单独分一条总线，要么降低采样率、用 FIFO 批量读，把总线占用率压下来。
我一般在设计初期就算一笔账：把每个设备的采样率、每次读的字节数、协议开销加起来，估一个总线的理论占用率。超过 50% 就要考虑拆总线，因为实际运行时还有重试、其他主控访问、中断处理延迟这些额外开销。
7.4 几条写在 checklist 里的经验
第一，新板子第一次上电，先不写驱动，用i2cdetect扫一遍，扫不到就去查硬件，别在代码里找原因。第二，每个新器件接入前，先只接它一个，验证通了再加第二个，避免多变量同时变化。第三，驱动里务必打印芯片 ID，这是区分"硬件问题"和"软件问题"最快的信号。第四，上拉电阻的取值写进原理图评审清单，别留给后面调试时拍脑袋。第五，所有 IIC 访问路径统一走一个封装层，将来要加日志、加统计、加重试，只改一处。
我在实际项目里体会最深的一点是：IIC 驱动写出来只要半天，写稳要半年。真正决定成败的往往不是那几行传输代码，而是上电时序、总线恢复、超时保护、休眠重配这些"边角料"。这些东西在功能测试阶段一个都暴露不出来，只有跑长时间稳定性、做温度循环、做反复上下电测试的时候才一个个冒出来。所以我现在写 IIC 驱动的顺序是反过来的：先写超时和恢复，再写功能，最后写业务逻辑。前面那两块地基没打好，后面加多少功能都是在流沙上盖楼。
