📚 课程目录第3章时钟拉伸机制

时钟拉伸机制：从设备控制时钟的原理

时钟拉伸（Clock Stretching）这个话题，说实话，是很多工程师在I2C调试中容易踩坑的地方。我记得刚入行那会儿，第一次遇到从设备不响应，示波器上SCL线被拉低半天不动，我还以为是总线挂了。后来才知道，这其实是从设备在说“等等，我还没准备好”。

从设备如何控制时钟

I2C协议有个很有意思的设计——时钟信号虽然由主设备产生，但从设备却能通过拉低SCL来“暂停”通信。这背后的原理，其实就藏在I2C总线的开漏结构里。

你想想看，SCL和SDA都是开漏输出，加上上拉电阻。主设备想产生时钟，就把SCL拉低再释放，靠上拉电阻把电平拉高。但这时候，如果从设备也把SCL拉低，那SCL就升不上去。主设备检测到SCL没变高，就知道从设备在拉伸时钟，于是停止发送下一个时钟脉冲。

核心要点：时钟拉伸是从设备通过主动拉低SCL线，强制主设备等待的一种流控机制。它不会破坏总线状态，只是让时钟暂停。

我在一个项目中遇到过这样的情况：一个温湿度传感器，每次读取数据后需要大约500μs才能准备好下一次数据。如果不处理时钟拉伸，主设备连续读取就会拿到错误数据。后来我查了数据手册，发现这个传感器确实支持时钟拉伸，只是默认没开启。

SCL低电平保持的时序细节

从设备拉低SCL后，能保持多久？这其实没有硬性限制。标准模式下，从设备可以无限期拉低SCL，直到它准备好。但实际项目中，我们得考虑看门狗和系统实时性。

具体时序参数，我整理了一个表格，方便你对照：

参数	符号	标准模式	快速模式	高速模式
SCL低电平时间	t_LOW	≥4.7μs	≥1.3μs	≥0.32μs
SCL高电平时间	t_HIGH	≥4.0μs	≥0.6μs	≥0.12μs
时钟拉伸最大时间	t_STRETCH	无限制	无限制	≤0.9μs

注意看高速模式那一列。高速模式下，时钟拉伸时间被限制在0.9μs以内。为什么？因为高速模式的设计目标就是高吞吐，不允许从设备长时间占用总线。我建议你在选型时，如果要用高速模式，先确认从设备是否支持这么短的拉伸时间。

主设备如何检测时钟拉伸

主设备检测时钟拉伸，说白了就是看SCL线有没有按预期变高。具体流程是这样的：

主设备拉低SCL：开始一个时钟周期
主设备释放SCL：让上拉电阻把SCL拉高
主设备检测SCL电平：如果SCL还是低，说明从设备在拉伸
主设备等待：继续检测，直到SCL变高
继续通信：SCL变高后，主设备再拉低SCL，开始下一个周期

嗯，这里要注意。主设备在检测SCL时，不能无限等下去。我见过一个案例，某款从设备因为固件bug，时钟拉伸后永远不释放SCL，结果整个总线都卡死了。所以，超时处理是必须的。

警告：主设备必须实现时钟拉伸超时机制。一般建议超时时间设为10ms-100ms，具体取决于你的系统实时性要求。超时后，主设备应该复位总线或重新初始化。

主设备的适配策略

适配时钟拉伸，主要有三种策略。我根据自己的经验，把它们列出来对比一下：

策略	实现方式	适用场景	优缺点
轮询等待	循环检测SCL电平，直到变高	简单从设备，拉伸时间短	实现简单，但占用CPU
中断触发	SCL上升沿触发中断，唤醒主设备	多任务系统，拉伸时间长	节省CPU，但需要硬件支持
DMA+超时	DMA自动处理数据，超时后复位	高速传输，批量数据	效率高，但实现复杂

我个人习惯用轮询等待加超时。为什么？因为简单可靠。在嵌入式Linux驱动里，我通常这样实现：

static int i2c_wait_for_scl_high(struct i2c_adapter *adap, int timeout_ms)
{
    unsigned long timeout = jiffies + msecs_to_jiffies(timeout_ms);
    
    while (time_before(jiffies, timeout)) {
        if (gpio_get_value(adap->scl_pin)) {
            return 0;  // SCL已变高，成功
        }
        udelay(1);  // 每1μs检测一次
    }
    
    return -ETIMEDOUT;  // 超时，返回错误
}

这段代码看起来简单，但我在项目中踩过坑。有一次，我忘了加udelay(1)，结果while循环跑得飞快，CPU占用率直接飙到100%。加了延时后，问题就解决了。

小技巧：检测SCL时，延时不要太大。1μs是比较合适的值。延时太大，会错过从设备释放SCL的时机，导致通信效率下降。

时钟拉伸的典型场景

哪些从设备会用到时钟拉伸？我总结了几类：

EEPROM：写入操作后需要时间完成内部编程，通常会拉伸时钟
ADC/DAC：转换过程中需要时间，会拉伸时钟等待转换完成
传感器：测量、校准过程中会拉伸时钟
安全芯片：加解密运算需要时间，会拉伸时钟

我记得有一次调试一个EEPROM，写入数据后它总是拉伸时钟大约5ms。一开始我以为是硬件问题，后来看了数据手册才发现，这个型号的EEPROM写入时间就是5ms，时钟拉伸是正常行为。

时钟拉伸的SVG流程图

下面这张图展示了时钟拉伸的完整流程，从主设备开始发送时钟，到从设备拉伸，再到主设备检测超时：

避坑指南

最后，分享几个我踩过的坑：

不要假设所有从设备都支持时钟拉伸：有些廉价传感器根本不支持，强行使用会导致通信失败
注意高速模式的限制：高速模式下时钟拉伸时间极短，主设备必须能快速响应
超时时间要合理：太短会导致误判，太长会拖慢系统
多主设备场景要小心：多个主设备同时检测时钟拉伸，可能产生总线竞争

我曾经在一个项目里，把超时时间设成了1ms，结果某个EEPROM写入需要3ms，每次写入都超时。查了两天才发现是超时时间设短了。后来改成10ms，问题就解决了。