So effectively writing 1 to TWINT acknowledges the interrupt, so that the next byte can be processed. Also note that clearing this flag starts the operation of the TWI, so all accesses to the TWI Address Register (TWAR), TWI Status Register (TWSR), and TWI Data Register (TWDR) must be complete before clearing this flag. Note that this flag is not automatically cleared by hardware when executing the interrupt routine. The TWINT Flag must be cleared by software by writing a logic one to it. While the TWINT Flag is set, the SCL low period is stretched. In the library, this appears to be achieved by a call to twi_releaseBus which sets the TWINT flag.

This lets slower slaves control the speed at which bits are clocked out to them by stretching the low part of the SCL pulse. Then when the master releases the SCL line (so it floats back high) it actually has to check that the line actually went high, and if not, wait until it does. It appears that I2C is designed so that, although the master initiates the transfer of a bit (by bringing the SCL line low), the slave can prolong the period of that clock pulse by also bringing the SCL low (after the master does). It is interesting for example that 1-Wire is slower again.Īfter extensive reading of the Atmega documentation, and running an experiment, I'm inclined to agree with this.

There are probably more subtle reasons.

SPI does not wait for any sort of acknowledgement - this must make it able to be designed to be faster.The reply to a query comes down the same data line, so both ends are constantly reconfiguring inputs as outputs, and then open-drain.This would take time and the receiver needs to be given time to do it.

The data line in particular is two-way, that is, after every 8th bit the sender waits for an ACK from the receiver.Since it uses open-drain and pull-up resistors, the transition from low to high is necessarily electrically fairly slow, as it relies on the pull-up (possibly some distance away) to bring the line back to the high state (compared to SPI which drives the line low/high 'manually' all the time).But why does it have a slower clock rate? Are you asking why is I2C so slow? I think the answer basically is that I2C has a slower clock rate.

Arduino wire library change baud rate