These are the exact fragments the model serves — also available as an
ordered study guide.
Two wires for a whole cluster of parts
One controller and several peripherals all tap the same two shared wires, SDA and SCL; each peripheral carries its own address.
I2C (Inter-Integrated Circuit, said "eye-squared-see") is a bus that connects a controller to many peripherals over just two shared wires. One wire carries the data, the other carries a clock, and every chip on the board taps the same two lines. A handful of small sensors and a display can all hang off that one pair, and the controller talks to each of them in turn without a fresh set of wires per device.
What makes two wires enough for a crowd is that each peripheral has an address. When the controller wants a particular chip, it puts that chip's address on the bus; the addressed one answers and the rest stay quiet. So the sharing is not a free-for-all — it is one controller calling on named devices, one at a time, over wires they all hold in common.
That is the whole promise of I2C, and it is a direct answer to the pin problem: a controller has far more it wants to talk to than it has pins to spare, and here a single two-wire bus serves a whole cluster of parts. The cost is that everyone shares one lane, so the parts take turns and the bus runs at a modest speed rather than a blazing one. The rest of this concept is how those two wires pull it off.
SDA carries data, SCL carries the clock
Each SCL clock tick, driven by the controller, marks when the receiver reads the bit held on SDA: one bit per beat.
The two wires have names. SDA is the serial data line — the bits of every address and every byte travel here, one after another. SCL is the serial clock line, and it does exactly one job: it ticks, and each tick marks the moment to read the bit sitting on SDA. Data on one wire, timing on the other.
I2C is synchronous, which means the timing is not guessed but handed over explicitly. The controller drives SCL, generating every clock pulse itself, and a bit is only valid on SDA while the clock is holding steady. The receiver does not have to know in advance how fast the bits are coming; it just watches the clock and reads SDA on each beat. That is the difference a clock wire buys — the sender sets the pace and the receiver follows it exactly, instead of both sides having to keep the same time on their own.
Because the controller owns the clock, it also owns the tempo of the whole conversation. Nothing moves on the bus unless the controller is ticking SCL, so a peripheral can never run ahead or flood the line — it puts its bits out only as the clock invites them. Two wires, then, split the labor cleanly: one says what, the other says when.
Everyone can pull low, nobody drives high
Each device can only pull the shared line LOW or release it; a pull-up resistor to the supply restores HIGH when no device pulls, so devices never fight.
Both SDA and SCL are wired a particular way called open-drain, and it is the trick that lets many devices share a line safely. An open-drain output can do only two things: connect the wire to ground, pulling it LOW, or let go of it entirely. It can never actively push the wire HIGH. So a device asserts a zero by pulling down, and asserts nothing by releasing.
On its own, a released line would just float at no particular level, so each line carries a pull-up resistor to the supply rail. When no device is pulling down, the pull-up gently lifts the wire to HIGH; the instant any device pulls down, it easily overrides that gentle pull and the line reads LOW. It works like many hands on one rope that can only ever pull it down, with a spring at the top that lifts it back up whenever everyone lets go: no two hands can pull against each other, because there is only one direction to pull. The resting state of a quiet bus is HIGH, and a LOW means at least one device is actively holding it there.
This is what makes contention impossible. If two devices could each drive the line to opposite voltages, connecting them would be a short and a fight over who wins. Here there is no opposite to drive: every device can only pull toward the same place, ground, and the pull-up handles the other direction for all of them. Many chips on one wire, and the worst that happens when two speak at once is a LOW instead of a HIGH — never a damaging clash. Sharing is safe because the electrical design leaves nothing to fight over.
A 7-bit name, and only one answers
The controller puts a 7-bit address plus a read/write bit on the bus; every peripheral compares it to its own address and only the match acknowledges.
Every peripheral on an I2C bus has an address, and in the common scheme that address is 7 bits wide. Seven bits gives 2^7, which is 128, distinct addresses. Sixteen of them are reserved by the specification for special purposes, so 112 are left for ordinary devices — still far more than the small cluster of chips a typical two-wire bus carries. Each chip knows its own address, often fixed by the manufacturer with a pin or two left to nudge it if two of the same part must coexist.
A transfer opens with the controller sending that address on SDA, and it packs one more bit on the end: a read/write bit that tells the addressed chip which way this transfer will go — the controller reading from it, or writing to it. The 7 address bits plus that 1 direction bit make the first 8-bit byte of every exchange. Every device on the bus hears it, but each compares those address bits against its own and only the one that matches pays any further attention. It is a like a name called out over a room where everyone can hear it: only the person whose name it is answers, and the rest simply wait for a name of their own.
That comparison is the entire reason two shared wires can serve a room full of chips without confusion. The controller does not need a separate wire running to each device to pick it out; it just speaks the right name, and the bus itself sorts out who was meant. The addressed peripheral answers; the others treat the rest of the transfer as none of their business until the next address goes by.
START, address, ACK, data, STOP
One I2C transfer in order: a START condition, the address byte with its ACK, a data byte with its ACK, then a STOP condition, all on the SDA and SCL lines.
An I2C exchange has a fixed shape, and it begins and ends with two special signals. Normally SDA only changes while SCL is LOW, between clock ticks. The exceptions are the frame markers: a START condition is SDA falling from HIGH to LOW while SCL is still HIGH, and a STOP condition is SDA rising from LOW to HIGH while SCL is HIGH. Because those two moves are illegal during ordinary data, every device recognizes them instantly as "a transfer is beginning" and "a transfer is done."
Between the START and the STOP, everything moves a byte at a time, and each byte gets a receipt. The controller clocks out 8 bits, and then, on a ninth clock pulse, it releases SDA so the receiver can answer. The receiver pulls SDALOW to say ACK — got it, send more — or leaves it HIGH, which reads as NACK, meaning not received or no more wanted. So each byte is a like handing over a message and waiting for a small nod before handing over the next: the nod confirms it was taken, and its absence means it was not, and the whole transfer is a run of them: the first byte carries the address and its read/write bit, its ACK confirms a device is present and listening, then data bytes follow, each with its own ACK, until the controller issues the STOP.
Read the pattern once and every I2C transfer looks the same underneath: START, the addressed byte, an acknowledgement, some data bytes each acknowledged, STOP. A missing acknowledgement is not a footnote either — a NACK where an ACK was expected is exactly how the controller learns that the chip it called for is not there, or has had enough. The framing and the receipts are what turn a shared pair of wires into an orderly conversation with a beginning, a confirmation, and a clean end.
How fast the clock is allowed to run
Because the controller drives SCL, the speed of an I2C bus is just how fast it ticks that clock, and the specification defines named grades for it. The two everyday ones are Standard-mode at up to 100 kHz and Fast-mode at up to 400 kHz. Most small sensors a build talks to are perfectly happy at one of those, and a great deal of real hardware never needs more.
Higher grades exist for parts that move more data. Fast-mode Plus reaches up to 1 MHz, and High-speed mode up to 3.4 MHz; there is even an Ultra Fast-mode at up to 5 Mbit/s, though it runs in one direction only and is rarely met in ordinary builds. A device advertises the top grade it supports, and the bus can run no faster than its slowest participant — pick a clock every chip on the line can keep up with, and the shared arrangement stays honest.
These numbers set expectations more than they set rules. At 400 kHz a bus is shuttling hundreds of thousands of bits a second, which is ample for polling a cluster of sensors many times over but nowhere near what a link streaming video would demand. Knowing the grades is mostly knowing where I2C sits: quick enough for control and sensing, and deliberately not built to be the fastest wire on the board.
Few wires for many devices, at a price
Every interface is a package of tradeoffs, and I2C's is easy to name: it spends the fewest wires to reach the most devices. Two lines, SDA and SCL, carry a whole cluster of addressed chips, and adding another peripheral usually costs no new wires at all — just another address on the bus already there. For a board crowded with small parts a controller only needs to check on now and then, that is close to ideal.
The price is speed and a little overhead. Sharing one lane means the parts take turns, the open-drain lines and their pull-ups limit how fast the voltages can swing, and every transfer spends bits on an address and an acknowledgement before any data moves. So I2C is unhurried by design. Where SPI reaches higher speeds by giving each device its own select line and a richer set of wires, and UART links just two devices directly with no addressing at all, I2C takes the opposite bargain — more devices and fewer wires, in exchange for a slower, shared bus. Those siblings are separate concepts; the point here is only that I2C sits at the many-devices, few-wires corner of the same design space.
That corner is exactly where a lot of everyday hardware lives. When the question is "how do I hang half a dozen little sensors off one controller without running out of pins," I2C is usually the answer, and its modest speed is a price worth paying. Reach for it when devices are many and small and the data is light; look elsewhere when one link has to move a flood of data fast.
The sensor bus of a small build
On a small self-driving car, the controller has to feel a lot at once, and much of what it feels arrives over I2C. A build like that carries a scatter of little sensor chips — a motion sensor to tell which way it is tipping and turning, a magnetometer for heading, sometimes a distance or light sensor or two — and each is a small part that reports light, occasional readings. That is precisely the peripheral I2C was made for, so the natural wiring is to hang them all on the same two lines and let the controller call each one up by address.
The payoff is in the pin budget. A microcontroller has only so many pins, and spending a dedicated set on every sensor would run it out fast. Put those sensors on one I2C bus and the whole cluster costs two pins total, leaving the rest for the motors, the wheels, and everything else that genuinely needs its own wire. The controller walks the bus — address a sensor, read its bytes, address the next — fast enough to keep a steady picture of how the car is moving.
That is why I2C earns its place between the raw pin-level concepts and the parts that ride on top of it. The sensors a build reads over this bus are their own concepts, and what they measure is their story to tell; I2C is the shared road their readings travel. Learn how the two wires address a crowd, frame a transfer, and acknowledge each byte, and a whole shelf of sensor chips stops being a wiring problem and becomes a list of addresses to visit.