I've always considered SCK to be a unidirectional line since the master generates/transmits the clock signal and the slaves "see" the generated pulses. I have found many sources that agree with this idea via Google. However, I was reading this I2C primer/refresher by Analog and I noticed they defined the SCK line as bidirectional:

From paragraph 3: "The I2C bus uses only two bidirectional lines, Serial Data Line (SDA) and a Serial Clock Line (SCL). "

So what's going on here? Is the SCK line only bidirectional sometimes, like when there is more than one master in the I2C configuration?

  • 8
    \$\begingroup\$ Look up clock stretching. \$\endgroup\$ – Matt Young Oct 30 '19 at 1:04
  • \$\begingroup\$ A multi-master setup would be another scenario where both lines would appear (to a master) to sometimes be an 'input' and sometimes an 'output'. \$\endgroup\$ – user85471 Oct 30 '19 at 1:07
  • \$\begingroup\$ It is implementation specific \$\endgroup\$ – Mitu Raj Oct 30 '19 at 4:04
  • \$\begingroup\$ What do you expect to happen in a multi-master I2C setting? \$\endgroup\$ – Mast Oct 30 '19 at 12:19

The clock line can be bi-directional for two reasons.

  • Clock stretching
  • Multi-master.

Typically on slave devices that are entirely implemented in hardware the clock line is input-only. Such devices have no need to stretch the clock.

On the other hand microcontroller based slaves typically do need to stretch the clock to give them time to interpret the incoming bytes and prepare an appropriate response.

Unfortunately there are some masters out there that do not fully implement I2C and don't take any notice of clock-stretching or worse try to drive the line hard high. Such masters will not work correctly with a slave that needs to clock stretch.

  • \$\begingroup\$ Notably last time I looked the Linux Kernel didn't support clock stretching in many of it's drivers. \$\endgroup\$ – Sam Oct 30 '19 at 22:14
  • \$\begingroup\$ Clock stretching isn't really a driver thing, if the controller doesn't support it then short of implementing I2C in software there isn't much the driver can do. \$\endgroup\$ – Peter Green Nov 1 '19 at 17:22
  • \$\begingroup\$ It really is, when you are in a framework like the Linux Kernel, you may not be able to or willing to wait for the stretch due to the interrupt architecture. \$\endgroup\$ – Sam Nov 2 '19 at 0:03

It's supposed to be bidirectional so that slave devices can hold it low and "stretch" the clock during internal processing or whatever. However, not all master implementations actually look at the state of SCL, and not all slave devices have the capability to stretch the clock.

  • 2
    \$\begingroup\$ And many of the slaves would never need to. But try to make a microcontroller into a slave, and, oh, you definitely need it then. \$\endgroup\$ – gbarry Oct 30 '19 at 3:22
  • 1
    \$\begingroup\$ This answer is good. I will add that if slave chip uses clock stretching, then the master must support it, or it does not work. It really depends on your slave chips. My advice is to read the actual I2C application manual by NXP, or at least the Wikipedia page about I2C, instead of just looking at a specific implementations of random tinkerers that do not need to use all possible features of I2C. \$\endgroup\$ – Justme Oct 30 '19 at 9:34
  • \$\begingroup\$ The issue with slave devices isn't whether they have the "capability" to stretch the clock, but rather whether they would always be able to operate fast enough, relative to the master, that they wouldn't need to stretch the clock. \$\endgroup\$ – supercat Oct 30 '19 at 22:11

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.