简介：面向硬件设计与嵌入式开发者的总线通信协议学习资料，聚焦 I2C 及其两个重要变体 SMBus 与 PMBus 的原理、特性与差异。内容从 I2C 的双向通信、多主控、7 位或 10 位寻址、上拉电阻与各速率等级讲起，梳理起始条件、地址帧、应答位到停止条件的完整通信流程，再延伸至 SMBus 的标准化命令集、CRC 校验与系统管理定位，以及 PMBus 在电源转换器控制、故障报告和配置灵活性上的专有设计，并对比三者在应用领域、功能特点与兼容性上的区别。资源包共 1 个 PDF 文件，约 2.58MB，内容为结构清晰的技术文档，适合作为协议选型与接口调试时的案头参考。已有 3622 人学习，可帮助读者快速建立三种协议的完整认知框架，理解其继承关系与适用边界，为电路板通信方案设计和器件选型提供依据。

1. 两根线撑起一块电路板：I2C 到底是什么

拆开任何一块稍微复杂点的电路板，你大概率会看到两根细细的走线，从主控芯片一路延伸到好几个小芯片旁边，中间还各挂着一颗电阻。这两根线，就是 I2C 总线。I2C 全称 Inter-Integrated Circuit，中文常叫集成电路间通信协议，说白了就是芯片之间聊天用的一套约定：一根线传数据（SDA），一根线传时钟（SCL），所有设备都挂在这两根线上，靠地址认领属于自己的消息。

为什么值得搞懂它？因为只要你碰过传感器、显示屏、加速度计模块，几乎一定间接用过 I2C。它把“多个芯片怎么接线、怎么对话”这件事压缩到了极致——不用像 SPI 那样每个从设备配一根片选线，两根线就能挂一串设备。而 SMBus 和 PMBus 这两个名字经常和 I2C 一起出现，很多人第一次看到就懵：它们仨是三个东西，还是一个东西的三个版本？这篇就把这条线讲透。

2. 为什么偏偏是两根线：I2C 的设计取舍

2.1 开漏输出与上拉电阻：高电平是“放”出来的

I2C 最容易被忽略、也最容易翻车的硬件细节，是上拉电阻。I2C 器件引脚采用开漏（或开集）结构，意思是芯片只能主动把线拉低，没法主动把线推高。线要变高，靠的是外部上拉电阻把它“拽”回电源电压。没有数据传输时，总线就停在高电平的空闲状态。

打个比方，总线像一根被弹簧拉起的绳子，任何设备想发“0”，就往下拽一把；想发“1”，就松手让弹簧把它拉回去。所以总线上只要有一个设备拽着，线就是低电平——这也正是多主器件仲裁能成立的基础。

上拉电阻的取值不是玄学。5V 供电的典型场景里，4.7 kΩ 是最常见的值。阻值太大，上升沿变缓，高速时波形爬不上去；阻值太小，低电平时灌电流过大，器件可能吃不消。总线长度也受电容限制，双绞线每米大约 100 pF 到 240 pF，所以 100 kbps 下总线长度大致 1 米量级，降到 10 kbps 才能拉到 10 米左右。

# 典型 I2C 上拉连接示意（文字描述） # VDD ── Rp(4.7kΩ) ── SDA ── 各器件 SDA 引脚 # VDD ── Rp(4.7kΩ) ── SCL ── 各器件 SCL 引脚 # 所有器件 GND 共地

上面这段不是可执行代码，而是把接线关系写清楚：两条线各自通过一个电阻接到 VDD，所有器件的 SDA、SCL、GND 分别并联。参数上，VDD 常见 3.3V 或 5V，Rp 从 4.7 kΩ 起步，总线设备多、走线长时再往下调。

2.2 起始、地址、应答：一次对话的完整剧本

I2C 的一次通信像一场有固定礼仪的对话。主器件先把 SDA 从高拉低、再把 SCL 拉低，发出起始条件，等于敲桌子说“我要说话了”。接着发地址帧：7 位或 10 位地址，最后一位是读/写位，0 表示要写，1 表示要读。总线上每个从器件都拿这个地址跟自己的比，对上了就把 SDA 拉低一个时钟周期，回一个 ACK；没对上就装没听见，线保持高电平。

数据帧固定 8 位，高位先发，每帧后面跟一个 ACK 或 NACK。全部发完，主器件把 SCL 拉高、再把 SDA 拉高，发出停止条件，对话结束。读操作稍微绕一点：主器件先发一次“写”方向的地址把目标指好，再用重复起始条件切换方向，重新发“读”方向地址，然后接收数据，最后一帧回 NACK 告诉从器件“够了”。

这里有个血泪经验：地址算错是新手最常见的翻车点。7 位地址 0x2D 加上写位 0，拼成 8 位是 0x5A；加读位 1 则是 0x5B。很多数据手册给的是 7 位地址，而驱动代码里要的是移位后的 8 位值，差一位就全程 NACK。

2.3 多主器件与仲裁：谁拉低谁说了算

I2C 允许总线上挂多个主器件。两个主器件同时开口怎么办？靠仲裁。每个主器件在发送的同时持续回读 SDA：如果自己想发高电平，却发现线是低的，说明别人正在拉低，自己就立刻退出，把总线让出去。赢家继续发，数据不损坏、不用重来，这套机制简单得有点优雅。

与之配套的是时钟延展：从器件处理不过来时，可以把 SCL 按住不放，主器件必须等线真正变高才继续。注意，I2C 规范本身没有给时钟延展设超时，理论上器件可以一直按着；这一点在 SMBus 里被明确加了限制，后面会讲。

3. SMBus 和 PMBus：在 I2C 上长出来的两层楼

3.1 SMBus：给系统管理加一套硬规矩

SMBus 全称 System Management Bus，系统管理总线，最常见的落脚点是计算机主板和嵌入式系统，管温度、电压、风扇这些监控量。它的物理层和 I2C 高度相似，也是两根线（SMBCLK、SMBDAT），但加了一整套“硬规矩”，让它更适合长期无人值守的系统监控。

第一个规矩是逻辑电平阈值固定，不随器件供电电压浮动。所以一条 SMBus 上可以同时挂 1.8V、3.3V、5V 供电的器件，各自电源不同也能对话。第二个规矩是超时：SMBus 规定最低时钟速度，并限制一次事务里时钟能被延展多久，10 kHz 最低时钟对应大约 35 ms 超时，超了所有器件复位 I/O 逻辑、允许总线重启。I2C 没有这个后悔药，SMBus 有，鲁棒性就是这么来的。

第三个规矩是 PEC，分组差错校验，在事务末尾加一个错误码字节，用来查传输有没有出错。此外 SMBus 要求器件每次收到自己的地址都必须应答，不管它在忙什么，这样主器件才能准确判断总线上谁还活着。它还留了一根可选信号 SMBALERT#，从器件有故障要报告时，可以主动拉这根线通知主器件，不用等主器件来轮询。

3.2 PMBus：把“电源管理”写成一套命令语言

PMBus 全称 Power Management Bus，电源管理总线，是架在 SMBus 之上的协议层。I2C 规范只描述了物理层、时序和流控制，没说消息里那些字节是什么意思；SMBus 补了一部分格式；PMBus 则直接定义了一整套命令语言，让“读输出电压”“设过压阈值”“报告故障”这些动作有了标准说法。

通俗地说，I2C 是电话线，SMBus 是电话线加一套通话礼仪，PMBus 则是在这套礼仪上再规定“你说‘电压’这个词时，对方必须理解成输出电压”。正因为命令语义统一，不同厂商的电源器件才能互操作，电源系统设计的复杂度才降得下来。

PMBus 的硬件要求也有自己的脾气：总线以 3.3V 运行为主，电源内部的 SCL/SDA 只允许弱上拉，主要上拉电阻由系统侧提供、放在电源外部；数据速率跑 100 kbps 全速，并尽量避开时钟延展，因为它会拖慢整条总线。冗余系统里，电源装进系统后最多用三根地址信号（地址 2、地址 1、地址 0）定位置；非冗余系统里，电源器件地址通常是 B0h。

3.3 三者到底怎么叠：一张表看清层级

把三者关系想成一栋楼：I2C 是地基，管电平和时序；SMBus 是一楼，加了超时、PEC、告警线和固定阈值；PMBus 是二楼，在 SMBus 之上定义了电源命令集。它们通常能共享同一条总线而不出大问题，因为电气上兼容、寻址方式一致。

这张表不是让你背，而是让你在选型时有个判断依据：只是读个传感器，I2C 足够；要做主板监控、要求故障可上报，SMBus 更稳；要统一管理一堆电源芯片，PMBus 的命令集能省掉大量私有协议。

4. 常见误区：这几个概念最容易搅在一起

4.1 误区一：SMBus 和 PMBus 是 I2C 的“竞争协议”

易混点在于三者名字并列出现，看起来像三个平级选项。之所以混，是因为很多资料把它们放在同一张对比表里。区分方法看层级：SMBus 和 PMBus 都是基于 I2C 物理层的衍生规范，不是替代品。一条总线上挂 I2C 器件和 SMBus 器件，电气上通常能共存，只是协议规矩不同。

4.2 误区二：I2C 有超时，卡住了会自己恢复

易混点来自“总线卡死”这个常见现象。之所以混，是因为很多人先接触 SMBus，把它的超时当成了 I2C 的默认行为。实际上 I2C 规范没有超时，从器件按住 SCL 不放，主器件只能干等。区分方法：如果你的系统要求总线能自恢复，要么选 SMBus 器件，要么在软件层自己加超时和总线复位逻辑。

4.3 误区三：地址 0x2D 直接写进代码就行

易混点是 7 位地址和 8 位地址字节。之所以混，是因为数据手册和驱动 API 各说各话。区分方法记住一条：总线上传输的是 8 位字段，高 7 位是地址，最低位是读写位。写操作把 7 位地址左移一位、最低位补 0；读操作补 1。看到代码里地址是手册值的两倍，别慌，那是在拼读写位。

4.4 误区四：上拉电阻随便选个 10k 就行

易混点是“上拉电阻只是把线拉高”。之所以混，是因为低速实验板上随便焊个电阻也能跑通。区分方法看速率和总线电容：速率越高、挂的器件越多、走线越长，上升沿越容易变缓，电阻要相应减小；但太小会增加低电平灌电流。4.7 kΩ 是常见起点，不是万能答案。

4.5 误区五：时钟延展是故障

易混点在于看到 SCL 被按住不动，第一反应是总线挂了。之所以混，是因为它确实表现为“时钟停住”。区分方法：时钟延展是合法机制，从器件处理不过来时主动降速；真正要警惕的是没有超时保护的无限期按住，那才是需要软件兜底的场景。

5. 什么时候用哪条总线：边界判断与一个真实取舍

选型的核心不是“哪个更高级”，而是“你的系统要不要那层额外的规矩”。只读一个温度传感器、一块 EEPROM，I2C 足够，接线简单、代码短，别为了“规范”给自己加负担。做主板级监控，要温度、电压、风扇一起管，还希望器件故障能主动报警、总线卡住能自恢复，SMBus 的超时、PEC 和 SMBALERT# 就是实打实的价值。管一堆电源转换器，要统一读写输出电压电流、设过压阈值、做故障报告，PMBus 的命令集能让你少写一堆私有协议。

反过来，什么时候别用？总线很长、速率要求高、器件又多的场景，I2C 的电容限制和开漏结构会让你很难受，这时候该考虑别的方案。对实时性要求极强、不能容忍时钟被延展拖慢的链路，也要谨慎评估 SMBus 和 PMBus 的超时与延展限制。还有一点：如果总线上混挂不同规范的器件，先确认电平阈值和上拉安排能兼容，别等到波形爬不起来才回头查。

举个模拟项目的例子。某实验室做一块多路电源监控板，最初所有器件都按 I2C 接，结果一颗电源芯片偶尔把 SCL 按住不放，主控整条总线卡死，只能断电重启。后来把电源部分换成 PMBus 器件、系统监控部分走 SMBus 规矩，超时机制让总线能自己复位，PEC 又抓出了几次偶发的传输错误。代价是代码里多了一层命令解析，但换来的是无人值守时不再需要人去拔电。

从那以后我每次画板子，只要总线上挂了电源类器件，都会先把超时和上拉这两件事在纸上过一遍，再动手写驱动。希望帮到你。

本文还有配套的精品资源，点击获取