I2C总线深度解析：开漏物理层、多主仲裁与SCL/SDA时序实战

1. 为什么两根线能撑起整个嵌入式世界I2C 这东西刚入行的时候觉得它简单得不行——两根线一根 SCL 一根 SDA挂一堆设备上去就能通信。真到调试的时候才发现十个通信问题里有六个出在 I2C 上而且症状千奇百怪有的设备上电能用、跑一会儿就死有的单独测试没问题、一挂上第二个从机就开始丢数据还有的明明示波器看波形挺漂亮逻辑分析仪就是解不出正确的帧。这些问题追到根上几乎都绕不开三个东西开漏物理层、时序参数、多主仲裁。这篇东西我打算用一周的节奏把 I2C 从最底层的电气特性一路讲到多主机竞争总线时的仲裁机制中间穿插大量实测波形和踩坑记录。不管你是刚接触 I2C 的新手还是已经用过几十颗 I2C 器件、但一直没搞明白“为什么这里必须加上拉电阻”“为什么时钟拉伸会导致通信失败”的老手都能从里面找到对你有用的部分。核心关键词就五个I2C、开漏物理层、多主仲裁、SCL、SDA全文围绕它们展开不跑题。先给个整体认知I2C 是 Philips现在的 NXP在 1980 年代搞出来的二线制串行总线设计初衷是让主板上的各种芯片用最少的引脚互相通信。它的物理层是开漏输出加外部上拉协议层是主从架构加地址寻址扩展层是多主仲裁加时钟同步。这三层叠在一起才构成了完整的 I2C。很多人只学了协议层会发 START、会读写寄存器就觉得掌握了 I2C结果一遇到总线锁死、仲裁丢失、上升沿太慢的问题就抓瞎。所以这一周的内容我会把三层都拆开讲透。适合谁看做嵌入式固件的、画原理图的硬件工程师、调驱动的 Linux BSP 工程师、玩 FPGA 想自己写 I2C 控制器的还有那些被 GT911 触摸屏、SSD1306 OLED、EEPROM 读写折磨过的朋友。文章里所有代码和参数都是可以直接抄作业的示波器截图我会用文字描述关键特征逻辑分析仪的解析结果也会给出判断依据。2. 开漏物理层I2C 一切特性的地基2.1 开漏输出到底“开”的是什么先把概念说清楚。开漏Open-Drain指的是 MOS 管的漏极没有内部上拉只留一个引脚出来。对于 NMOS 来说栅极给高电平漏极就被拉到地导通栅极给低电平漏极就悬空高阻。所以开漏输出只有两种状态强下拉到地或者高阻态。它自己产生不了高电平高电平必须靠外部上拉电阻拉到 VCC。I2C 的 SCL 和 SDA 都是这种结构。每个挂在总线上的设备引脚内部都是一个开漏 NMOS谁都可以把线拉低但谁都不能主动把线拉高。这个设计带来一个极其重要的结果线与逻辑。只要有一个设备把线拉低整条线就是低只有当所有设备都释放高阻时线才被上拉电阻拉高。为什么非要这么设计因为 I2C 允许多个设备共享同一根线。如果用推挽输出一个设备输出高、另一个输出低两个 MOS 管直接对穿瞬间大电流烧管子。开漏从物理上杜绝了这种冲突这是 I2C 能挂几十个设备还不炸的根本原因。2.2 上拉电阻怎么算不是随便选个 4.7k 就完事新手最常听到的一句话是“I2C 上拉用 4.7k”。这话对但只对了一部分。4.7k 是 100kHz 标准模式下的经验值到了 400kHz 快速模式、1MHz 快速模式4.7k 可能就太大了上升沿爬不上去波形变成圆角从机采样出错。上拉电阻的取值受两个约束夹击下限由灌电流决定上限由上升时间决定。先说下限。I2C 规范规定标准模式和快速模式下器件拉低时引脚能承受的最大灌电流是 3mA快速模式是 20mA但一般不会用到这么大。总线电压 VDD 通常是 3.3V 或 5V。假设 VDD3.3VVOL低电平电压最大允许 0.4V那么上拉电阻最小值Rmin (VDD - VOL) / IOL (3.3 - 0.4) / 3mA ≈ 967Ω所以 3.3V 系统里上拉电阻不能小于约 1k否则灌电流超标长期运行可能损伤器件。再说上限。I2C 的上升时间 tr 有明确要求标准模式 1000ns快速模式 300ns快速模式 120ns。上升时间由 RC 充电决定公式是tr ≈ 0.847 × R × C其中 C 是总线总电容包括 PCB 走线电容、引脚电容、器件电容。规范规定总线电容上限是 400pF。假设你的总线电容实测 100pF快速模式要求 tr ≤ 300ns那么R ≤ tr / (0.847 × C) 300ns / (0.847 × 100pF) ≈ 3.54kΩ所以 100pF 总线电容、400kHz 速率下上拉电阻要小于 3.5k。如果你用了 4.7k上升时间会到约 400ns超规波形圆角通信可能时好时坏。实际选值就是在这两个边界之间取一个折中。我一般这样操作总线速率总线电容推荐上拉说明100kHz100pF4.7k标准模式余量足100kHz200~400pF2.2k电容大需要更强上拉400kHz100pF2.2k~3.3k快速模式常用值400kHz200pF1.5k接近下限注意灌电流1MHz50pF1k快速模式走线要短注意上拉电阻不是越小越好。太小会导致低电平灌电流过大器件发热甚至拉不到足够低的 VOL反而让从机识别不出低电平。我见过有人为了“波形好看”直接上 470Ω结果从机直接不响应。2.3 总线电容是隐形杀手总线电容这个东西原理图上根本看不到但它决定了你的上拉电阻能不能用、波形能不能看。每一段 PCB 走线大约 1~3pF/cm每个器件的引脚电容 5~10pF连接器、过孔、探头都会贡献电容。挂 10 个器件、走线 20cm轻松就上 150pF。电容大了会怎样上升沿变缓波形从方波变成指数上升的圆弧。在圆弧还没爬到 VIH高电平输入阈值通常 0.7×VDD的时候从机如果采样就会读到不确定的值。更隐蔽的问题是慢上升沿会让总线更容易受到串扰和噪声影响因为高阻态持续时间变长了。实测判断方法用示波器看 SCL 和 SDA 的上升沿。如果上升沿明显是圆弧而且从 0.3×VDD 爬到 0.7×VDD 的时间超过规范值那就是电容太大或者上拉太弱。解决办法有两个减小上拉电阻或者用 I2C 缓冲器/中继器把总线分段每段单独上拉。2.4 开漏带来的“线与”如何支撑多设备共存回到线与逻辑。假设总线上挂了三个设备 A、B、CSDA 线被上拉电阻拉到 VDD。A 想发数据 1它就释放 SDA高阻此时如果 B 和 C 也释放SDA 就是高如果 B 想发 0它把 SDA 拉低那么不管 A 和 C 怎么释放SDA 都是低。这就是线与任何一个设备拉低总线就是低全部释放总线才高。这个特性直接支撑了两个关键机制多主仲裁和时钟拉伸。仲裁的时候多个主机同时发数据谁发 1 谁发 0 一目了然发 1 的那个发现总线是低就知道自己输了主动退出。时钟拉伸的时候从机把 SCL 拉低主机发现 SCL 没按自己预期变高就知道从机还没准备好乖乖等着。这两个机制后面会详细讲但它们的物理基础都是开漏加线与。3. 协议层拆解START、地址、ACK 和那些容易忽略的细节3.1 起始和停止条件不是随便拉一下就行I2C 的 START 条件定义是SCL 为高时SDA 由高变低。STOP 条件是SCL 为高时SDA 由低变高。注意这两个条件都要求 SCL 先处于高电平然后 SDA 发生跳变。如果 SCL 是低的时候 SDA 跳变那只是普通的数据位变化不是起始或停止。为什么这么定义因为正常数据传输时SDA 只在 SCL 低电平期间变化SCL 高电平期间 SDA 必须稳定。START 和 STOP 故意打破这个规则让从机能够区分“这是帧的开始/结束”和“这是普通数据”。时序参数上START 条件有一个保持时间 tHD;STA标准模式最小 4.0μs快速模式 0.6μs。意思是 SDA 变低之后SCL 还要保持高至少这么久从机才能可靠识别。STOP 条件有建立时间 tSU;STO标准模式最小 4.0μs快速模式 0.6μs。这些参数在写 FPGA 或 GPIO 模拟 I2C 的时候必须严格遵守否则从机可能漏掉起始条件。我踩过的一个坑用 GPIO 模拟 I2CSTART 的时候先把 SCL 拉低、再拉 SDA 低、再拉 SCL 高顺序错了结果从机一直不响应。正确的顺序是确保 SCL 和 SDA 都是高空闲态然后拉低 SDA再拉低 SCL。停止则反过来先拉高 SCL再拉高 SDA。3.2 7 位地址和读写位一个字节里的乾坤标准 I2C 用 7 位地址加上一位读写位凑成一个字节。地址占 bit7~bit1读写位占 bit0。读写位 0 表示写1 表示读。所以一个从机的 7 位地址如果是 0x3C比如 SSD1306 OLED写操作发送的字节是 0x78读操作是 0x79。这里有个常见误区很多人把 0x3C 直接当成“写地址”把 0x3D 当成“读地址”其实 0x3C 是 7 位地址本身0x78 和 0x79 才是加上读写位后的完整字节。数据手册里有时写 7 位地址有时写 8 位地址看的时候要分清。GT911 触摸屏的地址是 0x5D 或 0x14取决于上电时 INT 引脚的状态这个后面讲排查的时候会细说。地址传输之后从机如果存在并且准备好会在第 9 个时钟周期把 SDA 拉低这就是 ACK。如果从机不存在或者忙SDA 保持高就是 NACK。主机收到 NACK 后通常要发 STOP 或者重复 START 来终止或重试。3.3 数据帧格式从机寄存器地址怎么传以读写 EEPROM 为例典型流程是这样的写操作START发送设备地址 写位比如 0xA0等待 ACK发送寄存器/存储地址高字节等待 ACK发送寄存器/存储地址低字节等待 ACK发送数据字节等待 ACKSTOP读操作稍微绕一点需要先写地址再读数据START发送设备地址 写位等待 ACK发送寄存器/存储地址高字节等待 ACK发送寄存器/存储地址低字节等待 ACK重复 START发送设备地址 读位0xA1等待 ACK读取数据字节主机发 NACK表示最后一个字节STOP这个“写地址-重复START-读数据”的模式是 I2C 读操作的经典套路几乎所有带寄存器地址的 I2C 器件都这么用。Verilog 写 I2C 控制器的时候状态机要专门处理这个重复 START不能先发 STOP 再发 START否则某些器件会复位内部地址指针。3.4 时钟拉伸从机也会“踩刹车”时钟拉伸Clock Stretching是 I2C 里一个很特别的设计从机可以把 SCL 拉低强制主机等待。这通常发生在从机需要更多时间处理数据的时候比如 EEPROM 写完一个页需要几毫秒的内部擦写或者传感器转换还没完成。主机怎么知道从机在拉伸主机释放 SCL 后本来期望它被上拉电阻拉高但如果从机还拉着 SCL 低主机读回的就是低。主机必须检测这个状态并且等待 SCL 真正变高之后才开始下一个时钟周期。很多用 GPIO 模拟 I2C 的代码不处理时钟拉伸因为主机拉高 SCL 后直接延时固定时间就认为 SCL 高了根本不读回。这在从机不拉伸的时候没问题一旦从机拉伸主机就会在 SCL 还没高的时候继续操作导致通信错乱。正确的做法是主机释放 SCL 后循环读取 SCL 引脚直到读到高电平再继续。提示不是所有从机都支持时钟拉伸但主机最好都支持。你不需要为每个从机都处理但代码里加上这个检测遇到支持的从机就不会翻车。4. 多主仲裁两个主机抢总线时发生了什么4.1 仲裁的物理基础线与逻辑再立功多主仲裁是 I2C 最精妙的设计之一。假设两个主机同时想发数据它们都发了 START然后开始逐位发送地址和数据。每个主机在发送每一位的同时也在读回 SDA 线的实际电平。因为 SDA 是线与逻辑如果主机 A 发 1释放 SDA主机 B 发 0拉低 SDA那么总线上实际是 0。主机 A 读回 0发现自己发的是 1 但总线是 0就知道自己输了仲裁立刻停止发送转为从机接收模式。主机 B 读回 0发现自己发的是 0总线也是 0继续发送。这个过程逐位进行直到只剩一个主机。输掉仲裁的主机不会损坏数据因为赢的那个主机发的数据本来就是总线上实际呈现的数据。仲裁可以在地址阶段发生也可以在数据阶段发生完全由线与逻辑自动完成不需要额外的仲裁线。4.2 仲裁丢失后的处理不能立刻重试仲裁丢失的主机必须立刻释放 SDA 和 SCL并且不能再发任何数据。但它不能马上重新发起 START因为赢的主机还在通信中。它必须等到总线空闲检测到 STOP 条件之后才能再次尝试。这里有个细节仲裁丢失的主机怎么知道总线什么时候空闲它需要持续监测 SCL 和 SDA直到看到 STOP 条件SCL 高时 SDA 由低变高。有些 I2C 控制器硬件会自动处理这个软件模拟的话要自己写状态机。我遇到过一个真实案例两个 MCU 通过 I2C 共享一个 EEPROM都做主机。其中一个 MCU 的 I2C 驱动没有正确处理仲裁丢失输了之后立刻重试结果和赢的主机反复冲突总线一直处于忙状态两个 MCU 都读不到数据。后来在驱动里加了“仲裁丢失后等待 STOP 再重试”的逻辑问题解决。4.3 时钟同步多主机如何统一节奏多主机的时候SCL 也是线与的。每个主机都有自己的 SCL 时钟但总线上的 SCL 是所有主机 SCL 的线与结果。具体来说SCL 高电平期间只要有一个主机把 SCL 拉低总线 SCL 就是低所有主机都释放SCL 才高。这就产生了时钟同步低电平周期由拉低时间最长的主机决定高电平周期由释放最早的主机决定。最终总线上的 SCL 频率会比任何一个主机的单独频率都低但所有主机都能正确识别每一位。这个机制保证了多主机环境下即使各主机时钟频率有差异也能正常通信。4.4 多主仲裁的边界条件什么时候会出问题多主仲裁虽然优雅但有几个边界条件容易出问题第一仲裁丢失后的重试时机。前面说了必须等 STOP。如果输的主机在赢的主机发重复 START 的时候误判为空闲就会冲突。第二时钟拉伸和仲裁的交互。如果一个主机在仲裁过程中被从机拉伸了时钟它的状态机会不会乱这取决于实现。硬件 I2C 控制器一般没问题软件模拟要小心。第三总线锁死。如果某个从机在通信中途复位把 SDA 一直拉低总线就锁死了。主机发 START 也没用因为 SDA 已经是低START 条件SCL 高时 SDA 由高变低无法产生。解决办法是主机发送 9 个时钟脉冲让从机把剩余的数据位发完然后发 STOP。如果还不行只能硬件复位或者断电重启。5. 实操用逻辑分析仪抓一次完整的 I2C 通信5.1 接线和触发设置逻辑分析仪抓 I2C接线很简单通道 0 接 SCL通道 1 接 SDA地线接好。采样率建议至少是 SCL 频率的 10 倍100kHz 的 I2C 用 1MHz 采样率就够400kHz 用 4MHz 以上。触发条件设成 SDA 下降沿START 条件或者直接设成 SCL 的某个边沿。我习惯用 Saleae 或者类似的逻辑分析仪软件里直接选 I2C 协议解析器设置好 SCL 和 SDA 通道它就会自动把波形解析成地址、数据、ACK/NACK。如果解析不出来先检查接线和采样率再检查上拉电阻和波形质量。5.2 解析一次 EEPROM 写操作假设我们往地址 0xA0 的 EEPROM 的 0x0010 地址写 0x55逻辑分析仪应该解析出这样的序列序号内容说明1STARTSCL 高时 SDA 下降20xA0设备地址 写位3ACK从机拉低 SDA40x00存储地址高字节5ACK从机拉低 SDA60x10存储地址低字节7ACK从机拉低 SDA80x55数据9ACK从机拉低 SDA10STOPSCL 高时 SDA 上升如果第 3 步是 NACK说明从机没响应检查地址对不对、从机有没有上电、上拉电阻有没有焊。如果第 5 或第 7 步 NACK可能是存储地址超出范围。如果第 9 步 NACK可能是 EEPROM 正在忙上一笔写还没完成需要等几毫秒再试。5.3 用示波器看波形质量逻辑分析仪看协议示波器看电气。重点看三个东西第一上升沿时间。从 0.3×VDD 到 0.7×VDD 的时间对比规范值。超了就要减小上拉电阻或者缩短走线。第二低电平电压。从机拉低时VOL 应该在 0.4V 以下3.3V 系统。如果接近 0.4V 甚至更高说明灌电流太大或者上拉太小。第三过冲和振铃。上升沿如果有明显的过冲和振铃说明走线阻抗不匹配或者上拉太强。可以在上拉电阻上串一个小电阻比如 100Ω来抑制但会稍微增加上升时间。5.4 常见波形异常对照表波形现象可能原因解决办法上升沿圆弧爬不到 VDD上拉太大或总线电容太大减小上拉分段加缓冲器低电平不到 0.4V 以下上拉太小灌电流过大增大上拉电阻SCL 被拉低很久不释放从机时钟拉伸主机等待检查从机状态SDA 一直低START 发不出总线锁死发 9 个时钟脉冲或复位从机ACK 位是高NACK从机没响应检查地址、电源、上拉数据位偶尔错上升沿太慢或噪声检查上拉、走线、屏蔽6. 那些年我踩过的 I2C 坑和排查思路6.1 GT911 触摸屏通信失败地址不是固定的GT911 这颗触摸屏控制器I2C 地址由 INT 引脚在上电复位时的状态决定。如果 INT 在上电时被拉低地址是 0x5D如果 INT 被拉高地址是 0x14。很多新手照着别人的原理图抄INT 引脚接法不一样结果地址对不上一直 NACK。排查方法上电后用逻辑分析仪抓看主机发的地址是什么再看 GT911 数据手册确认当前 INT 状态对应的地址。如果地址不对要么改软件里的地址要么改硬件 INT 的上拉/下拉。6.2 SSD1306 OLED 显示花屏时钟拉伸没处理SSD1306 在某些命令处理时会拉伸时钟。如果主机的 I2C 驱动不处理时钟拉伸就会在 SCL 还没释放的时候继续发下一个字节导致 SSD1306 收到错乱的数据显示花屏或者不显示。解决办法在 GPIO 模拟 I2C 的代码里每次释放 SCL 后循环读 SCL 引脚直到它为高。硬件 I2C 控制器一般自带这个处理但有些低端 MCU 的硬件 I2C 也不支持需要查手册确认。6.3 I2C 扩展多路复用TCA9548A 的用法当总线上挂太多同地址器件或者总线电容太大就需要 I2C 多路复用器比如 TCA9548A。它本身是一个 I2C 从机地址 0x70~0x77 可配通过写它的寄存器来选择哪一路通道导通。每个通道下面可以挂一组同地址的器件互不干扰。用法主机先写 TCA9548A选择通道 0然后和通道 0 下面的器件通信要切到通道 1再写一次 TCA9548A。注意每次切换通道后要给总线一点稳定时间而且切换通道时不能有正在进行的通信。6.4 PMBus 和 I2C 的区别PMBus 是建立在 I2C 物理层之上的电源管理协议电气特性和 I2C 兼容但协议层有区别PMBus 有专门的命令集支持 PEC包错误校验有更严格的时序要求。很多电源芯片同时支持 I2C 和 PMBus用 I2C 读写也能工作但用 PMBus 命令能获得更多功能比如读输出电压、电流、温度。如果你只是简单配置电源芯片用 I2C 读写寄存器就够了。如果需要动态监控和故障管理建议用 PMBus 命令集。6.5 常见问题速查表问题现象排查方向快速验证完全无响应电源、地址、上拉示波器看 SCL/SDA 有没有波形偶尔 NACK时序、上拉、总线电容逻辑分析仪看哪一步 NACK通信一段时间后死总线锁死、从机复位看 SDA 是否一直被拉低多主机冲突仲裁处理、重试逻辑抓两个主机的 START 时序读写数据错位时钟拉伸、重复 START检查从机是否支持拉伸波形过冲上拉太强、走线太长串 100Ω 电阻试试7. 从 Verilog 到 Linux 驱动不同层面的 I2C 实现要点7.1 Verilog 写 I2C 控制器的状态机设计用 FPGA 写 I2C 控制器核心是一个状态机。典型状态包括IDLE、START、SEND_ADDR、WAIT_ACK、SEND_DATA、READ_DATA、STOP。每个状态控制 SCL 和 SDA 的输出并且采样 SDA 判断 ACK。关键点SCL 的生成要用计数器分频保证频率准确。SDA 的输出要在 SCL 低电平期间变化SCL 高电平期间保持稳定。ACK 采样要在第 9 个 SCL 高电平期间进行。时钟拉伸检测要在释放 SCL 后读回 SCL 引脚。一个常见的坑状态机在 WAIT_ACK 状态没有超时机制如果从机一直不响应状态机就卡死。加一个超时计数器超过一定时间就发 STOP 并报错。7.2 Linux I2C 驱动设备树和 i2c-devLinux 下用 I2C最简单的方式是通过 i2c-dev 接口在用户空间用 ioctl 读写。设备树里配置 I2C 控制器和从机地址驱动加载后生成 /dev/i2c-N 设备节点。用户程序用 open、ioctl(I2C_SLAVE, addr)、read/write 来通信。如果要写内核驱动用 i2c_driver 结构体注册probe 函数里用 i2c_smbus_read_byte_data 等函数读写。注意内核空间的 I2C 访问不能睡眠的上下文要用原子操作能睡眠的上下文可以用普通操作。7.3 逻辑分析仪分析 I2C 数据的技巧逻辑分析仪抓 I2C除了看协议解析还可以用搜索功能找特定地址或数据。比如你想知道哪个主机在访问 0x50就搜索 0xA0 或 0xA1。如果解析出来的数据是乱的先检查采样率是不是够再检查 SCL 和 SDA 有没有接反。对于长时序的抓取可以设置触发条件为“地址匹配”只抓特定从机的通信避免数据太多看不过来。8. 一周学习路径建议如果你真想一周把 I2C 吃透我建议这样安排第一天搞懂开漏物理层算一遍上拉电阻用示波器看波形。第二天读一遍 I2C 规范里的时序图把 START、STOP、ACK、数据位的时序参数记下来。第三天用 GPIO 模拟 I2C 读写一个 EEPROM不调库自己写时序。第四天用逻辑分析仪抓自己的波形对照规范检查。第五天研究多主仲裁和时钟拉伸找两个主机试试冲突场景。第六天看 Linux 或 FPGA 的 I2C 实现对比自己的代码。第七天复盘所有踩过的坑整理成自己的检查清单。这一周下来你对 I2C 的理解会从“会调库”变成“知道每一根线为什么这么动”。后面再遇到 GT911 不响应、SSD1306 花屏、EEPROM 写不进去你都能自己定位到物理层还是协议层还是仲裁层的问题。我个人在实际操作中的体会是I2C 的问题百分之八十出在物理层百分之十五出在时序参数只有百分之五是真的协议逻辑错误。所以每次调试 I2C先看波形再看时序最后才查代码。这个顺序能帮你省下大量时间。