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, 2019 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, 2019 at 1:07
  • \$\begingroup\$ It is implementation specific \$\endgroup\$
    – Mitu Raj
    Oct 30, 2019 at 4:04
  • \$\begingroup\$ What do you expect to happen in a multi-master I2C setting? \$\endgroup\$
    – Mast
    Oct 30, 2019 at 12:19

2 Answers 2


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, 2019 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\$ Nov 1, 2019 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, 2019 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, 2019 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, 2019 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, 2019 at 22:11

Your Answer

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

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