i2c的时钟延展问题

结论： (即在模拟i2c主：在主设置SCL为高后，要超时判断SCL是否为高，再发后面的时序）

 

现象(如下图)：

由于在发送读命令之后，即ACk之后，下面从设备需要准备数据时间，（大约10us,一个时钟的时间），此时还在I2C中断中，因此SCLK上是被拉低。由于主设备，并未检查该SCLK信号，导致下一个数据的第一个时钟信号被拉低，而不知道，而当做有效信号采样，结果导致数据采用出错；我们自己的主设备，采用硬件I2C，有判断总线是否占用和超时机制，故没有这个问题。

I2C的时钟可能被从设备拉低，从示波器看好像主少发了时钟（只有8个时钟，实际应该9个，最前面一个被从设备拉低了），实际是从设备拉低，这时候主设备最好检查时钟信号变高后，再发时钟信号脉冲！

（还在调试爱立信电源PMBUS问题：主发第九个时钟未检查总线，此时从设备把SCL拉低《此时从设备正在做相应数据处理，所以拉低总线》，导致ACK应答失败，从示波器看好像少发了第九时钟；方法发第九个时钟的时候检查SCL电平，发现它变高后，才发第九个时钟）

 

原因：通信中，从设备由于某种原因（数据处理或准备）拉低SCL时钟线（此时总线属于被占用状态），而主设备并未判断SCL的是否为高空闲，而继续通信，导致失败

 

解决方法：在通信中，要随时检查SCL电平，当它为低的时候，需要超时等待，等它为高时候，再发新的SCL信号

 (即在代码中，主设置SCL为高后，要超时判断SCL是否为高，再发后面的时序）

另：个人认为硬件i2c有总线占用和超时判断，相对于模拟i2c更好； 但硬件i2c容易出现死锁的问题

 

Clock Stretching--http://www.i2c-bus.org/clock-stretching/

In an I2C communication the master device determines the clock speed. Unlike RS232 the I2C bus provides an explicit clock signal which relieves master and slave from synchronizing exactly to a predefined baud rate.

However, there are situations where an I2C slave is not able to co-operate with the clock speed given by the master and needs to slow down a little. This is done by a mechanism referred to asclock stretching.

An I2C slave is allowed to hold down the clock if it needs to reduce the bus speed. The master on the other hand is required to read back the clock signal after releasing it to high state and wait until the line has actually gone high.

Bandwith

Clockstretching sounds a bit odd but is common practice. However the total bandwith of the shared bus might be significantly decreased. So, especially for I2C buses shared by multiple devices it is important to estimate the impacts of clock-stretching. So do not make the slowest I2C device dominate your bus performance