I2C. Two Wires for Everything (as Long as You Get the Pull-ups Right)

I2C was designed in 1982 at Philips to let a microprocessor talk to support chips on the same board. EEPROMs, real-time clocks, DACs. without burning a pile of GPIOs. Two wires, shared by everyone on the bus, with addressing baked into the protocol. It's still the standard way to connect sensors and low-speed peripherals to a microcontroller today.

It's also the protocol most likely to waste your afternoon when something goes wrong. usually because the pull-up resistors are missing, wrong value, or interacting badly with capacitance from a long cable. Once you understand the electrical model, the debugging gets a lot faster.

The electrical model first

Both lines. SDA (data) and SCL (clock). are open-drain with external pull-ups. No device ever drives a line HIGH. Instead, every device on the bus can pull a line LOW by turning on a transistor. When nobody is pulling LOW, the pull-up resistor brings the line HIGH passively.

This is what makes I2C a true multi-master bus: two devices can share SDA and SCL without a dedicated master controlling direction. Any device that wants to transmit just starts pulling lines LOW and reading back what's on the bus.

Rendering diagram...

Pull-up values: 4.7kΩ for 100kHz standard mode, 2.2kΩ for 400kHz fast mode. At 1MHz (fast-plus) you need 1kΩ or less, and at that point the driver strength specs start to matter. For most sensor work. 100 or 400kHz, on-board only. 4.7kΩ and move on.

How a transaction works

Every transaction starts with a START condition: SDA falls while SCL is HIGH. Nothing else on the bus looks like that, so every device immediately knows to pay attention.

Then comes a 7-bit address and one R/W bit. Every device on the bus receives the address and compares it to its own. The one that matches pulls SDA LOW during the 9th clock pulse. that's the ACK. Everyone else stays silent.

Rendering diagram...

The NACK at the end of a read sequence is intentional. The master uses NACK on the last byte to tell the slave "that's all I need." After a NACK the master sends STOP and releases the bus.

Clock stretching

A slave can hold SCL LOW after the master releases it. This tells the master "wait. I'm still processing." The master must check SCL before advancing to the next bit. Most hardware I2C peripherals handle this automatically. Bit-banged I2C implementations sometimes don't, which causes mysterious data corruption with slow EEPROMs or sensors that need time to prepare a reading.

The repeated START pattern. don't get this wrong

Reading from most sensors is a two-phase operation: first write the register address you want to read, then read the data. Between those two phases, you should use a Repeated START, not a STOP + START.

Wrong:   [START][addr+W][reg][STOP][START][addr+R][data][STOP]
Correct: [START][addr+W][reg][RESTART][addr+R][data][STOP]

Some sensors accept either. Some (particularly older EEPROMs and a handful of I/O expanders) will reset their internal state on the STOP and return the wrong register. If you're reading a sensor and getting the right data but from the wrong register, Repeated START is where I'd look.

Address conflicts

7-bit addressing gives 128 possible addresses. A handful are reserved, leaving 112 usable ones. Most sensor ICs have one or two address-select pins that let you configure the low bits. so you can put two BME280s on the same bus (0x76 and 0x77), but not three.

When two devices share an address and you can't change either, the practical answer is a second I2C bus. Most STM32s have two or three I2C peripherals. On a Raspberry Pi, you can bit-bang a third bus on any GPIO.

I2C is a solid choice for anything slow and on-board. Sensors, EEPROMs, RTCs, display controllers, battery gas gauges. The moment you need to go more than a few tens of centimetres or need reliable high-speed transfers, there are better options.