I²C多主通信不是“抢总线”，而是让硬件自己商量好谁说话
你有没有遇到过这样的场景：
- 车载中控屏突然卡住，但仪表盘温度还在跳动；
- 智能手表抬腕亮屏瞬间，心率数据却延迟了两秒才更新；
- 工业PLC里两个MCU同时想读同一块温湿度传感器，结果总线“死锁”了几百毫秒——日志里只留下一串ARLO标志被置位的痕迹。
这些都不是软件Bug，而是I²C多主通信没被真正理解的表现。很多人以为多主 = 多个主机轮流发命令，像排队打饭；其实它更像一群人在嘈杂的会议室里讲话——没人举手喊“我先说”，但只要有人声音压过别人，其他人就自然闭嘴；而且大家说话节奏不同，却能神奇地同步成一个节拍。
这不是靠操作系统调度、也不是靠软件加锁实现的，而是由两根线（SDA/SCL）上的物理电平关系直接决定的。今天我们就抛开手册里的框图和术语堆砌，从一块面包板开始，讲清楚：当多个主设备同时伸手去碰I²C总线时，到底发生了什么？为什么失败方不会丢数据？为什么快慢不同的MCU还能一起干活？以及——你在写驱动时，究竟该关注哪些寄存器、避开哪些坑？
开漏结构：所有故事的起点
一切都要从I²C最基础的电气特性说起：SDA和SCL都是开漏（Open-Drain）输出。
这意味着：
- 任何设备都可以把线“拉低”（GND），相当于按下开关；
- 但没有任何设备能主动把线“拉高”（VDD），那得靠外部上拉电阻“托起来”。
你可以把它想象成一条挂在天花板上的绳子，所有人手里都有一段往下拽的绳头，但没人能往上推。谁用力拽，绳子就往谁那边沉；所有人都松手，绳子才靠弹簧（上拉电阻）慢慢回到原位。
这个简单设定，直接催生了两个关键能力：仲裁和时钟同步。它们不是协议层“定义出来”的功能，而是物理层“不得不如此”的结果。
仲裁不是投票，是边发边比的实时淘汰赛
很多资料说“I²C仲裁是逐位比较”，听起来像在做二进制减法。但真实过程更动态：每个主设备一边发数据，一边盯着SDA看自己说的话是不是被别人盖过去了。
举个具体例子：
| 时间点 | AP发送 | Sensor Hub发送 | SDA实际电平 | AP检测结果 | Hub检测结果 | 结果 |
|---|---|---|---|---|---|---|
| 第1位（地址bit7） | 1 | 0 | 0 | 发1但看到0→立刻停手 | 发0 |
