1
\$\begingroup\$

I was reading about the I2C Clock stretching.

I understood like, in cases when the slave is requires some time to manage the received data from the master, it slows down the communication speed by stretching the clock SCL line.

I tried to dig deep but was not able to understand it better.

From what I believe, the slave doesn't send the acknowledgement bit to the master and that's what causes the delay. That's how the clock appears to be stretched? That's my guess. But I am not sure. Can someone clarify on how this happens?

In that case, what if the master wants to transmit another set of data to the slave during the clock stretching? Can the master do it during that time or what happens if its does? How can it transmit a new set of data when it hasn't received the acknowledge bit of its previous data that it sent?

\$\endgroup\$
5
  • 1
    \$\begingroup\$ You must have read that I2C lines are open drain with (weak) pull-up. Do you understand what that means and why it implies that any device on the I2C bus can hold any line low (but not force it to be high)? \$\endgroup\$
    – DonFusili
    Oct 21, 2021 at 11:16
  • \$\begingroup\$ Yes, I have read the I2C Lines are open drain. But either strong pull up or weak pull up is decided on the distance between the master and slave. If their are little far, we need strong pull ups & if they are near, we need weak pull ups. I also understand that the devices can pull the bus LOW only but not high. But can you explain on how this point which you say helps to answer my question? \$\endgroup\$
    – user220456
    Oct 21, 2021 at 11:45
  • \$\begingroup\$ Forget pull-up strongness or weakness. If no device pulls bus low, it is high due to the pull-up. \$\endgroup\$
    – Justme
    Oct 21, 2021 at 11:57
  • 1
    \$\begingroup\$ Also: try to forget about clock stretching since it's actually rare to see it in the field \$\endgroup\$ Oct 21, 2021 at 12:28
  • \$\begingroup\$ Not receiving ack bit is usually classified as nack, which has different meaning in I2C communication. It doesn't mean "delay the transmission". \$\endgroup\$
    – Mitu Raj
    Oct 21, 2021 at 13:06

1 Answer 1

2
\$\begingroup\$

No, the device that wants to do a delay at any point will just keep the clock low to stretch the clock cycle and the other devices will just have to wait until the clock goes high again before continuing.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Could you explain with a little more detail? I am not able to understand. So, during the clock stretching, its logical for the slave, not to send the ACK bit. But you seem to mention that the slave will pull the clock LOW. So, you're saying the before the ACK bit is send, the slave will pull down the clock, keeping it LOW, before organizing its data and sending the ACK bit? If yes, then during that time, can the master send another set of data or what would happen if it wants to send? \$\endgroup\$
    – user220456
    Oct 21, 2021 at 11:48
  • 3
    \$\begingroup\$ The receiving device can pull the clock low and keep it low at any point it wants to slow down the bus. It has nothing to do with ACK bit. And when bus clock is low no other device can do anything about it, even if they want to send or receive more bits. The other devices need to wait until all the devices that were stretching the clock stop stretching it so bus can go high again. \$\endgroup\$
    – Justme
    Oct 21, 2021 at 11:54
  • 2
    \$\begingroup\$ When the slave is holding the clock, nothing on the bus is happening. No clock, no change. The slave will usually hold the clock when it is not ready to accept the data - it is no use delaying the ack because it is simply not ready. When it is ready, it will release the clock and the bus transaction will continue. You really need to read the Philips/NXP i2c spec. It tells you all you need to know. Where did we get our knowledge? \$\endgroup\$
    – Kartman
    Oct 21, 2021 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.