clock stretching

[Kittu20]

I am trying to understand what is the clock stretching in i2c communication.
I know that microcontroller sends clock signal to slave device.

[jpanhalt]

From Microchip:

27.3.1 CLOCK STRETCHING
When a slave device has not completed processing
data, it can delay the transfer of more data through the
process of clock stretching. An addressed slave device
may hold the SCL clock line low after receiving or sending
a bit, indicating that it is not yet ready to continue.
The master that is communicating with the slave will
attempt to raise the SCL line in order to transfer the
next bit, but will detect that the clock line has not yet
been released. Because the SCL connection is
open-drain, the slave has the ability to hold that line low
until it is ready to continue communicating.
Clock stretching allows receivers that cannot keep up
with a transmitter to control the flow of incoming data.

[AVI-crak]

Too fast correct answer.
You must keep the conversation on hold until the client is fully mature.

[Kittu20]

From Microchip:

The description given in the link is beyond my knowledge. The two transactions I see in the clock signals are low-to-high which is called a rising edge and high-to-low which is called a falling edge.

[Sacodepatatas]

You already know that both master and slave can control the SDA by pulling down the line to a low level, because the default line state is high when no device is taking control. As the SCL is of the same type of the SDA, and although controlling the SCL line is forbidden for a slave device, when certain situations ocur like in clock stretching, it is allowed that, once the master has pulled down the SCL, the slave may pull It down aswell to hijack the low line state for an amount of time longer than the master clocking period, and the master can't do anything about it. The fact that either SCL or SDA lines can't be in high state until all devices release the line (output a high level) is usually known as "Wired AND".

[Siwastaja]

The description given in the link is beyond my knowledge.

Well, the idea in essence:

Normally, I2C clock is a signal that is generated by the master; slave only reads the clock signal level and obeys it.

With clock stretching, slave takes control of that clock line, too, controlling it like a master would. Master listens and understands the slave is now stretching the clock, and waits. This way, slave can say "hold on for a while, I'm not done yet!" to the master.

I don't like clock stretching because it makes otherwise simple protocol much more complicated. It would be better to design slaves so that they can always reply in time. And 99% of slaves do that, and many masters do not even support clock stretching.

[macboy]

The description given in the link is beyond my knowledge.

Well, the idea in essence:

Normally, I2C clock is a signal that is generated by the master; slave only reads the clock signal level and obeys it.

With clock stretching, slave takes control of that clock line, too, controlling it like a master would. Master listens and understands the slave is now stretching the clock, and waits. This way, slave can say "hold on for a while, I'm not done yet!" to the master.

I don't like clock stretching because it makes otherwise simple protocol much more complicated. It would be better to design slaves so that they can always reply in time. And 99% of slaves do that, and many masters do not even support clock stretching.

Much more complicated?
I implemented a bit-banged i2c master with clock stretching, and it is super simple. When the master releases the clock line, it simply waits until it goes to high level before proceeding. Normally that occurs immediately, but if the slave is stretching the clock then you simply sit and wait.

[Siwastaja]

Much more complicated?
I implemented a bit-banged i2c master with clock stretching, and it is super simple. When the master releases the clock line, it simply waits until it goes to high level before proceeding. Normally that occurs immediately, but if the slave is stretching the clock then you simply sit and wait.

Yes, much more complicated.

If you just need to put something together which kinda-maybe works, then sure, it's just a few hours of implementation, if even that.

But you might not realize how serious consequences that "simply sit and wait" strategy is, if predictability of timing has any value for you. Now you need to add timeouts, error handling, decide what to do when the timeout occurs, specify what the acceptable maximum time is...

And, I2C is often used in microcontroller systems, where timing and reliability does matter. But, as I said earlier, most of the slaves do not do clock stretching, so you can choose to turn this feature off from the master side, as well, and there you have it, predictable timing again, and the only error condition is NAK.

[woofy]

@Kittu20
Grab your self a copy of the specification.
NXP has put it behind an account wall so I'm not going to include it here, but its document number UM10204.
Search for um10204.pdf, its all over the internet.

Anyone writing a bit-bashed master really should include clock stretching. Its part of the spec, and as macboy pointed out, easy to implement.

[woofy]

Much more complicated?
I implemented a bit-banged i2c master with clock stretching, and it is super simple. When the master releases the clock line, it simply waits until it goes to high level before proceeding. Normally that occurs immediately, but if the slave is stretching the clock then you simply sit and wait.

Yes, much more complicated.

If you just need to put something together which kinda-maybe works, then sure, it's just a few hours of implementation, if even that.

But you might not realize how serious consequences that "simply sit and wait" strategy is, if predictability of timing has any value for you. Now you need to add timeouts, error handling, decide what to do when the timeout occurs, specify what the acceptable maximum time is...

And, I2C is often used in microcontroller systems, where timing and reliability does matter. But, as I said earlier, most of the slaves do not do clock stretching, so you can choose to turn this feature off from the master side, as well, and there you have it, predictable timing again, and the only error condition is NAK.

I don't agree.
Clock stretching is part of the I2C specification, time-outs are not. (It is part of SMBus).
In fact the I2C spec specifically says "There is no limit in the I2C-bus protocol as to how long this delay can be".

[Siwastaja]

I don't agree.
Clock stretching is part of the I2C specification, time-outs are not. (It is part of SMBus).
In fact the I2C spec specifically says "There is no limit in the I2C-bus protocol as to how long this delay can be".

 

So seriously, your firmware hangs in infinite while(1) loop, or stops communication with other I2C devices, and you say to your boss or customer...
"I2C protocol specification document said there is no maximum limit for clock stretching"?

Of course, the lack of standardizing a maximum time makes it even more complicated, because then you have to assume something, or ignore the whole issue and pretend everything's OK.

It's fundamentally simple to understand that master is something that controls slaves. Master creates timing, slaves only share their data. With I2C, there is a possibility of control flow reversal, so that a single slave is capable of controlling the master, and also preventing it from accessing other slaves. And for what - for a feature which is not desired or used 99% of the time.

It is not uncommon at all to see a P-MOSFET designed in to cut the power to a possibly misbehaving I2C slave. Or see devices which use yet another extended standard over I2C specification, such as SMBus or PMBus. What a mess.

But clearly you are one of those who think that "the fact I don't understand all the complications, and ignore all possible issues, makes it simple". Meanwhile, I prefer protocols which truly are inherently simple. I2C could be; the totally unnecessary feature bloat no one REALLY needs, such as multi-master capability and clock stretching, implodes the state space. Problem is, I2C is usually used for simple and slow things. It doesn't need to be as complicated as it is, it's overengineered.

But maybe there are a few cases where clock stretching is useful. I just say I don't like it. So whenever I have choice, with sensors for example, I tend to choose SPI variant, which has completely predictable timing and hardware signal which resets the communication state. And on SPI, master is master.

[PCB.Wiz]

The description given in the link is beyond my knowledge. The two transactions I see in the clock signals are low-to-high which is called a rising edge and high-to-low which is called a falling edge.

Imagine someone is handing you a bag of apples one at a time, and you have to place them in a tray.
At some point, you need to communicate 'WAIT' to the other person, whenever they feed faster than you can handle.

That's exactly what clock stretch does - the signals are open-drain, so the slower node can hold the SCL low, until they are ready for the next step.

[Kittu20]

master generates the SCL signal. Master can set SCL line high or Low. slave only reads the clock signal level. I don't understand what happens after that

[SiliconWizard]

slave only reads the clock signal level.

Well, no. That's the point.

[langwadt]

master generates the SCL signal. Master can set SCL line high or Low. slave only reads the clock signal level. I don't understand what happens after that

the master cannot set the SCL line high, it can only release it so it gets pulled up by the pull-up resistor

as long as any of the devices on the bus keeps the line low it stays low

[PCB.Wiz]

master generates the SCL signal. Master can set SCL line high or Low. slave only reads the clock signal level. I don't understand what happens after that

No, the stretching capable slave can both read scl and can also pull SCL low.
That is the wait signal.
The master releases the clock and then checks if it really did go high.
If the master checks SCL and finds it is still held low, then it waits until it goes high = released by the driving slave.

Not all i2c slaves need to do clock stretching, so data on EEPROMs will not mention it.

[Nominal Animal]

Let me try if I can explain this in a beginner-friendly way.  Please don't flame me!  But do point out if you disagree with my explanation.

I²C bus has two open-drain signals, SCL and SDA.  This means that the master side and the slave side can only pull the signal to ground.  This is also why we need actual physical pull-up resistors.  TI appnote SLVA689 describes exactly how one calculates the needed resistances, but typically values like 2.2kΩ are used.

The master generates the clock signal by pulling SCL to ground, keeping it grounded for a minimum duration, and letting it rise and stay high (over some threshold voltage, which is described in the device datasheets) for a minimum duration.

Clock stretching is when the client prevents the SCL from going high, because it is not ready yet.
(Think of it like your friend tapping a rhythm on a table with their hand, and you pausing them by gently keeping their hand on the table.)

Although clock stretching is part of the I²C standard, not all I²C masters support it.  For that reason, some I²C slave devices explicitly mention the device does not do clock stretching.

This also means that if you have a master and slave that disagree on what the "high" level ought to be, you need a voltage level shifter that is explicitly documented as suitable for I²C use, including clock stretching.  For example, there are voltage level translators where the SCL line is strictly unidirectional, from master to slave, and only the SDA line truly bidirectional and suitable for I²C SDA; these translators work for I²C except they do not support clock stretching.

[TomS_]

You and a friend are walking down the road. Your friend is the master and is leading the way, setting the pace through their footsteps (the clock). You are the slave, following in step. While walking you are having a conversation, talking back and forth (sending and receiving data).

At some point you want to stop for a moment to take a quick break, you stop walking so your friend must also stop walking.

That's basically clock stretching. Without it, the master keeps walking on, and eventually talking to no one and receiving no reply because the slave stopped walking and talking some time ago.

So the slave can basically pause the master by holding the clock signal in a low state preventing it from generating further clocks (no more foot steps), thus preventing the sending or receiving of further data.