I2C多主机仲裁与时钟延展：开漏输出、线与逻辑及工程避坑指南

1. 为什么多主机仲裁是 I2C 最容易被低估的机制

很多人学 I2C，第一反应是"两根线、一个主机、挂一堆从机"，然后背一遍起始条件、地址帧、ACK/NACK 就完事了。真到项目里，只要总线上出现两个主机——比如一块主控 MCU 加一颗带 I2C 接口的传感器融合芯片，或者双核系统里两个核都想访问同一片 EEPROM——问题就来了：谁先说话？说一半撞车了怎么办？数据会不会丢？

I2C 最精妙的地方恰恰在这里。它没有像 CAN 那样的显式仲裁 ID，也没有像 SPI 那样的片选线，而是靠**开漏输出加线与（wired-AND）**这个物理特性，让多个主机在电气层面"边发边听"，谁发高电平、别人发低电平，谁就立刻知道自己输了，然后自动退出。整个过程不需要任何额外的仲裁线，也不需要软件提前协商优先级。

我第一次真正理解这套机制，是在调试一个双主机的板子时。两个主机同时想读同一颗 EEPROM，逻辑分析仪抓出来的波形里，SDA 上出现了明显的"半高"毛刺，SCL 也被拉长了一段。当时以为是硬件故障，后来才反应过来：这就是仲裁丢失和时钟延展在真实波形上的样子。理解了这两件事，你再看 I2C 时序图，会发现它比教科书上画的"理想波形"有意思得多。

这篇内容我会把多主机仲裁和时钟延展这两件事拆开讲透：物理层为什么必须用开漏、仲裁到底是怎么一位一位比出来的、时钟同步和时钟延展有什么区别、实际项目里怎么用逻辑分析仪定位问题、以及那些文档里不会写但踩过就忘不掉的坑。适合已经会写 I2C 基本读写、但一遇到多主机或总线异常就抓瞎的嵌入式开发者。

2. 开漏输出与线与逻辑：仲裁能成立的物理前提

2.1 推挽输出为什么在 I2C 上会出事

先说清楚一个基础问题：为什么 I2C 的 SDA 和 SCL 必须是开漏（Open-Drain）或者开集（Open-Collector），而不能用推挽（Push-Pull）。

推挽输出的结构是上下两个管子，一个负责拉高、一个负责拉低，输出要么强驱动到 VCC，要么强驱动到 GND。如果两个推挽输出接在同一根线上，一个想输出高、一个想输出低，那就等于把 VCC 和 GND 通过两个导通的管子直接短路，瞬间大电流，轻则波形畸变，重则烧管子。

开漏输出只保留下管（NMOS 到 GND），上管被去掉，高电平靠外部上拉电阻拉上去。这样每个设备只有两种动作：拉低或者释放（高阻态）。释放的时候线由外部上拉电阻决定电平。多个开漏输出接在一起，只要有一个拉低，线就是低；全部释放，线才被上拉拉高。这就是线与逻辑。

用一句话概括：

开漏输出让"拉低"成为一种可以叠加的公共动作，任何设备都能把线拉低，但没有任何设备能强行把线拉高。这正是仲裁能成立的根本原因。

2.2 上拉电阻的取值不是随便选的

既然高电平靠上拉电阻，那这个电阻选多大就有讲究了。它直接决定了上升沿的 RC 时间常数，进而影响总线能跑多快、能挂多少设备。

上拉电阻的取值受两个约束夹击：

• 上限：由上升时间决定。I2C 标准里，标准模式（100kHz）上升时间上限 1000ns，快速模式（400kHz）是 300ns，快速模式+（1MHz）是 120ns。总线电容越大，同样的电阻上升越慢，所以电容大就得减小电阻。
• 下限：由灌电流决定。器件拉低时，电流从 VCC 经上拉电阻灌进下管，这个电流不能超过器件规格（标准模式 3mA，快速模式 6mA 左右）。电阻太小，灌电流超标，低电平可能抬不到 VOL 以下，逻辑就错了。

一个常用的估算公式是：

Rp(max) = tr / (0.8473 × Cb) Rp(min) = (VCC - VOL(max)) / IOL(max)

其中 tr 是允许的最大上升时间，Cb 是总线总电容，VOL 是低电平电压上限，IOL 是最大灌电流。实际选值一般落在 2.2k 到 10k 之间。总线短、设备少，4.7k 或 10k 都行；总线长、设备多、速度快，就得往 2.2k 甚至 1.5k 靠。

我踩过的一个坑：一块板子上 I2C 挂了 8 个器件，走线拉了将近 30cm，上拉还是照抄参考设计的 10k。结果 400kHz 下波形上升沿软得像山坡，逻辑分析仪解码时断时续。换成 2.2k 之后立刻干净。所以上拉电阻这件事，参考设计只能当起点，必须结合你的实际总线电容重新算。

2.3 总线电容是隐形杀手

总线电容来自哪里？PCB 走线（大约 1~3pF/cm）、器件引脚、连接器、排线。I2C 规范规定总线电容上限是 400pF。超过这个值，上升沿会慢到无法在规定的建立时间内稳定，仲裁和时钟都会出问题。

如果你发现总线怎么调都不稳，先别怀疑代码，拿万用表或者 LCR 表量一下总线对地电容。超过 400pF 就得想办法：缩短走线、减少挂载器件、用 I2C 缓冲器/中继器分段，或者降低速率。这是硬件层面的硬约束，软件再怎么优化也绕不过去。

3. 仲裁的完整过程：一位一位比出来的胜负

3.1 仲裁发生在哪一段

先明确一点：仲裁只发生在地址帧和数据帧阶段，起始条件（START）和停止条件（STOP）不参与仲裁。因为 START 是 SCL 高时 SDA 由高变低，所有主机都能发出，一旦有两个主机几乎同时发 START，接下来就进入地址比较。

仲裁的规则非常朴素：每个主机在发送每一位的同时，都在回读 SDA 的实际电平。如果自己发的是高（释放），但读回来是低，说明有别的设备把它拉低了，自己就输了，立刻停止发送，转为从机接收模式。

注意这里的关键：输的那一方不是"被踢出总线"，而是自动切换成接收方，继续监听总线，因为赢的那一方可能正好在寻址它。这个设计非常优雅——仲裁失败的主机不会浪费这次通信，它可能正是被寻址的对象。

3.2 一个具体的仲裁例子

假设总线上有两个主机 A 和 B，同时发起通信：

• A 想寻址设备地址0x50（二进制1010000）
• B 想寻址设备地址0x60（二进制1100000）

逐位比较（高位在前）：

在 bit5 这一位，B 释放 SDA（想发 1），但 A 把 SDA 拉低（发 0），线与结果是 0。B 回读发现是 0，和自己发的不一致，于是 B 立即停止驱动 SDA 和 SCL，退出仲裁。A 完全不知道有人和它竞争过，继续正常通信。

这就是为什么 I2C 的仲裁是"非破坏性"的：赢的一方数据完全不受影响，输的一方自动退让，总线上不会出现数据错乱。

3.3 仲裁和地址的关系：为什么地址越小优先级越高

从上面的例子能看出来，仲裁是逐位比较，谁先发出 0 谁就赢。因为 0 是"强"的（拉低），1 是"弱"的（释放）。所以地址数值越小，二进制里高位越早出现 0，优先级越高。

这个特性在实际系统里可以用来做优先级设计。比如你有两个主机，一个负责实时控制、一个负责后台日志，你希望实时控制优先，那就给它分配一个数值更小的地址。当然，前提是这两个地址不能冲突，且都在合法范围内。

提示：仲裁优先级由地址决定这件事，只在多主机同时发起时才有意义。如果两个主机访问的是完全不同的从机地址，仲裁照样会发生，只是输的那一方会等总线空闲后重试。

3.4 仲裁丢失后软件要做什么

硬件层面仲裁丢失是自动处理的，但软件层面必须知道这件事。大多数 MCU 的 I2C 外设都有一个仲裁丢失标志位（比如 STM32 的 ARLO，NXP 的 ARBL）。一旦置位，说明本机在仲裁中输了，硬件会自动释放总线并切换到从机模式。

软件要做的处理通常是：

1. 检测到 ARLO 标志，清除它。
2. 判断当前是发送还是接收状态，决定是否需要重新发起。
3. 等待总线空闲（检测 STOP 条件或总线空闲标志）。
4. 重新发起本次传输。

这里有个容易忽略的点：仲裁丢失后不要立刻重试。如果立刻重试，很可能又和对方撞上，形成活锁。正确做法是等一个随机或递增的退避时间，或者等总线明确空闲后再来。我在一个双主机项目里就吃过这个亏，两个主机互相抢，日志刷得飞快但数据一直传不出去，后来加了退避才稳定。

4. 时钟同步与时钟延展：两个容易混淆的概念

4.1 时钟同步：多主机如何统一节奏

多主机场景下，每个主机都有自己的 SCL 时钟源，频率不可能完全一致。那总线上的 SCL 到底听谁的？答案是：线与之后，谁的低电平长听谁的。

SCL 也是开漏的，每个主机在 SCL 上也是"拉低或释放"。当多个主机同时驱动 SCL 时：

• 只要有一个主机把 SCL 拉低，总线 SCL 就是低。
• 只有当所有主机都释放 SCL，总线 SCL 才被上拉拉高。

所以总线 SCL 的高电平时间，取决于最后一个释放 SCL 的主机；低电平时间，取决于第一个拉低 SCL 的主机。最终总线时钟周期等于所有主机时钟周期里最长的那个。这就是时钟同步。

时钟同步保证了即使两个主机频率不同，它们也能在同一个节奏下逐位比较，仲裁才能正常进行。如果时钟不同步，两个主机对"当前是第几位"的理解就会错位，仲裁根本没法做。

4.2 时钟延展：从机也能"踩刹车"

时钟延展（Clock Stretching）是另一回事，它通常发生在主机和从机之间。有些从机处理速度慢，比如一颗 EEPROM 写完一个字节需要几毫秒的内部擦写时间，或者一颗传感器需要时间做 ADC 转换。这时候从机可以在接收完一个字节、准备发 ACK 之前，把 SCL 拉低并保持住，强制主机等待。

主机在释放 SCL 后，会回读 SCL 电平。如果发现 SCL 还是低，就知道从机在延展时钟，于是主机进入等待，直到从机释放 SCL 才继续。整个过程对主机是透明的，主机不需要知道从机为什么要延展，只需要老老实实等。

时钟延展的典型应用场景：

• EEPROM 页写后的内部写周期
• 传感器转换等待
• 从机 MCU 中断响应慢，来不及准备数据
• 某些 RTC 芯片的寄存器更新

4.3 两者的区别用一张表说清

很多人把这两个概念混为一谈，其实它们的触发方、目的、影响范围完全不同。时钟同步是"多主机抢麦时的节奏对齐"，时钟延展是"从机举手说等一下"。

4.4 不支持时钟延展的主机怎么办

不是所有 I2C 主机都支持时钟延展。有些硬件 I2C 外设、特别是某些高速模式下的控制器，会忽略 SCL 被从机拉低的情况，继续按自己的节奏走。这时候如果从机延展了时钟，通信就会出错。

遇到这种情况有几个办法：

• 换用支持时钟延展的主机外设，或者用软件模拟 I2C（GPIO 翻转），软件模拟天然支持延展，因为每一步都回读电平。
• 降低通信速率，给从机留足时间，让它不需要延展。
• 查从机手册，看是否有"禁止时钟延展"的配置位，有些器件可以关掉。
• 如果从机是 EEPROM，用"页写 + 轮询 ACK"的方式代替等待，避免依赖延展。

我在用某款国产 MCU 的硬件 I2C 驱动一颗老式 EEPROM 时就遇到过这个问题：写页之后从机延展时钟，主机不认，直接发下一个 START，结果数据全乱。最后改成软件模拟 I2C 才解决。所以选型阶段一定要确认主机外设对时钟延展的支持情况，这个参数在数据手册里往往藏得很深。

5. 用逻辑分析仪把仲裁和延展"看"出来

5.1 抓什么波形

光看文档很难建立直觉，最好的办法是拿逻辑分析仪实际抓一次。你需要抓的是 SDA 和 SCL 两路信号，采样率至少是总线速率的 10 倍以上，400kHz 总线建议 10MS/s 以上，否则毛刺和窄脉冲会丢。

抓多主机仲裁时，重点看：

• 两个主机同时发 START 后，SDA 上是否出现某一位突然"变低"而某个主机停止驱动的痕迹。
• SCL 是否出现被拉长的低电平段（时钟同步或延展）。
• 仲裁丢失后，输的主机是否转为接收，SDA 是否继续被赢的主机驱动。

抓时钟延展时，重点看：

• ACK 位之前，SCL 是否被从机额外拉低了一段。
• 这段低电平期间，SDA 是否保持稳定（从机在准备数据）。
• 主机是否在 SCL 释放后等待，而不是强行继续。

5.2 解码器的坑

逻辑分析仪的 I2C 解码器很方便，但它有个常见问题：遇到时钟延展或仲裁时，解码可能出错或直接卡住。因为解码器默认按标准时序解析，一旦 SCL 被异常拉长，它可能把一次传输拆成两次，或者报"unexpected condition"。

我的经验是：解码器只用来快速看地址和数据，真正的时序问题必须回到原始波形上人工看。特别是仲裁丢失那一位，解码器往往直接跳过，你得自己数位。

5.3 一个真实的排查案例

之前有个项目，双主机访问同一颗 EEPROM，偶发读出的数据错位。逻辑分析仪抓了几次，发现每次出错前 SCL 都有一段异常长的低电平。一开始怀疑是从机时钟延展，但查手册发现这颗 EEPROM 不支持延展。后来仔细看波形，发现是两个主机同时发起读操作，在地址帧某一位发生仲裁，输的主机退出时 SCL 被短暂拉低，赢的主机继续。问题出在输的主机的软件没有正确处理 ARLO，退出后立刻重试，导致总线状态混乱。

解决办法是在 ARLO 处理里加总线空闲检测和退避。改完之后再抓波形，仲裁依然发生（这是正常的），但不再有数据错位。这个案例说明：仲裁本身不是 bug，对仲裁的处理不当才是 bug。

6. 工程实践中的仲裁与延展避坑清单

6.1 多主机系统的设计原则

如果你确定系统里会有多个主机，设计阶段就要考虑这几件事：

• 地址规划：给不同主机分配不同优先级的地址，重要的、实时的用更小的地址值。
• 访问分区：能不让两个主机访问同一从机就尽量分开，减少仲裁概率。仲裁虽然不破坏数据，但会增加延迟和软件复杂度。
• 退避策略：仲裁丢失后的重试必须带退避，不能裸重试。
• 总线空闲检测：重试前确认总线真的空闲，别在别人通信中途插进去。
• 超时保护：任何 I2C 操作都要有超时，防止从机或总线卡死导致整个系统挂起。

6.2 时钟延展相关的注意事项

• 主机外设是否支持时钟延展，选型时必须确认。
• 软件模拟 I2C 天然支持延展，但速率上不去，适合低速慢速器件。
• 从机延展时间过长会拖慢整个总线，必要时用轮询代替等待。
• 多主机场景下，时钟延展和时钟同步可能叠加，波形会更复杂，抓波形时要有心理准备。

6.3 常见问题速查表

6.4 我个人的几条经验

第一，不要迷信硬件 I2C。硬件外设省 CPU，但在多主机、时钟延展、异常恢复这些场景下，灵活性和可控性往往不如软件模拟。项目里如果 I2C 只是低速配置通道，软件模拟反而更省心。

第二，逻辑分析仪是必备工具。I2C 的问题几乎都能在波形上看到，靠猜和改代码效率极低。一个几百块的分析仪能省下几天调试时间。

第三，仲裁和延展要写进测试用例。很多团队只测单主机正常读写，一上多主机就出问题。测试阶段就应该构造双主机同时访问的场景，验证仲裁和退避逻辑。

第四，上拉电阻留可调空间。PCB 设计时把上拉电阻做成可更换的，或者预留并联焊盘，调试阶段能省很多事。

第五，读手册要读到"电气特性"章节。时钟延展支持、总线电容上限、灌电流能力这些关键参数都在电气特性里，很多人只看功能描述就动手，结果踩坑。

I2C 这两根线看似简单，真正把它用稳，靠的是对开漏、线与、仲裁、同步、延展这一整套机制的理解。多主机仲裁和时钟延展之所以被称为"最精妙的设计"，是因为它们用最少的硬件成本，解决了多设备共享总线的核心矛盾。把这两件事吃透，你再看任何 I2C 波形，都能读出背后的故事。