The history of i2c: why Philips built it in 1982

The problem

Why i2c was invented: too many wires in a TV set

In the early 1980s, Philips Semiconductors had a problem that looked like a hundred separate problems. The spec describes it as a pattern they noticed across their own products:

"In consumer electronics, telecommunications and industrial electronics, there are often many similarities between seemingly unrelated designs. For example, nearly every system includes: some intelligent control, usually a single-chip microcontroller; general-purpose circuits like LCD and LED drivers, remote I/O ports, RAM, EEPROM, real-time clocks or A/D and D/A converters; application-oriented circuits such as digital tuning and signal processing circuits for radio and video systems, temperature sensors, and smart cards."

That list is the origin story in disguise. "Digital tuning and signal processing circuits for radio and video systems" is a television. Philips made televisions, and a 1982 TV was becoming a computer: a microcontroller that had to tell a tuner which channel, a display driver what to show, and an audio chip how loud.

Every one of those conversations traditionally meant its own wires — a parallel bus, or a fistful of dedicated lines per chip. That costs pins on every package, traces on a board that has to stay cheap, and a fresh interface design for each new peripheral. Multiply by a product line and you're paying for the same problem over and over.

Philips' answer, in the spec's own words, was to build a bus "to exploit these similarities to the benefit of both systems designers and equipment manufacturers, as well as to maximize hardware efficiency and circuit simplicity". Two wires. Every chip on them. Addresses in software instead of pins.

The economics were the point, not the elegance. One interface design, reused across every chip Philips made, on two conductors that cost nothing to route.

The idea

What Philips got right in 1982

The decision that made i2c last was addressing in software. A chip doesn't need a chip-select pin, because it listens for its own 7-bit address and ignores everything else. Adding a device to a bus costs zero host pins — which is precisely why SPI, faster in every other respect, still loses whenever you have more devices than pins.

The second decision was open-drain wiring. No device ever drives the line high; pull-up resistors do that, and any device can pull it low. Two chips talking at once produces a defined result instead of a short circuit — which is what makes multi-controller arbitration possible at all, and why a stuck device can hang a bus rather than destroy it. That single choice explains most of what the protocol looks like, forty years on.

Both decisions trade speed for simplicity. In 1982, changing a TV channel, that was obviously the right trade. It's still the right trade for reading a temperature every second, which is why the bus never needed to change much.

The licensing

Why TWI exists, and one telling word

If i2c was so obviously good, why does your Atmel datasheet call it TWI — Two-Wire Interface — and describe the identical bus without ever saying "i2c"?

Because it was licensed. NXP's 1998 revision entry is explicit that the bus was by then "implemented in over 1000 different ICs and licensed to more than 50 companies". Using the name, and the addresses that came with it, meant a relationship with Philips. Atmel's workaround was to implement the protocol exactly and call it something else — which is why "TWI" and "i2c" describe the same wires to this day, and why our what is i2c page has to explain that they're the same thing.

Here's the detail I like. That 1998 sentence still exists in the current spec's revision history. And the introduction of the same 2021 document opens with the same claim, same numbers — one word different:

1998: "…implemented in over 1000 different ICs and licensed to more than 50 companies."
2021: "…implemented in over 1000 different ICs manufactured by more than 50 companies."

The patents expired, and the sentence quietly changed verb. Nobody announced it. It's just sitting there in the document, two pages apart, the whole licensing era opening and closing in the difference between licensed to and manufactured by.

Where it went

What i2c is used for now — mostly invisibly

Ask what i2c is for and you'll get sensors and displays. That's the visible half, and our what is i2c page covers which parts to reach for. The half nobody mentions is that i2c became infrastructure, and NXP's introduction names it plainly — the bus is used in:

• DDC (Display Data Channel) — the cable behind your monitor. When your computer knows the display's model and supported resolutions the instant you plug it in, that's i2c: VGA, DVI and HDMI all carry it, and the monitor answers with an EEPROM read. Every screen you've ever connected did an i2c transaction before it showed a picture.
• SMBus — the System Management Bus on essentially every PC motherboard, an i2c derivative with stricter timing. Fan speeds, voltages, temperatures, battery status.
• PMBus — power supplies that report and take instruction.
• IPMI — server management: the interface that lets a datacentre power-cycle a machine whose OS has died.
• ATCA — telecom equipment shelves.

Add the i2c HID Device in Windows Device Manager — your laptop's touchpad, which is i2c wearing a Microsoft input protocol — and the picture inverts. i2c isn't primarily a hobbyist bus that also appears in computers. It's a computer-industry bus that hobbyists also use. Philips solved the TV problem so thoroughly that the solution outlived the problem and colonised everything else.

The Arduino ecosystem is a late arrival to a party that started in a Dutch television.

The rename

2021: controller and target

The most recent revision, Rev. 7.0 of 1 October 2021, is almost entirely a vocabulary change. NXP's own changelog gives the reason without ceremony: the terms master and slave became controller and target "to align with MIPI I3C specification and NXP's Inclusive Language Project".

Nothing electrical moved. A controller is what a master was; a target is what a slave was; the waveforms are identical. Every datasheet, library and tutorial written before October 2021 — which is most of them — describes exactly the same bus in the older words. If you're reading two sources that disagree on vocabulary, they don't disagree on anything else.

The alignment with I3C is the interesting part. MIPI's I3C is the backward-compatible successor: faster, with in-band interrupts (no more separate interrupt wire) and dynamic addressing (no more address conflicts). It's appearing in phones and professional hardware. It is not, on any visible timeline, replacing the i2c in a $2 sensor.

Why it lasted

Forty years and still the default

i2c is slow. It has no error correction beyond an ACK bit, a 112-address space that everyone crowds into the same corner of, a 400 pF ceiling that limits it to a board or a bench, and a clock-stretching feature that even the Raspberry Pi's silicon gets wrong.

It won anyway, and it's still winning, because the trade Philips made in 1982 turned out to be permanent. Most chips in most systems have almost nothing to say. A temperature sensor produces a few bytes a second. A real-time clock produces seven. For traffic like that, bandwidth is worthless and pin count is everything — and a bus that costs two wires no matter how many devices you hang on it is unbeatable at that job.

Forty years of hardware got faster around it, and it never mattered, because the problem it solves isn't a speed problem. That's why a spec whose last meaningful change was in 2007 still describes the bus under your fingertips right now.

The protocol itself, byte by byte, is in how i2c works. What it is and what to build with it: what is i2c.