2
\$\begingroup\$

The I2C manual by NXP allows Clock Stretching (holding SCL low) by slave devices in order to have the master wait for them to process data, interrupts and the like. This is all fine and well, although not having a timeout seems questionable.

Now, I wonder whether a master controller can use the same method for example when waiting for the host processor to provide/collect data. For simplicity I only consider a single master setup, although it should not matter.

Edit: For the sake of clarity I am concerned about cases in which during a multi-byte transfer the host processor is not able to provide/collect data to/from the master controller. Issuing a STOP and possibly resetting the slave's state machine (auto-increment counters, 32-bit internal registers, etc.) is not feasible.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Erm... why not just not start the next cycle until ready? \$\endgroup\$ Jan 24, 2014 at 14:34

2 Answers 2

4
\$\begingroup\$

Being the master the clock generator, it's in fact reducing the clock frequency by its own, contrary to a slave, that has the clock generated by the master, but wants to signal the master to hold it.

According to Wikipedia:

Although the master may also hold the SCL line low for as long as it desires, the term "clock stretching" is normally used only when slaves do it.

But

To ensure a minimum bus throughput, SMBus places limits on how far clocks may be stretched. Hosts and slaves adhering to those limits cannot block access to the bus for > more than a short time, which is not a guarantee made by pure I²C systems.

So, when using clock stretching be sure the devices support it, as for trademark reasons I2C is implemented as other names and has not all features. But that is more a concern for slave devices.

\$\endgroup\$
2
\$\begingroup\$

I2C clock "stretching" refers to the mechanism by which a slave device holds SCL low after the master has driven it low, in order to prevent it from going high again before the slave is ready to process the next data bit.

If the master is waiting for more data from, say, a host CPU, it simply won't drive SCL low in the first place — it'll simply leave it high until the next data transfer can start. There's no reason for the master to hold SCL low for an extended period of time.

The one exception would be during the arbitration phase of a multi-master setup. In that case, some clock stretching will occur as a result of the various masters not being strictly in-phase as they start their transfers.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.