3. I2C时序分析：SCL与SDA时序关系、时钟同步与仲裁、多主机通信机制
各位同学，今天我们聊I2C的时序。说实话，很多工程师调I2C调不通，十有八九是时序没吃透。你想想看，两根线要完成地址发送、读写控制、数据收发、应答确认，全靠SCL和SDA的配合。我当年第一次调I2C驱动，示波器一挂上去，波形乱得跟心电图似的——后来才发现是起始条件没满足建立时间。
3.1 SCL与SDA的时序关系
I2C的时序核心就一句话：SCL提供时钟，SDA在SCL低电平时变化，在SCL高电平时被采样。这个规则贯穿整个协议，所有操作都围绕它展开。
关键规则：
- SCL高电平时，SDA必须保持稳定（数据采样窗口）
- SCL低电平时，SDA允许变化（数据切换窗口）
- 起始条件：SCL高电平，SDA从高变低
- 停止条件：SCL高电平，SDA从低变高
我给大家画个时序图，把几个关键参数标出来。这些参数在电机控制场景下尤其重要——你想想，电机驱动板上的噪声那么大，时序裕量不够的话，数据很容易被干扰。
这张图里我标了四个关键位置：起始条件、数据采样、数据变化、停止条件。注意看，数据采样窗口永远在SCL高电平期间，数据变化只能在SCL低电平期间发生。这个规则一旦被破坏，总线上的所有设备都会乱套。
我的经验：在电机控制板上，我习惯把I2C时钟频率降到标准模式（100kHz）而不是快速模式（400kHz）。虽然慢了点，但抗干扰能力强很多。有一次客户反馈电机运行时偶尔丢数据，我让他把频率从400kHz降到100kHz，问题就解决了。
3.2 时钟同步与仲裁机制
I2C的时钟同步，说白了就是多个设备抢着拉低SCL，谁拉得低谁说了算。这个机制很有意思——它用的是线与逻辑。
时钟同步原理：
- 所有设备都可以拉低SCL（开漏输出）
- 如果某个设备需要更多时间处理数据，它会主动拉低SCL
- 其他设备检测到SCL被拉低，会等待SCL释放后再继续
- 所有设备都释放SCL后，SCL才会被上拉电阻拉高
我举个例子你就明白了。假设主机A和主机B同时想发起通信，A的时钟周期是10μs，B的时钟周期是15μs。A拉低SCL后，B也会跟着拉低。当A准备释放SCL时，B还在处理数据，B会继续拉低SCL。A检测到SCL还是低电平，就会等待。直到B也释放了SCL，总线才会恢复高电平。这样一来，实际的SCL周期就被拉长到了15μs——这就是时钟同步。
时钟同步的实质：多个主机中，最慢的那个决定了总线时钟速度。这既是优点也是缺点——优点是慢设备不会被快设备淹没，缺点是快设备得迁就慢设备。
仲裁机制跟时钟同步类似，但发生在SDA线上。当多个主机同时发送数据时，它们会通过SDA进行仲裁。规则很简单：谁发送低电平，谁就赢得仲裁。
仲裁过程：
- 多个主机同时发送起始条件
- 每个主机在SCL高电平时采样SDA
- 如果某个主机发送高电平，但检测到SDA是低电平，说明有其他主机在拉低SDA
- 这个主机就知道自己输了仲裁，立即停止发送，转为从机模式
- 赢得仲裁的主机继续正常通信
注意：仲裁过程中，输掉的主机不能产生停止条件。它必须默默退出，让赢得仲裁的主机完成整个传输。如果输掉的主机擅自发送停止条件，会破坏总线状态，导致通信失败。
我曾经在一个多电机同步控制项目中踩过这个坑。三个电机驱动器挂在同一条I2C总线上，每个驱动器都配置了独立的MCU。其中一个MCU的固件有bug，仲裁失败后发送了停止条件，结果整条总线卡死了。查了两天才找到原因——从那以后，我要求所有从机固件必须严格遵循仲裁退出规则。
3.3 多主机通信机制
多主机通信，说白了就是多个MCU或控制器共享同一条I2C总线。这在电机控制中很常见——比如一个主控板控制多个电机驱动板，每个驱动板上又有一个本地MCU。
多主机通信的典型场景：
| 场景 | 描述 | 我的建议 |
|---|---|---|
| 主控+多个从机 | 一个主控轮询多个电机驱动器 | 最常用，简单可靠 |
| 多主控共享传感器 | 多个控制器读取同一个位置传感器 | 需要仲裁机制，注意总线冲突 |
| 主从切换 | 某个从机临时成为主机发起通信 | 适合报警场景，但实现复杂 |
多主机通信的核心挑战是总线冲突。虽然I2C有仲裁机制，但仲裁本身会消耗时间。在电机控制这种实时性要求高的场景下，我一般不建议用真正的多主机模式。更实用的做法是：一个主机，多个从机，主机轮询。
我的做法：在电机控制系统中，我习惯把主控MCU设为主机，所有电机驱动器设为从机。主机每隔1ms轮询一次所有从机，读取电流、位置、温度等数据。这样既避免了仲裁冲突，又能保证实时性。如果某个从机有紧急事件需要上报，我给它分配一个中断引脚，通过GPIO通知主机，而不是通过I2C主动发起通信。
如果你确实需要多主机模式，有几个要点必须注意：
- 总线空闲检测：每个主机在发起通信前，必须检测总线是否空闲（SCL和SDA都为高）
- 仲裁超时处理：设置一个超时时间，如果仲裁时间过长，所有主机释放总线，重新竞争
- 地址冲突避免：确保每个主机的从机地址不重复，否则仲裁会频繁发生
- 错误恢复机制：总线卡死时，主机可以通过发送9个时钟脉冲来复位从机状态机
说到错误恢复，我记得有一次在调试四轴机械臂时，I2C总线莫名其妙卡死了。示波器一看，SDA被某个从机拉低了，但SCL还在正常跑。我手动发了9个时钟脉冲，SDA就释放了。后来查代码，发现是从机在接收数据时发生了溢出中断，状态机卡在了某个中间状态。从那以后，我在所有从机固件里都加了总线超时复位功能——如果SCL超过10ms没有变化，自动复位I2C外设。
多主机通信的黄金法则：
- 能不用的多主机，尽量不用
- 如果非要用，确保所有主机的固件都经过严格测试
- 总线上加一个总线监视器，检测异常状态
- 每个主机都要有错误恢复能力
最后说一句，I2C的时序分析，说到底就是理解SCL和SDA的配合关系。起始条件、数据采样、停止条件这三个关键点吃透了，剩下的就是参数配置和抗干扰处理。在电机控制这种高噪声环境下，时序裕量留大一点，上拉电阻选对值，地线铺好——这些基本功比什么花哨的技巧都管用。