I2C Protocol – How Does the Slave Pull Down the SDA Line?

i2cpll

As we know, the waveforms of the I2C signals (SDA and SCL) are very similar to the following:

The main requirement is that during the transmission of a byte, the SDA does not transition while SCL is high. In fact, in that case a STOP condition arises 2. The SCL is driven by the master so how can the slave asynchronously drive the SDA? Does it have an internal PLL to produce a faster internal clock (I am thinking a clock frequency twice the SDA frequency), or can the slave just switch SDA at the falling edge of SCL?

Best Answer

Many I2C slave devices (microcontrollers, for example) will have an internal clock that runs continuously and at a much higher rate than the I2C clock. These devices will simply drive SDA on an internal clock edge that happens some time after they observe SCL to be low.

Simple I2C slaves (certain ADCs, bus switches, etc) will use the SCL falling edge to time their SDA transitions. Simple causality and gate delays will ensure the SDA transition occurs at least a few nanoseconds after SCL has fallen. The known maximum clock rate for the I2C protocol being used will allow the designer to ensure the SDA transition happens before the next rising edge of SCL.

For lower speed I2C protocol (100 kHz for sure, maybe also for 400 kHz but I don't remember for sure) devices that are very slow can also hold SCL low themselves to give themselves time to update SDA before SCL is allowed to go high again. This is called "clock stretching".

Related Solutions

Electronic – I2C slave not pulling down SDA data line for the full clock cycle

The variation in delay you're seeing is immaterial. I²C is a synchronous protocol, so the only thing that matters is whether or not the SDA line is still low on the next rising edge of SCL. As you can see in your first diagram, they all pull SDA low before that happens, so they are behaving correctly.

If this is causing problems on your I²C master, then it is implemented incorrectly.

In fact, the rising edges you've circled are caused when the master stops driving the SDA low itself, and have nothing to do with the slave devices' activity. They haven't yet driven the line at all.

(The timing variation you see is probably due to the asynchronous nature of your logic analyzer's sampling.)

Electronic – How is the clock frequency established between master and slave in I2C protocol

Following up the comments:

Yes, the frequency is hard-coded into some specific I2C-related registers. At runtime.

That said, your Arduino library might be doing some probing and rise time measurement on the bus for determining a viable clock rate. Let's see.

After doing a bit of source-digging, the answer is in twi.h

#ifndef TWI_FREQ
#define TWI_FREQ 100000L
#endif

Another piece from that very file:

TWBR = ((CPU_FREQ / TWI_FREQ) - 16) / 2;

Where TWBR stands for Two Wire Baudrate Register I suspect.

I'd call that enough evidence and definitely say, yes your I2C frequency is set directly by your library without any negotiations. If you want to change it, I'd suggest you #define TWI_FREQ before you #include twi.h (or indirectly through Wire.h)

Best Answer

Related Solutions

Electronic – I2C slave not pulling down SDA data line for the full clock cycle

Electronic – How is the clock frequency established between master and slave in I2C protocol

Related Topic