Clock stretching, sometimes referred to as clock synchronization, is a mechanism used by an I2C slave to notify the master to slow down the clock speed.
I2C devices can slow down communication by stretching SCL: During an SCL low phase, any I2C device on the bus may additionally hold down SCL to prevent it from rising again, enabling it to slow down the SCL clock rate or to stop I2C communication for a while. This is also referred to as clock synchronization.
This situation may happen when the slave is waiting for its internal operation to finish, such as EEPROM read/write, sensor data calculation, internal state machine to settle down, and so on.
The master, on the other hand, is required to read back the clock signal after releasing it to the high state and wait until the line has actually gone high.
As described above, to implement clock stretching mode (a.k.a blocking mode) in a master side, it is required to read back the SCL after releasing it to the high state, and wait until the line has actually gone high.
If you are using a I2C controller as a master, the clock stretching is usually handled by the I2C controller in hardware level. But if the master communicates with the slave via GPIO, it needs to be accomplished in software level (driver code).
But the problem is, according to I2C Primer, the I2C specification does not specify any timeout conditions for clock stretching, i.e. any device can hold down SCL as long as it likes.
So what if the slave holds down the SCL permanently, or for a long unacceptable time?
What a quirky slave!
网友评论