I2C Communication Protocol Animation

Watch START, address, R/W, ACK, data, repeated START, clock stretching, and bus arbitration on a two-wire I2C bus.

animation
i2c
serial-communication
sensing
actuation
protocol
intermediate
Animation I2C Timing Debugging

I2C Communication Protocol Animation

Follow an I2C transaction as a master uses the shared SCL and SDA lines to address one device, exchange bytes, wait for ACKs, handle repeated START, and expose common bus problems such as slow pull-ups, clock stretching, address conflicts, and arbitration loss.

Temp sensor 0x48 Selected target device
Register read Transaction pattern
ACK expected Receiver response on bit 9
Rise OK Pull-up and capacitance check
What is moving? The red cursor moves across the SCL/SDA timing diagram. Each cell is a START, data bit, ACK, repeated START, or STOP event.
Try first Press Step through the temperature read preset. Watch SDA stay stable while SCL is high, except during START and STOP.
Read the result The diagnosis explains whether the bus is healthy, waiting because of clock stretching, ambiguous because of address conflict, or too slow to rise.
Core idea I2C is open-drain. Devices pull low; pull-up resistors return the bus high. That electrical detail shapes protocol behavior.
1 Idle SCL and SDA sit high because the pull-up resistors release the bus.
2 START The master pulls SDA low while SCL is still high. Every slave starts listening.
3 Address Seven address bits are sent MSB first, followed by the R/W direction bit.
4 ACK The receiver pulls SDA low on the ninth clock. High means NACK.
5 Data Bytes move MSB first. A register read uses a repeated START before switching to read.
6 STOP The master releases SDA high while SCL is high, freeing the shared bus.

Bus and Timing Animation

Idle bus: no device is pulling the lines low, so pull-up resistors hold both SCL and SDA high.

Step 0 of 0
I2C shared bus with master, pull-ups, and four slave devices The selected slave device is highlighted. SCL and SDA are shared by all devices. SCL SDA pull-ups to VCC Master MCU drives clock EEPROM 0x50 Temp 0x48 OLED 0x3C RTC 0x68 Only the addressed device should respond with ACK. Duplicate addresses make the ACK ambiguous.
I2C timing diagram SCL and SDA waveforms, bit cells, sample points, and active cursor. SCL SDA Data changes while SCL is low; receivers sample while SCL is high. Idle
Current event Idle
Address frame 0x48 + W
Electrical rise 224 ns
Bus state Ready
Healthy I2C transaction The addressed device ACKs, SDA is stable during SCL-high sample windows, and the pull-up network is fast enough for the selected speed mode.
Why it matters START and STOP are the two legal times SDA changes while SCL is high. During data bits, changing SDA while SCL is high would be misread.
Debug habit When a transaction fails, first check pull-ups and address ACK before debugging firmware parsing.
Quick Reference: What to Look For on I2C
START and STOP These are the exceptions to the data-stability rule.
  • START: SDA falls while SCL is high.
  • STOP: SDA rises while SCL is high.
  • Both lines idle high on a released bus.
Address plus R/W A 7-bit address is followed by one direction bit.
  • 0 means master writes to slave.
  • 1 means master reads from slave.
  • The byte is sent MSB first.
ACK and NACK The receiver owns the ninth clock bit.
  • ACK: receiver pulls SDA low.
  • NACK: SDA remains high.
  • Master usually NACKs the final read byte before STOP.
Repeated START Used when the master wants to keep bus ownership.
  • Common pattern: write register address, repeated START, then read data.
  • No STOP appears between the write and read phases.
Clock stretching A slave may hold SCL low to delay the next bit.
  • The master must wait if it supports stretching.
  • Some controllers or software stacks do not tolerate long stretches.
Electrical limits Open-drain signaling makes pull-ups part of the protocol.
  • Too-weak pull-ups and high capacitance slow rising edges.
  • Too-strong pull-ups increase sink current.
  • Shorter buses and lower capacitance give more margin.
Technical Accuracy Notes: What the Model Does and Does Not Prove
Open-drain behavior I2C devices actively pull low and release high. The animation treats a high bit as released SDA/SCL, not as a driven high output.
Rise-time estimate The model uses the common first-order estimate tr ~= 0.8473 x R x C. It is useful for screening, but layout, device capacitance, level shifters, and measurement threshold matter.
Speed-mode limits The built-in checks use typical I2C rise-time maxima: 1000 ns for Standard mode, 300 ns for Fast mode, and 120 ns for Fast-mode Plus.
Address conflicts If two slaves share one address, both can ACK. The bus cannot tell which one accepted the transaction unless hardware addressing or a multiplexer separates them.
Arbitration Arbitration is shown at bit level: a master loses when it attempts to send a released high but reads back low. Low dominates on an open-drain bus.
Not a compliance tester The page does not replace an oscilloscope, logic analyzer, or data-sheet timing check. It is a learning aid for recognizing protocol phases and likely failure causes.
Example Debug Readings
Address scan finds nothing Check wiring, power, common ground, pull-ups, and whether the device uses an alternate address pin setting.
ACK appears but data is wrong Confirm register address order, repeated START requirements, byte order, and whether the final read byte should be NACKed.
Works at 100 kHz, fails at 400 kHz Suspect rise time, bus capacitance, level shifters, long wires, or a device that does not support the faster mode.
Check 1: Repeated START Use Temp register read. Which phase writes the register address, and why is there no STOP before the read address?
Check 2: Pull-up margin Increase capacitance at 400 kHz. When does the rise-time warning appear, and what hardware change helps?
Check 3: Arbitration Enable multi-master arbitration. Which master loses, and what bus observation proves it lost?
Compare with SPI SPI avoids address ACK and open-drain pull-ups, but uses more wires and chip-select lines. Open SPI animation
Use the bus visualizer Compare I2C and SPI side by side when choosing a sensor interface. Open I2C/SPI visualizer
Connect to hardware Use the sensor interfacing chapter to connect protocol behavior with wiring and firmware patterns. Open sensor interfacing