I have looked into I2C specifications, but there are few questions that I don't understand clearly. I understand clock stretching is a mechanism in the I2C communication protocol where a target device (slave)temporarily pauses communication by holding the clock line (SCL) low until it is ready to continue.

However, I'm interested to know about its practical applications. What are the scenarios or situations where clock stretching is commonly applied? Additionally, are there any limitations or drawbacks associated with clock stretching in I2C communication, and in what situations is it not recommended or not supported?

 

I2C clock stretching is one of the things with a large number of bad hardware implementations (like the next clock after a stretch will be runt/short because the master device 'cheats' with a mask of the continuing clocks) across controllers, SoC and other platforms.
https://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html

https://learn.adafruit.com/raspberry-pi-i2c-clock-stretching-fixes/overview
Various approaches for dealing with I2C clock stretching on a Raspberry Pi.

You might see it commonly applied as a hardware delay on a target device with a difference in read/write times like a EEPROM, where the write time is usually much longer than the read time for X byte. It's very common to see software bit-banged I2C used to handle clock stretching correctly.

I try to avoid I2C if SPI is available on the target device.

 

You might see it commonly applied as a hardware delay on a target device with a difference in read/write times like a EEPROM, where the write time is usually much longer than the read time for X byte.

Thank you for sharing a practical example of applying clock stretching. However, I'm still unclear about the limitations and situations where clock stretching is not recommended. Could you please provide more specific details

 

Thank you for sharing a practical example of applying clock stretching. However, I'm still unclear about the limitations and situations where clock stretching is not recommended. Could you please provide more specific details

No. It's time for you to do more reading.

 

No. It's time for you to do more reading.

I've looked into the specification and done a Google search for "limitations and situations where clock stretching is not recommended". However, after reading many links, I still don't understand the specific situations where clock stretching is not recommended. Could you please provide more clarity or information on this topic?

 

If the target device needs more time before it is capable of continuing to receive the communication, then what are it's alternatives? As for limitations, think about what is happening to all of the other communications that other devices are ready to carry out but can't because one devices is holding the clock line hostage. Surely you can see at least a few potential problems that might creep up.

 

In your context, if clock stretching is “not recommended” then I²C is not recommended. Clock stretching was developed for a reason. If you need it there is no alternative within I²C, so that means you can’t do what you want with it.

The bottom line is that your question is malformed.

 

The bottom line is that your question is malformed.

Thank you! I now understand the benefits of I2C stretching and why it's useful. It allows the slave to take the necessary time to provide accurate data without causing a communication error or data loss

 

Hi MTech,
Simply put, it is a useful option when the MCU has to communicate with a slow external IC device, that's when I use that option.
E
Added link:
https://prodigytechno.com/i2c-clock-stretching/

 

Thank you! I now understand the benefits of I2C stretching and why it's useful. It allows the slave to take the necessary time to provide accurate data without causing a communication error or data loss

Then it would appear that you did NOT really understand what you said in your initial post: "I understand clock stretching is a mechanism in the I2C communication protocol where a target device (slave)temporarily pauses communication by holding the clock line (SCL) low until it is ready to continue."

 

While clock stretching is useful keep in mind that some host devices will timeout if the slave holds the clock low for too long.