核心内容摘要
《锁饥饿：能抢却抢不到的并发困境》
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位（地址bit