I²C in Real Systems on Embedded Systems Development

I²C Initialization & Clock Configuration

Mon, 01 Jan 0001 00:00:00 +0000

I²C Initialization & Clock Configuration#

Every I²C transaction depends on the peripheral being correctly initialized: GPIO pins configured as open-drain with alternate function, the I²C clock enabled via RCC, and the timing registers set to produce the desired SCL frequency. Getting any of these wrong produces symptoms that range from no activity on the bus to intermittent NACKs that appear device-dependent but are actually timing violations. The initialization code is typically short — 10 to 20 lines — but the details inside those lines determine whether the bus works reliably at 400 kHz or silently falls back to unpredictable behavior.

Multi-Byte Read/Write Patterns

Mon, 01 Jan 0001 00:00:00 +0000

Multi-Byte Read/Write Patterns#

Most I²C devices expose a register-based interface: a write transaction sends the register address, and a read transaction retrieves the data at that address. The protocol detail that makes this work is the repeated start condition — a start without a preceding stop — which allows the master to switch from write mode (sending the register address) to read mode (receiving data) without releasing the bus. Nearly every sensor, EEPROM, and I/O expander uses this pattern, and understanding the transaction structure at the byte level is essential for debugging transfers that silently return stale or incorrect data.

Error Recovery & Bus Reset

Mon, 01 Jan 0001 00:00:00 +0000

Error Recovery & Bus Reset#

I²C errors fall into two categories: protocol-level errors that the hardware peripheral detects (NACK, arbitration loss, bus error) and bus-level failures that the peripheral cannot self-recover from (stuck SDA, phantom busy flag). The first category is handled by error callbacks and retry logic. The second requires manual intervention — toggling GPIOs, resetting the peripheral, or power-cycling the bus. Firmware that does not handle both categories will eventually lock up in the field, because every I²C bus will eventually encounter a stuck condition, and no amount of software reset will clear a slave device that is holding SDA low mid-byte.

Multi-Master & Arbitration

Mon, 01 Jan 0001 00:00:00 +0000

Multi-Master & Arbitration#

I²C was designed from the start to support multiple masters on the same bus. Arbitration — the mechanism that resolves contention when two masters transmit simultaneously — is built into the protocol at the electrical level, not as an optional extension. In practice, multi-master I²C is uncommon in small embedded systems because the firmware complexity it introduces rarely justifies the architectural benefit. Understanding the arbitration mechanism is still essential, because arbitration loss can occur even in systems that were not designed as multi-master — a stuck slave or a bus fault can trigger arbitration loss interrupts that firmware must handle gracefully.