3. I2C 寻址机制：7位与10位地址格式、广播地址、保留地址、地址冲突与仲裁
说到 I2C 寻址，很多工程师第一反应就是「从机地址嘛，7位还是10位，配对了就行」。但实际调试中，地址问题引发的故障远比想象中多。我见过不少项目，板子焊完死活不通，最后发现是地址冲突——两个从机抢同一个地址，总线直接瘫痪。
这一章，我们就来把 I2C 寻址的底裤扒干净。从地址格式到仲裁机制，我会结合实战中踩过的坑，帮你彻底搞懂。
3.1 7位地址格式：最常用的寻址方式
I2C 总线最经典的寻址方式就是 7 位地址。主机发送起始条件后，紧跟着发送的第一个字节就是地址字节。
地址字节的结构是这样的：
| 位 | 7 (MSB) | 6 | 5 | 4 | 3 | 2 | 1 | 0 (LSB) |
|---|---|---|---|---|---|---|---|---|
| 含义 | 7位从机地址 (A6~A0) | R/W# | ||||||
注意，这个字节的高 7 位才是真正的从机地址，最低位是读写标志位：0 表示主机要写，1 表示主机要读。
举个例子，一个温度传感器地址是 0x48（二进制 1001000），那么主机要读取它时，发送的地址字节就是 0x91（10010001）。
关键点：很多新手在代码里直接写从机地址 0x48，然后发现读操作不对。其实底层库已经把地址左移了一位，把 R/W# 位补在最低位。你写 0x48，库函数自动变成 0x90（写）或 0x91（读）。
我个人习惯在数据手册里先确认从机地址的完整 7 位值，再去看驱动代码怎么处理移位。有一次我调试一个加速度计，手册写地址是 0x1D，但代码里写的是 0x3A。查了半天才发现，驱动库已经做了左移一位的处理，0x1D << 1 = 0x3A。嗯，这个坑踩过一次就不会忘了。
3.2 10位地址格式：什么时候用？
7 位地址最多支持 112 个设备（去掉保留地址后），对于大多数场景够用了。但有些复杂系统——比如服务器主板、基站设备——挂的 I2C 设备太多，7 位地址就不够分。
10 位地址的格式比较特殊，它需要两个字节来传输：
| 字节 | 位 | 说明 |
|---|---|---|
| 第一个字节 | 7:5 = 11110 4:0 = 地址高两位 (A9:A8) |
11110 是 10 位地址的标识码，后面跟地址高两位 |
| 第二个字节 | 7:0 = 地址低八位 (A7:A0) | 完整的低 8 位地址 |
主机发送第一个字节时，格式是：11110 A9 A8 R/W#。从机识别到 11110 前缀，就知道后面还要再收一个字节才能得到完整地址。
实战建议：10 位地址的从机在应答机制上有些特殊。第一个字节的应答来自所有匹配高两位地址的从机，第二个字节的应答才来自最终匹配的从机。调试时如果发现应答时序异常，先检查是不是 10 位地址的从机没有正确识别第二个字节。
我记得有一次帮客户调试一个电源管理芯片，芯片手册明确写的是 10 位地址。客户用逻辑分析仪抓波形，发现第一个字节发完有 ACK，第二个字节发完也有 ACK，但后续数据传输就是不对。我让他检查从机是否支持 10 位地址模式——结果发现芯片的某个配置引脚没拉高，默认工作在 7 位模式。这种硬件配置和软件设置不匹配的问题，在 10 位地址场景下特别容易出。
3.3 广播地址与保留地址
I2C 规范定义了一些特殊地址，不能分配给普通从机。这些地址有特定的用途。
| 地址 (7位) | 用途 | 说明 |
|---|---|---|
| 0x00 | 广播/通用呼叫地址 | 所有从机都应应答，用于主机发送全局命令 |
| 0x01~0x03 | 保留 | 用于未来扩展或特定总线协议 |
| 0x04~0x07 | 保留 | 高速模式 (Hs-mode) 相关 |
| 0x78~0x7B | 10位地址标识 | 11110xx 前缀，用于 10 位地址 |
| 0x7C~0x7F | 保留 | 用于特殊目的，如设备 ID 读取 |
广播地址 0x00 是个有意思的东西。主机发送地址 0x00 + 写标志，所有支持广播的从机都会应答。然后主机可以发送一个命令字节，告诉所有从机执行某个操作——比如复位、进入低功耗模式。
注意：不是所有从机都支持广播地址。数据手册里一般会写「General Call」或「GC」支持情况。如果从机不支持广播，它会在地址阶段不产生 ACK。调试时如果发现广播后没有 ACK，先确认从机是否支持这个功能。
我曾经在一个多主系统中用过广播地址。系统里有 8 个相同的传感器，需要同时触发采样。用广播地址发一个命令，所有传感器同时开始采样，比逐个寻址快得多。但要注意，广播地址不能用于读操作——你想想看，如果所有从机同时往 SDA 上发数据，总线直接就乱套了。
3.4 地址冲突：两个从机抢同一个地址
地址冲突是 I2C 调试中最常见的故障之一。说白了，就是总线上有两个或更多从机使用了相同的 7 位地址。
为什么会发生地址冲突？
- 相同型号的芯片：很多传感器、EEPROM 的默认地址是一样的。比如常见的 AT24C02，地址引脚全接地时地址是 0x50。如果你在板子上用了两个 AT24C02，地址引脚又没做区分，那就冲突了。
- 地址引脚配置错误：有些芯片有多个地址配置引脚，如果这些引脚的电平设置不当，两个芯片可能被配置成相同地址。
- 地址范围重叠：不同型号的芯片，虽然功能不同，但地址可能落在同一范围。
地址冲突的典型现象是什么？主机发送地址后，SDA 线上出现异常的 ACK 时序——有时有 ACK，有时没有，或者 ACK 的波形不干净（有毛刺、电平不到位）。
排查方法：用逻辑分析仪抓取地址阶段的波形。正常情况是一个地址字节后跟一个 ACK 位（SDA 被从机拉低）。如果看到 SDA 在 ACK 位置出现「半高电平」或「抖动」，基本可以断定有两个从机在同时应答——一个拉低，另一个没拉，结果就是电平不确定。
我记得有一次调试一个工业控制板，上面挂了 4 个 I2C 温度传感器。逻辑分析仪抓波形，地址阶段一切正常，但数据读取总是出错。后来逐个断开从机，发现其中两个传感器的地址引脚都悬空了——手册说悬空默认是高电平，结果两个芯片的地址完全一样。把其中一个的地址引脚拉低，问题解决。
3.5 仲裁机制：谁抢到总线谁说话
I2C 总线支持多主机模式。也就是说，多个主机可以挂在同一条总线上。那问题来了：如果两个主机同时发起通信，谁说了算？
答案就是仲裁（Arbitration）。
仲裁的规则很简单：谁输出低电平，谁就赢得仲裁。因为 I2C 的 SDA 和 SCL 都是开漏输出，多个设备同时输出时，低电平会覆盖高电平。
仲裁过程是这样的：
- 两个主机同时检测到总线空闲，同时发出起始条件。
- 它们开始发送地址字节，每个 bit 都在 SCL 的上升沿被采样。
- 如果某个主机发送的是高电平，但检测到 SDA 上是低电平，它就意识到自己失去了仲裁。
- 失去仲裁的主机立即停止发送数据，转为从机模式，等待下一次机会。
调试技巧：仲裁过程中，失去仲裁的主机不会产生停止条件。它只是释放总线，让赢得仲裁的主机继续通信。所以你在波形上可能看到「不完整的传输」——地址发了一半就停了。这不是故障，是仲裁的正常行为。
我见过一个案例，客户说他们的系统偶尔会出现「莫名其妙的数据错误」。用示波器抓了几天，终于抓到一次：两个 MCU 同时尝试访问同一个 EEPROM，地址相同，但一个要读，一个要写。仲裁发生在 R/W# 位上——写操作输出 0，读操作输出 1，结果写操作赢了。读操作的 MCU 失去仲裁后，以为自己没抢到总线，但 EEPROM 已经被写操作占用了。后续的数据就全乱了。
解决方案很简单：给两个 MCU 分配不同的优先级，或者用软件握手避免同时发起通信。
3.6 知识结构图：I2C 寻址机制全景
下面这张图把本章的核心知识点串起来了。从地址格式到仲裁机制，你可以看到它们之间的逻辑关系。
3.7 避坑指南：地址相关的常见问题
最后，我把这些年遇到的地址相关问题整理成一份清单。你在调试时可以直接对照排查。
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 发送地址后无 ACK | 从机地址错误、从机未上电、地址引脚配置不对 | 用万用表测量从机供电，核对数据手册地址 |
| ACK 波形异常（半高电平） | 地址冲突，两个从机同时应答 | 逐个断开从机，找到冲突的设备 |
| 广播地址无响应 | 从机不支持广播功能 | 查阅数据手册确认 General Call 支持情况 |
| 10 位地址通信失败 | 从机未配置为 10 位模式、主机驱动不支持 | 检查从机配置引脚，确认主机驱动支持 10 位地址 |
| 多主机系统数据错乱 | 仲裁失败、软件未处理仲裁丢失 | 抓取总线波形，检查仲裁过程是否完整 |
曾经有个血的教训：一个产品量产了 1000 台，有 3% 的机器在老化测试中出现 I2C 通信故障。排查了两个月，最后发现是 EEPROM 的地址引脚虚焊，导致地址随机变化。从那以后，我所有项目的 I2C 地址引脚都加了测试点，产线必须 100% 测试地址引脚的电平。
寻址机制是 I2C 总线的基础。地址对了，通信就成功了一半。下一层我们要深入的是数据传输的细节——从字节格式到时钟拉伸，这些才是真正决定通信可靠性的关键。