“This goes to 11. It’s one better.” – Nigel Tufnel, “This Is Spinal Tap”

They say there are 10 kinds of people: those who understand binary arithmetic and those who don’t. Over at the MIPI Alliance, they’ve gone one better, too.

If you’re not a follower of MIPI, this is the nonprofit group that defines interface standards for small, mobile, and handheld devices. (BTW, MIPI stands for… nothing at all. They just liked the way it looked, apparently.) It’s not the only such group, for sure, but it’s one of the more successful ones, in the sense that its standards actually do get adopted and used.

The newest specification to come out of MIPI is I3C, and if you’ve already guessed that it’s the successor to I²C, you’re right. I3C (without the superscript, note) is a simple two-wire interface for connecting tiny sensor chips to your applications processor. It works a lot like I²C, but better.

For background, I²C – the inter-integrated circuit interface – dates back more than 30 years, to an in-house chip-to-chip interface developed at Philips (later NXP) for its MCUs and peripheral chips. The interface proved so popular that Philips started licensing it to other chipmakers, reasoning that the more widespread the interface became, the more popular its chips would be. Besides, an interface isn’t all that useful unless two or more chip families adopt it, right?

The I²C interface is now so popular and so widespread that any decent microcontroller is expected to have at least one or two I²C interfaces on it. NXP doesn’t even charge royalties for using it, although the company still is in charge of handing out unique hardware addresses for compatible chips, sort of like IEEE and Ethernet MAC addresses.

Both the new I3C and the old I²C use just two wires: a clock and a data line. It’s a multi-drop bus, meaning you can hang multiple slave chips (sensors, mostly) off the same pair of wires. The shared data line is an open-collector signal with a pullup resistor, so multiple slaves can yank on it simultaneously. That’s an important feature when you’re attaching cheap, brain-dead devices that don’t have complex interface logic.

But whereas I²C ran at about 400 kHz, I3C runs at a minimum of 1 MHz, and up to 12.5 MHz. So yeah, it’s faster. It’s also smarter about transferring data, so the maximum bandwidth increases faster than clock frequency, up to 33.3 Mbits/sec.

The control logic for I3C is considerably more complex than for I²C because there are so many new features. Slaves can now initiate interrupts, for example, by toggling the data line and requesting service. There follows an acknowledge/response phase, with possible arbitration if more than one slave requests service at the same time. Shoehorning all of this into the same two wires (really just one wire, plus a clock) requires some deft legerdemain that I²C couldn’t manage. 

You can add new I3C devices to an already configured system, a feature called “hot joining,” that was never envisioned in I²C days. This allows for actual, physical connections (such as when a peripheral in plugged into a socket), but it also permits slave devices to power-down, effectively removing themselves from the bus, and then power back up again and rejoin the party.

And, in case you were wondering, yes, I3C is backward compatible with I²C. You can hang old I²C slaves on the same bus as new I3C devices, and they’ll work together. You won’t get the 33.3-Mbps bandwidth of a pure I3C-only system, but you also won’t have to toss out and replace all your old peripherals and sensors.

Compatibility has its cost, however. Even though I3C is a brand new interface specification, it’s still slower than the competing SPI interface, Freescale’s age-old four-wire bus for dumb peripherals. SPI has a theoretical maximum bandwidth of 60 Mbps, nearly twice as fast as I3C in its quickest mode.

Granted, SPI uses four wires instead of two, so there’s some (very) modest cost in PCB layout and package pin count over I²C or I3C. But SPI is more power-efficient than I²C, because it doesn’t use open-collector signals and thus avoids the nasty pullup resistors and high-current drivers. I²C dissipates energy whether it’s active or not; SPI is a lot less hungry when it’s quiet.

So what about I3C’s power profile? MIPI Alliance alleges that it’s more power-efficient than either I²C or SPI, in part because it doesn’t always need those pullup resistors. In its high-speed modes, I3C supports conventional push-pull circuits, which makes for faster clock edges, higher data rates, and more sleep time between transactions (for chips that support it). The high-speed modes also support data formats that are more space- and power-efficient than the old I²C data transfers. You wind up transferring more data per clock edge than before, saving time and power. Finally, I3C’s new interrupt capability means a sensor can request service only when it needs it, rather than being polled unnecessarily.

Since it’s backward-compatible, there’s little reason for current I²C users not to upgrade gracefully to I3C. You won’t see all the benefits right away, but, once the last legacy I²C device is banished from the bus, it’s time to crank up the clock speed up to eleven and rock and roll.