★ FEATURED ARTICLE 做嵌入式这些年我越来越觉得 I2C 是最被低估的协议。它只有两根线SDA 负责数据SCL 负责时钟却能挂一堆外设甚至支持多个主机同时挂在总线上。很多人对 I2C 的理解停留在“主机发地址、从机回 ACK”最多再会读个 EEPROM。但真正把 I2C 用明白绕不开两个最精妙的设计多主机仲裁和时钟延展。这篇文章我就以工程师的视角把这两个机制掰开揉碎讲清楚包括它们解决什么问题、底层怎么实现、实际操作中怎么抓波形、怎么排查问题。适合刚开始学 I2C 的嵌入式新手也想给写过不少 I2C 代码、但没细想过背后机制的老手一次系统梳理。今天想聊的两个机制是 I2C 的“隐藏骨架”。我在前面先解释它们存在的必要性接下来拆解原理然后用真实调试经验带你看波形和坑。1. 为什么说这两个机制是 I2C 的“隐藏骨架”1.1 一个容易被忽略的设计事实绝大多数 I2C 教程和时序图默认都是单主机场景一个 MCU 做主下面挂 EEPROM、传感器所有时钟由主机产生从机被动响应。看起来和 SPI、UART 差不多无非是“主机说了算”。但 I2C 和它们最大的区别是它把一部分总线控制权故意交给了从机甚至允许总线上同时存在多个主机。我刚开始用 I2C 时也没意识到这一点。直到有一次做一个双 MCU 的项目两个单片机需要互相交换数据按照我当时的理解I2C 是“一主多从”的协议两个主机放在同一条总线上简直不可想象——万一两个主机同时发数据总线不就短路了吗后来查了规范才明白I2C 在设计之初就把这个问题解决了靠的就是多主机仲裁和时钟延展。这两个机制是 I2C 能成为“真正的多点多主机总线”的基础。没有它们I2C 就只能像 SPI 那样严格区分主从甚至需要额外的仲裁硬件。理解了这两个机制你再看 I2C 就会觉得它非常“聪明”协议本身不依赖中央调度器而是靠一根线上“拉了低就不放手”的物理规则把冲突消解在萌芽状态。1.2 没有仲裁和时钟延展多机系统会怎样我们可以反过来推演一下。如果没有多主机仲裁两个主机同时发起通信时SDA 上会出现两个设备同时驱动的局面。一个想发高、一个想发低如果都是推挽输出那就等效于把电源和地短接轻则数据全乱重则烧毁引脚。就算两个主机运气好没在同一时刻启动只要总线空闲检测的时间差不够也可能发生碰撞。如果没有时钟延展慢速从机就会被快速主机“欺负”。主机按自己的节奏发时钟从机这边可能还在忙上一次操作。要么从机强制响应导致数据错误要么主机只能把所有设备都按最慢的来设计牺牲总速度。比如一个总线上同时挂了高速 ADC 和慢速 EEPROM如果协议不支持从机主动拖住时钟那整个总线只能按 EEPROM 的慢速跑高速 ADC 就成了摆设。I2C 用两个机制同时解决这两个问题仲裁让多主机竞争变得“优雅”延展让快慢设备和谐共处。理解了它们的必要性下面就可以深入原理了。2. 多主机仲裁两条总线靠“线与”讲道理2.1 开漏输出与“线与”逻辑仲裁的物理基础要说仲裁必须先说 I2C 为什么能仲裁。核心在于 I2C 总线的输出结构不是推挽而是开漏加外部上拉电阻。推挽输出大家都很熟引脚要么输出高电平、要么输出低电平由内部两个晶体管交替导通实现。I2C 不一样它的 SDA 和 SCL 引脚内部只有一个下拉晶体管没有上拉晶体管。需要输出高电平时器件只是把引脚置为高阻状态让外部上拉电阻把总线拉高需要输出低电平时内部晶体管导通把总线拉低。这个结构带来一个非常重要的性质只要总线上任何一个器件拉低 SDA整条 SDA 线就是低电平其他器件即使处于释放状态也无法把总线变成高电平。这个特性叫“线与”。用生活经验来类比就像一群人过一扇门只要有一个人说“等一下”并按下暂停键整个进程就得停说“走吧”的人再多也抵消不了那一个暂停键。在 I2C 总线上拉低代表“我有话说”释放代表“我不占线”而多条线共同作用的结果是拉低者优先。正是这种“低电平优先”的物理规则让仲裁不需要额外的仲裁芯片。SPI 做不到这一点因为它的 MOSI 是推挽输出两个主机同时驱动 MOSI 时就会发生真正的电平冲突。I2C 的仲裁不是靠协议层去“排优先级”而是靠物理层天然地“线与”。2.2 仲裁过程拆解一位一位比下去有了“线与”基础仲裁过程就很清晰了。假设主机 A 和主机 B 在同一个空闲总线上同时发起 START同时开始发地址。I2C 地址是从 MSB 开始一位一位发的。以标准 7 位地址为例主机 A 想发地址 0x50二进制 1010 0000主机 B 想发地址 0x28二进制 0010 1000。第一位比特A 发 1B 发 0。B 的引脚导通把 SDA 拉低于是总线上 SDA 为低。A 本来想发 1但它在 SCL 高电平期间采样 SDA 时发现总线是低和自己发出去的电平不一致A 就知道自己“输”了立刻停止驱动 SDA从主机模式转为接收模式退出仲裁。B 则继续正常发送。再看一个更有意思的例子主机 A 发 0xA01010 0000主机 B 发 0xB01011 0000。第一位都是 1两个主机都能正常发第二位A 发 0B 发 1。因为 A 拉低了 SDAB 采样时发现自己期望的高电平被拉低于是 B 退出仲裁A 获胜。这个例子说明仲裁可能不是第一个 bit 就分出胜负而是逐位比较直到某一个 bit 出现“一个想发 1、一个想发 0”的差异想发 1 的那一方失败。仲裁的关键点在于每个主机既是发送者也是接收者。它在发送每个 bit 的同时必须采样 SDA 的状态。一旦发现总线上的电平和自己发出的不一致就说明总线上还有另一个主机在同时发送且对方这一位比自己“更强”——因为对方发出了 0把总线拉低了。这个机制不需要中央仲裁器每个主机自己就能判断胜负。2.3 仲裁失败的善后为什么不能发 STOP很多人学仲裁时容易漏掉一个细节仲裁失败的主机不能像普通错误处理那样直接发 STOP 信号。原因是现在总线已经归获胜的主机控制了地址和数据正在总线上正常传输。如果失败主机此时发一个 STOP就会向总线上的从机传递一个错误的结束信号可能让从机以为本次传输被意外终止从而破坏获胜主机正在进行的通信。正确的做法是仲裁失败的主机立刻停止驱动 SDA并转为接收模式继续接收总线上后续的地址和数据直到总线出现 STOP 信号再重新等待总线空闲准备重试自己的传输。我记得第一次写多主机代码时在仲裁失败分支里习惯性地发了 STOP结果总线上另一个主机的通信时不时被莫名其妙打断。后来用逻辑分析仪抓到真相失败主机发的 STOP 直接把获胜主机的事务给终结了。规范里其实写得很明确仲裁失败不是错误状态不能产生 STOP。这个坑纯看时序图的人是很难发现的。2.4 几种仲裁场景地址仲裁、数据仲裁与 ACK 仲裁仲裁并不只发生在地址阶段。两个主机同时访问同一个地址的从机时地址相同没分出胜负但之后的数据字节可能不同。这时数据阶段同样逐位仲裁。比如两个主机都想给同一个从机写数据一个写 0x55一个写 0xAA那在数据字节的第几位出现差异就在第几位分出胜负。ACK 位也能仲裁。如果两个主机都作为主接收器同时从同一个从机读数据那么在从机返回 ACK 的时候两个主机都会把 SDA 拉低因为 ACK 本身就是低电平“线与”后还是低两个主机都不会感知到冲突。但如果一个主机发了 ACK、另一个主机因为某种原因发了 NACK那位会出现一个拉低、一个释放的状态NACK 的一方会输。这个场景在实际系统中较少遇到但理解了“每一位都可能仲裁”你就知道 I2C 的仲裁粒度是非常细的。正是因为仲裁覆盖了地址、数据和 ACKI2C 多主机的通信完整性才有保障。SPI 没有这套机制所以 SPI 多主机要么靠片选互斥要么干脆不碰。I2C 从一开始就是为多主机准备的。3. 时钟延展从机的“暂停键”也是总线的“自适应变速箱”3.1 从机拉低 SCL主机只能等着我以前第一次听说“时钟延展”时第一反应是从机怎么可能拉低 SCLSCL 不是主机产生的吗这正是对 I2C 物理层理解不到位导致的困惑。实际上SCL 和 SDA 一样是开漏结构主机在产生时钟时也只是在“拉低”和“释放”之间切换外部上拉电阻负责把 SCL 拉高。既然 SCL 是开漏那么从机同样可以把 SCL 拉低。时钟延展的具体行为是当从机处理不过来时它会在 SCL 为低电平期间把 SCL 继续拉低不让它升高。主机这边正等着 SCL 释放却发现 SCL 一直处于低电平于是只能暂停直到从机处理完毕、释放 SCL主机才继续产生下一个时钟脉冲。打个比方主机像是一个主持人按自己的节奏报幕从机则是嘉宾。嘉宾没准备好时伸手按住主持人的话筒主持人就停下来等。从机不需要说话只需要“按住 SCL”这个动作就能让整个总线为它暂停。这个动作对总线上所有设备都是可见的是一种非常优雅的流控方式。3.2 从机为什么要延展EEPROM、ADC 和传感器从机为什么需要延展因为很多器件在响应 I2C 指令后需要一段时间做内部处理而且这个时间可能不确定。比如老式 EEPROM写入一个字节后需要几毫秒的写周期。主机如果连续写入多个字节从机根本来不及把数据真正存进存储阵列。如果没有时钟延展主机要么靠延时硬等要么依赖 EEPROM 手册里的“写周期时间”来估算。有了时钟延展EEPROM 可以在收到一个字节后拉低 SCL内部写完再释放 SCL主机天然地等待不需要额外延时。另一个典型场景是 ADC。某些 ADC 在启动转换后转换完成前是无法送出有效数据的。它会拉低 SCL表示“我还在转换先别发时钟给我”。如果主机不理解时钟延展可能会在转换未完成时强行读数据读到的自然是无效值或者直接通信失败。还有触摸控制器、温湿度传感器这类带内部 MCU 的器件启动初始化阶段动辄几十毫秒期间 I2C 接口可能处于忙状态。如果主机一上电就去访问设备会用时钟延展把总线拖住直到内部初始化完成。我调试 GT911 触摸芯片时就遇到过这种现象上电后立即读设备地址SDA 上的响应迟迟不来后来才发现是芯片内部固件还在初始化需要通过时钟延展来“等它”。3.3 时钟同步与延展叠加总线的速度以慢的那位为准时钟延展还有一个更宏观的体现多个主机同时启动时SCL 的频率也会自动“同步”。注意这里说的同步不是精确对齐而是“线与”的结果。假设主机 A 产生 100kHz 的时钟主机 B 产生 400kHz 的时钟两个主机同时开始通信。在 SCL 为高电平期间只要有一个主机想把 SCL 拉低SCL 就会被拉低而在低电平持续期间先释放的那个主机发现 SCL 还是低就会继续等待直到所有主机都把 SCL 释放。最终的 SCL 波形里高电平时间会变短低电平时间会变长总线实际频率向慢的主机靠拢。这就像两个人合唱节奏快的人发现对方还停在上一句就只能放慢等对方。I2C 总线上不同频率的主机通过这种方式自动协商出一个“公共节奏”谁也别想把节奏带得太快。再加上从机的时钟延展总线实际速度会取所有主机和所有参与通信的从机中“最慢的那一位”。这个机制对系统设计有非常实际的指导意义多主机 I2C 网络中各个主机允许配置不同的频率总线会自动降速到兼容水平。但反过来说如果你把某个主机配成 400kHz总线上却有一个从机不支持延展、且要求主机的 SCL 低电平时间不能太短那“线与”和延展依然可能让时序超出从机规格。所以设计时还是要参考所有器件的时序要求不能完全指望自动协商。3.4 硬件外设和软件模拟对时钟延展的处理差异大多数 MCU 的硬件 I2C 外设天然支持时钟延展。在硬件状态机里主机每发一个时钟都会检查 SCL 是否被从机拉低如果拉低状态机就停在当前状态直到 SCL 被释放。这个特性对程序员是透明的通常不需要额外写代码。但有两个坑。第一个坑是硬件的超时机制。很多 MCU 的 I2C 外设带总线超时检测比如超过多少时间没检测到 SCL 释放就触发超时中断。时钟延展本质上是合法等待如果超时时间设置得太短正常的时钟延展会被误判为总线错误。我之前用某款 MCU 时默认超时寄存器是 0也就是不检测一切正常后来为了可靠性开了超时检测结果遇到一个慢速传感器正常的延展被当成故障触发查了大半天才发现超时阈值配得太紧了。第二个坑是软件模拟 I2C。用 GPIO 模拟 I2C 时必须自己处理时钟延展在拉高 SCL 之后不要立刻认定 SCL 已经是高电平而要用一个循环去检测 SCL 引脚是否真的变成高电平。如果从机正在延展SCL 引脚会被拉低程序就得等一下。// 软件模拟 I2C 发一个时钟周期兼容从机时钟延展 void i2c_delay_clock_high(void) { uint16_t timeout 10000; // 释放 SCL让线上拉电阻把 SCL 拉高 GPIO_SCL_HIGH(); // 等待 SCL 真正变高从机可能延展导致 SCL 持续为低 while (GPIO_SCL_READ() 0) { if (timeout-- 0) return; // 超时处理 } }这段代码就是时钟延展处理的核心。很多软件模拟 I2C 的代码没有这一步直接延时后拉低 SCL结果就是和某些支持延展的从机通信时数据错乱。4. 实操抓仲裁波形、排查总线卡死4.1 手把手抓一次仲裁过程前面讲了这么多原理实际调试中怎么确认仲裁真的发生了最好的方式是用逻辑分析仪抓波形。我一般这样操作找两块开发板都作为 I2C 主机挂到同一条总线上再接一个逻辑分析仪。程序里让两个主机在空闲总线触发后几乎同时发起 I2C 写操作一个写从机地址 0xA0另一个写 0xB0。然后观察逻辑分析仪抓到的波形。在波形上你会看到一开始 SCL 和 SDA 都处于空闲高电平两个主机同时拉低 SDA 发起 START接着开始发地址。由于 0xA0 和 0xB0 的第一位都是 1SDA 在第一拍看起来是正常的到第二拍0xA0 的主机拉低 SDA0xB0 的主机希望 SDA 是高但实际读到低于是 0xB0 主机退出仲裁。如果逻辑分析仪足够精细你甚至能在 SDA 波形上看到这一拍的变化点SDA 在 SCL 高电平期间保持低而后续的地址位只剩获胜主机的信号在继续。实操建议逻辑分析仪采样率至少在 10MHz 以上否则很难看清位级别的竞争。两个主机最好用外部中断或定时器对齐触发保证同时启动的概率。仲裁失败后获胜主机会继续完成整个事务失败主机的波形会“消失”这是正常现象。我抓完一次仲裁波形之后最大的感受是仲裁根本不是“谁先抢到谁赢”而是“谁在这一位上更低谁赢”。仲裁结果取决于数据内容本身而不是主机的优先级配置这个特性决定了 I2C 多主机设计是去中心化的。4.2 异常排查总线卡死、通信失败问题速查实际项目中I2C 出问题最多的场景不在多主机制本身而在“看得到现象、摸不到原因”。我整理了一张常见问题速查表都是自己踩过或帮别人排查过的。现象可能原因排查方向多主机总线偶尔数据错乱上拉电阻偏大或偏小导致仲裁窗口的上升沿不满足时序用示波器看 SDA 上升沿检查上拉阻值和总线电容总线一直卡在低电平某个从机拉死了 SCL 或 SDA时钟延展后未能释放逐个断开从机定位检查从机复位时序和电源软件模拟 I2C 与某从机通信失败没有处理时钟延展主机不等 SCL 释放就继续发在 SCL 释放后增加读取检测兼容延展ESP32 休眠唤醒后 I2C 无法工作外设状态机未复位或者引脚方向配置被休眠机制打断唤醒后删除 I2C 驱动重新安装重新初始化引脚GT911 触摸 I2C 通信失败芯片复位/初始化期间需要时间或者地址引脚配置不对确认 INT 引脚地址选择、上电后延时再访问PC 端 I2C HID 设备报代码 12驱动资源冲突或总线资源分配问题优先查驱动和系统设备资源与 I2C 仲裁关系不大这里特别想提醒两个细节。第一个是总线卡死在低电平这是 I2C 调试里最让人头疼的问题。总线只有两根线SCL 或 SDA 被拉死后连 START 信号都发不出去。排查时不要先改代码先用万用表测 SCL 和 SDA 的对地电压。两根线都是低电平说明总线上有器件在拉低。逐个断开设备或用飞线挑开某个器件的 SDA/SCL 引脚很快就能定位到罪魁祸首。很多从机在异常复位时会把总线拉死比如电源跌落、复位时序不对这些问题用逻辑分析仪只能确认“卡死”要定位根因还得查每个器件的供电和复位。第二个是 ESP32 休眠唤醒后 I2C 外设的“假死”。ESP32 的 I2C 外设在休眠唤醒后内部状态机有时不能自动恢复到可用状态。表现是 i2c_master_cmd_begin 返回成功或超时但总线上完全没波形。解决办法不是反复调用读写函数而是把 I2C 驱动整个删掉重新安装i2c_driver_delete(I2C_NUM_0); i2c_driver_install(I2C_NUM_0, I2C_MODE_MASTER, 0, 0, 0);踩过这个坑之后我在所有使用 I2C 外设的低功耗项目里都把“休眠前关闭外设、唤醒后重新初始化”写成了标准流程。4.3 上拉电阻与总线电容的工程取值既然仲裁和时钟延展都依赖开漏加外部上拉那上拉电阻的取值就很重要。电阻太大上升沿太慢忙等时钟释放时容易误判电阻太小总线上设备的灌电流会超规格低电平时可能抬不高。上拉电阻的最大值由总线上升沿时间和总线等效电容决定。I2C 规范规定标准模式最大上升时间 1μs快速模式 300ns。总线电容包括器件引脚电容、PCB 走线寄生电容和连接器电容常见值在 100pF 到 300pF 之间。粗略估算最大电阻可用Rmax tr / (0.8473 × Cbus)例如快速模式 tr300ns假设 Cbus150pFRmax 大约在 2.4kΩ 左右。如果 Cbus 更大比如 300pFRmax 就只能取 1.2kΩ 左右。这也是为什么快速 I2C 总线上经常看到 2.2kΩ 甚至 1kΩ 电阻的原因。上拉电阻的最小值则由器件低电平输出能力决定。I2C 器件在 SDA0 时要能灌入至少 3mA 电流同时保证输出低电平不超过 0.4V。在 3.3V 电源下Rmin 大约等于 (3.3V - 0.4V) / 3mA约 1kΩ。所以如果总线电容不大4.7kΩ 是 100kHz 系统里的万金油但如果跑 400kHz最好用 2.2kΩ。真正的取值需要根据实际总线的器件数量和线长做一下估算不要迷信某个固定阻值。我在实际设计里还会注意一个细节不同供电电压的器件混合挂在同一条 I2C 总线上时上拉电阻接哪个电源很关键。如果主机是 3.3V、从机是 1.8V而 SDA/SCL 同时接两个电源的上拉就会在两个电源之间形成漏电路径导致高电平电压异常。这种场景要么统一上拉到低电压电源要么用 I2C 电平转换芯片不能直接硬接。5. 最后多说几句前前后后调过不少 I2C 问题我想说多主机仲裁和时钟延展这两个机制才是 I2C 真正的灵魂。仲裁不是靠“谁嗓门大”来决定而是靠物理层“低电平优先”配合每个发送器自省时钟延展也不是从机在闹脾气而是从机唯一能主动掌控总线的“暂停键”。它们合在一起让 I2C 成为了一条真正能“多主共存、快慢共处”的总线。如果说还有什么个人体会那就是遇到 I2C 问题时先把逻辑分析仪接上把波形抓出来再说话。软件上反复改超时、改延时往往掩盖了真正的物理层问题。理解了仲裁和延展之后很多之前觉得“玄学”的 I2C 故障其实都不过是最基本的线与逻辑在起作用。多主机系统里规则永远是明确的谁拉得越低谁就走得下去谁愿意等待谁才能真正拥有这条总线。
阅读完成 · 觉得有帮助？
