ATMEGA TWI / I2C Slave - How to implement clock stretching?

Question

I am programming a TWI slave based on an ATMEGA644PV.

It is working in general, the master can send and read data from the slave. So far so good.
But on some read-requests, the slave requires "more time" to prepare the data. I would like to utilize clock stretching to make the master wait until the data is ready.

The ATMEGA datasheet points out:

The Slave can extend the SCL low period by pulling the SCL line low. This is useful if the clock speed set up by the Master is too fast for the Slave, or the Slave needs extra time for processing between the data transmissions.

This is exactly what I want, but I don't get how to implement this on the driver level. I see no way to indicate to the I2C slave hardware that it shouldn't immediately ACK, but instead pull the SCL for a period of my choice.

From what I get, I can only tell the slave to ACK or - well - not to ACK at all after being addressed or a data byte being transferred.

Am I missing something obvious here? This is the first time I look at I2C from the view of a slave.

Answer 1

The Atmel Atmega processors (including the Atmega644) automatically perform clock stretching whenever the I2C interface needs an action performed by the software.

This action could be when a slave has received a byte of data and the data needs to be removed from the data register before the next byte can be received or when data is needed to transmit. It happens whenever the TWINT flag is set.

The data sheet does not highlight the fact much but it is mentioned in a few places (such as in section 19.5.5 on page 207 on the 02/12 datasheet).

Answer 2

Refer to the following schematic to see the most commonly-used interface between I2C master and slave devices. This interface does not use clock-stretching. The master generates all the clock signals on SCL with SW2 (and the slave only receives these clock signals).
Data can transfer both ways - from master-to-slave with SW1, or from slave-to-master with SW3. Of course, both ends must agree on who can control the SDA data line, to avoid collisions. By "control", I mean that the switch is closed, shorting the data line to ground. An open switch allows the SDA line to rise up to supply voltage through the pull-up resistor. A closed switch has "control" of the SDA line, pulling it to ground (low). An idle bus has all switches open.

^{simulate this circuit – Schematic created using CircuitLab} In the above schematic, the master clocks SW2 at a rate of 100k cycles-per-second (or 400k for high-speed), expecting the slave to keep up. In a clock-stretched system, the master initiates a clock cycle by closing SW2, and opens SW2 a short time later (that would normally end that clock cycle). But it monitors the clock line with BUF4 to see if R2 has actually pulled back to the idle high state. If the slave switch SW4 keeps the clock line low, that's a clock stretch, holding up further data transfers:

^{simulate this circuit} A slave device very often has no way to perform a clock-stretch, because SW4 doesn't exist, or if it does exist, there's no way to close it. But any microcontroller has GPIO pins that can do the SW4 function - pulling low to ground. The timing of SW4 is critical: it must be pulled low only while SW2 is also pulling low, to do the slave clock-stretch function. So the pseudo-code for controlling the GPIO pin (SW4) on the slave goes like this:
Initialize GPIO pin to be an input (read). When Slave must clock-stretch, continually monitor GPIO pin, looking for "low". While SCL is low, change GPIO to be output pin, set to logic "0". Keep low until Slave is ready to continue. Once Slave is ready, change GPIO to be input, clearing the clock-stretch.

The ACK or NACK data bit transfer is mostly used to ensure master & slave are alive, and in-sync.