A board has a temperature sensor, a power controller, an EEPROM and a clock chip, all on the same two wires. Any of two processors may start a transaction at any time. A slow EEPROM can hold the clock to make the master wait, and every byte is acknowledged by its receiver. All of it works with no extra wires, because of one electrical trick: nobody ever drives a line high.
How does I2C answer each question, and how much of it follows from the open-drain bus?
Constraint | I2C |
|---|---|
C1 Distance and medium | Short: one board, modest capacitance |
C2 Bandwidth and latency | Low: 100 kbit/s to 1 Mbit/s typically (fact S22) |
C3 Wires | Two: SDA (data) and SCL (clock), both open-drain with pull-ups |
C4 Topology | A shared bus with many slaves and possibly several masters |
C5 Who builds each side | Many vendors, one specification (NXP UM10204) |
Each answer links to the lesson that explains the idea behind it.
# | Question | Answer |
|---|---|---|
1 | When is the data valid? | The master drives SCL; data on SDA must be stable while SCL is high (fact S1) (1.1) |
2 | Where does a message start and end? | START and STOP are SDA edges while SCL is high, which normal data never makes (2.9) |
3 | Is the receiver ready? | The receiver acknowledges every byte on the ninth clock; a slave that needs time holds SCL low (clock stretching), a wait state (3.2) |
4 | How much may I send before I hear back? | Per byte: acknowledge or no acknowledge, plus clock stretching to slow the master (4.2) |
5 | What exactly is being asked? | Reads and writes to a 7-bit (or 10-bit) address; register meaning is device-specific (fact S22) (5.3) |
6 | How many requests can be in flight? | One transaction at a time on the bus (6.3) |
7 | In what order do results become visible? | Strictly in order: one transaction, one byte at a time (7.1) |
8 | Who gets the wire? | Multi-master: wired-AND arbitration bit by bit; a master that sends 1 but sees 0 has lost and stops (fact S15) (8.6) |
9 | Why can it hang? | A slave stuck holding SDA or SCL low hangs the whole bus; masters clock SCL until SDA is released, or reset the bus, with timeouts (9.9) |
10 | What if bits go wrong? | No CRC or parity; a missing acknowledge reports an absent or refusing receiver (10.7) |
11 | How do the two sides agree at start-up? | No negotiation or enumeration; addresses are fixed or set by pins; a master can probe for acknowledges (11.6) |
12 | How do we save power without losing data? | Not addressed by the protocol; an idle bus draws only pull-up leakage |
13 | What if there are several copies of one value? | Not applicable |
14 | Who is allowed to ask? | Not addressed: any device on the bus can talk to any address |
15 | How do we know it is correct? | Compliance is against the NXP specification; tests cover stretching, arbitration loss and stuck-bus recovery (15.6) |
Open drain, wired-AND: any device can pull a line low, none drives it high, so devices can share lines without contention.
Arbitration for free: two masters sending together are sorted out bit by bit without corrupting the winner's message.
Clock stretching: the same wired-AND lets a slave stall the master by holding SCL low.
Acknowledge per byte: cheap presence and readiness feedback on every byte.
A board (illustrative) hung its I2C bus whenever a processor reset in the middle of a read: the slave was part-way through sending a byte with SDA held low, and the restarted master saw a busy bus for ever. The standard recovery fixed it: on start-up, the master toggles SCL up to nine times until the slave releases SDA, then sends a STOP. Every robust I2C master implements it.
Nobody drives high; lines are pulled up, so a device driving 0 against another releasing simply produces 0.
No slave at that address responded: it is absent, busy or refusing.
I2C: two open-drain wires shared by many devices, with addresses, START and STOP conditions.
Wired-AND gives arbitration, clock stretching and per-byte acknowledgement.
Speed is limited by pull-ups; one stuck device can hang the bus, so recovery is essential.