🔗 I²C Communication

I2C stands for Inter-Integrated Circuit. In normal embedded systems it is a short-board or short-cable bus for slow peripherals: sensors, real-time clocks, display controllers, I/O expanders, EEPROMs and power monitors. It is not a magic two-wire network. It is a carefully timed agreement about how shared open-drain lines behave.

By the end, you can

1. Explain why I2C uses open-drain SDA and SCL lines with pull-up resistors
2. Identify START, STOP, address, R/W bit, data byte and ACK/NACK in an I2C transaction
3. Convert a 7-bit device address into the 8-bit address byte seen on the wire
4. Explain what NACK, bus stuck low and clock stretching mean during debugging
5. Choose practical first checks for pull-ups, logic level, address and bus length
6. Distinguish I2C from UART and SPI by the way devices share wires and timing

Two wires, many listeners

An I2C bus has two named signal lines:

1. SCL, the serial clock.
2. SDA, the serial data line.

Every device on the bus connects to those same two wires. The controller, often called the master in older datasheets, creates transactions. Target devices, often called slaves in older datasheets, listen for their address and respond only when selected.

This is why I2C is popular on small boards. A temperature sensor, RTC, IMU and OLED can share the same two signal traces. Each still needs power and ground, and each still adds capacitance and possible failure modes, but the pin count stays low.

Open-drain is the safety trick

The reason many devices can share SDA and SCL is that they do not fight to drive the line high. I2C outputs are open-drain or open-collector. A device can pull a line low. To send high, it releases the line and lets a pull-up resistor bring it back to Vdd.

That creates wired-AND behavior:

1. If every device releases the line, the pull-up makes it HIGH.
2. If any device pulls the line down, the shared line is LOW.
3. No device should actively drive HIGH into another device that is pulling LOW.

This is not just protocol elegance. It is electrical self-defense. Without open-drain, two devices could drive opposite levels and short a supply through their output transistors. With open-drain, the low state wins safely.

?Why can multiple I2C devices share the same SDA wire without fighting each other?

• A They use open-drain outputs, so devices pull LOW or release the line; the pull-up provides HIGH
• B Each device drives a different high voltage
• C SDA is analog, so logic conflicts do not matter
• D Only one device is physically connected at a time

A transaction is address, bits and acknowledgments

An I2C transaction starts with a START condition: SDA falls while SCL is high. It ends with a STOP condition: SDA rises while SCL is high. During data bits, SDA is allowed to change while SCL is low, and it is sampled while SCL is high.

After START, the controller sends an address byte. In the common 7-bit form, the first seven bits are the device address and the final bit says read or write:

$$\text{wire byte} = (\text{address} \ll 1) + R/W$$

For device address 0x3C, a write transaction sends:

$$(0x3C \ll 1) + 0 = 0x78$$

A read transaction to the same device sends:

$$(0x3C \ll 1) + 1 = 0x79$$

That detail explains a common datasheet confusion. Some datasheets list the 7-bit address, like 0x3C. Others list the already-shifted write byte, like 0x78. If your scanner sees 0x3C but sample code says 0x78, both may be describing the same device from different layers.

After every 8 bits, a ninth clock appears for acknowledgment:

1. ACK: the receiver pulls SDA low on the ninth clock.
2. NACK: the receiver leaves SDA high.

NACK can mean no device at that address, wrong wiring, wrong voltage, device busy, read complete, or a transaction error. It is not one diagnosis. It is the bus saying, "that byte was not accepted here."

?An I2C display has 7-bit address 0x3C. What address byte appears on the wire for a write?

• A 0x78, because the 7-bit address is shifted left and R/W is 0
• B 0x3C, because the address is always sent unchanged
• C 0x79, because writes set the R/W bit
• D 0x77, because 0x77 is the maximum normal address

Drive the transaction

The widget below slows the bus down so the waveform is readable. Top trace is SCL, bottom trace is SDA. Watch the START condition, address bits, ACK slot, data byte and STOP condition.

Try these moves:

1. Change address and notice the address byte changes but the transaction shape remains.
2. Switch read/write and watch the final address bit flip.
3. Raise NAK chance past 0.5. The address is not acknowledged and the data byte does not follow.
4. Add clock stretching. SCL stays low longer because the target is holding the bus until it is ready.

Clock stretching is one of I2C's clever compromises. A slow device can hold SCL low to pause the controller. The controller must read the actual line state, not merely assume its own clock output went high. Some devices use stretching rarely; some do not support it; some firmware stacks time out if it lasts too long. When debugging, clock stretching is a fact to measure, not a theory to argue about.

The bus is a measurement problem

I2C bugs often look like software bugs until you put a scope or logic analyzer on the lines. A scan returns no addresses. A sensor works alone but fails when the OLED is connected. Reads work at 100 kHz and fail at 400 kHz. A device vanishes only when a motor runs. Each symptom can come from code, but each also has an electrical version.

Use this first-pass debug order:

1. Power and ground: verify each module has the correct supply and common ground.
2. Voltage level: 5 V pull-ups on a 3.3 V microcontroller can damage pins.
3. Pull-ups: confirm there is a pull-up on SDA and SCL, not only weak internals.
4. Address: check the 7-bit address and any address-select jumpers.
5. Speed: try 100 kHz before assuming a board can handle 400 kHz.
6. Waveform: inspect rise time, stuck-low lines, ACK slots and stretching.
7. Isolation: remove devices until the bus works, then add them back one at a time.

I2C is not UART and not SPI

I2C, UART and SPI all move bits, but their failure modes are different.

UART has no shared clock line. Both ends agree on a baud rate and timing tolerance. It is good for logs and point-to-point links.

SPI has a clock and separate chip-select lines. It is fast and simple electrically, but each device usually needs its own select signal.

I2C shares clock and data among addressed devices. It saves pins and board space, but rise time, address conflicts and stuck-bus recovery become part of the design.

Design the bus before the code

For a small ESP32 sensor bus, a sane first design looks like this:

1. Use 3.3 V devices or proper bidirectional level shifting.
2. Put external pull-ups on SDA and SCL. Start around 4.7 kΩ for a short 100 kHz or 400 kHz board bus, then measure.
3. Keep wiring short and avoid routing beside noisy motor or switcher nodes.
4. Check every device address before buying two modules that conflict.
5. Use ADC1/GPIO notes, boot-strapping notes and pin ownership notes before picking pins.
6. Add timeouts and stuck-bus recovery in firmware.
7. Verify with a scope or analyzer before blaming the sensor library.

Practice 1 warm-up

A sensor has 7-bit I2C address 0x44. What address byte appears on the wire for a read transaction?

↘ Show worked solution

Shift the 7-bit address left one bit, then set R/W to 1 for read:

$$(0x44 \ll 1) + 1 = 0x89$$

So the wire byte is 0x89. The write byte for the same device would be 0x88.

Practice 2 core

An I2C address scan finds no devices. Name four checks you should make before changing the sensor driver code.

↘ Show worked solution

Check power, ground, voltage level, SDA/SCL wiring, external pull-ups, the expected 7-bit address, address-select jumpers and bus speed. Then look at the waveform: if SDA or SCL is stuck low, the problem is not the register-reading code.

Practice 3 stretch

A sensor reads correctly at 100 kHz but often NACKs or returns bad data at 400 kHz. What electrical cause should you suspect first, and what would you measure?

↘ Show worked solution

Suspect slow rising edges from too-weak pull-ups, too much bus capacitance or long wiring. Measure SDA and SCL rise time on a scope. If the released line has not reached a valid high level before the next sampling point, reduce speed, lower the pull-up resistance within sink-current limits, shorten the bus or reduce capacitance.

Key takeaways

• ▸I2C uses shared SDA and SCL lines. Devices pull LOW or release; pull-up resistors create HIGH.
• ▸START is SDA falling while SCL is high. STOP is SDA rising while SCL is high.
• ▸A 7-bit address becomes an 8-bit wire byte by shifting left and adding the R/W bit.
• ▸ACK means the receiver pulled SDA LOW on the ninth clock. NACK is a symptom, not a complete diagnosis.
• ▸Pull-ups, capacitance, logic level, address conflicts and stuck-low devices are first-class parts of I2C design.