What Is I3C, and How Does It Compare to I2C?

Detailed Explanation

I3C is a serial bus protocol developed by the MIPI Alliance, published as the publicly available I3C Basic Specification, positioned as I2C's successor for exactly the use case I2C has always served — connecting multiple sensors and low-speed peripherals to a controller over a shared two-wire bus — while addressing three of I2C's longest-standing limitations: fixed addressing, no built-in interrupt signalling, and a speed ceiling set by open-drain drive and pull-up resistor RC time constants. For I2C's own operation and pull-up requirements, see What Is I2C?

I3C reuses I2C's physical SDA/SCL pin pair and, during bus arbitration, its open-drain signalling — this is what makes backward compatibility with legacy I2C devices possible on the same bus, rather than requiring a parallel set of pins or a bus bridge.

I3C vs I2C: What Actually Changed

Dynamic Addressing and the Provisioned ID

I2C addresses are fixed by hardware — a pin strapped high or low selects between two or three possible addresses, which is why address collisions between identical parts on the same bus are a routine design constraint (see I2C's own address-collision guidance). I3C removes this constraint: every I3C device carries a 48-bit Provisioned ID (a globally unique identifier baked into the silicon, similar in spirit to a MAC address), and during bus initialisation the controller runs ENTDAA (Enter Dynamic Address Assignment), a Common Command Code that has every unassigned I3C device arbitrate for the bus using its Provisioned ID and receive a 7-bit dynamic address in response. Two identical I3C parts on the same bus resolve automatically, without an address-select pin or external multiplexer.

In-Band Interrupts (IBI)

I2C has no interrupt mechanism of its own — a sensor with a data-ready or threshold-crossing event needs a separate dedicated interrupt GPIO line back to the controller (see interrupts in embedded systems for how that line is typically handled in firmware), which consumes a pin per device and doesn't scale well on a bus with many sensors.

I3C's In-Band Interrupt lets a target signal the controller directly over SDA while the bus is idle: the target pulls SDA low during a defined interrupt-request window, and if multiple targets request simultaneously, they arbitrate using the same address-based arbitration mechanism the bus already uses, so the controller learns which specific device is requesting service as part of the same exchange — no separate interrupt line, and no ambiguity about which device to poll.

Common Command Codes and Hot-Join

I3C defines a set of Common Command Codes (CCC) — broadcast or direct commands the controller issues to configure bus behaviour, request dynamic addressing, or query device capabilities — that don't have an I2C equivalent. Hot-Join builds on this: a device that powers up or is physically connected after the bus has already been initialised can signal its presence and be assigned a dynamic address without requiring a full bus re-initialisation, useful for hot-pluggable sensor modules or expansion boards that weren't present when the controller first enumerated the bus.

Throughput: SDR and HDR Modes

I3C's baseline Single Data Rate (SDR) mode uses push-pull drive (rather than I2C's open-drain-only signalling) for the data phase of a transaction, which removes the pull-up resistor's RC-limited rise time as the speed bottleneck and allows clock rates up to 12.5 MHz per the I3C Basic Specification — roughly an order of magnitude above I2C's common 100 kHz–400 kHz range, though the exact achievable rate on a given board still depends on bus loading and trace length.

Beyond SDR, I3C defines optional High Data Rate (HDR) modes (including HDR-DDR, double-data-rate signalling) for applications needing still more throughput. Most sensor-hub use cases are well served by SDR alone; HDR modes matter more for higher-bandwidth applications closer to what a display or camera interface needs, where I3C is being evaluated as an alternative to dedicated high-speed interfaces.

Design Considerations

• Check I3C support per-part, not per-product-line. I3C adoption is genuine but uneven — verify each specific sensor or peripheral IC's I3C capability against its current datasheet rather than assuming an entire vendor family supports it.
• Plan the bus as mixed I2C/I3C during a transition period. Most real designs today combine I3C-capable parts with legacy I2C parts that have no I3C equivalent yet; the I3C controller's I2C-compatibility mode handles this, but confirm every legacy I2C device on the bus meets the timing requirements needed to coexist safely.
• In-Band Interrupts reduce GPIO pin count on sensor-dense boards. For a design with many interrupt-capable sensors, IBI can eliminate several dedicated interrupt lines that would otherwise each need to be routed and serviced individually — a genuine PCB layout and pin-budget benefit, not just a protocol curiosity.
• Confirm your MCU's I3C peripheral (or the lack of one) early. Not every MCU family has a native I3C peripheral yet; some designs implement I3C controller functionality by driving a high-speed I2C-capable peripheral in a compatible mode, which is more firmware effort than using dedicated I3C hardware. Zeus Design's embedded firmware team evaluates protocol and part selection — including I3C adoption tradeoffs — as part of new product hardware and firmware design.

Common Mistakes

• Assuming an "I3C-compatible" sensor works identically to its I2C mode with no other changes. Dynamic addressing, IBI, and CCC handling all need controller-side support in firmware; simply wiring the device to an I2C bus and addressing it at a fixed address ignores the features that justify choosing I3C in the first place.
• Mixing I3C and legacy I2C devices without checking spike-filter and timing compatibility. Some older I2C parts have fixed timing characteristics that don't tolerate the faster signalling I3C introduces between transactions; verify mixed-bus compatibility against the I3C Basic Specification's I2C-compatibility requirements rather than assuming any I2C device works unmodified on a mixed bus.
• Expecting the full 12.5 MHz SDR rate regardless of bus loading. Like I2C, I3C's achievable speed on a real board is still a function of bus capacitance, trace length, and device count — the push-pull data phase raises the ceiling substantially but doesn't eliminate physical bus loading as a constraint.
• Treating Hot-Join as eliminating the need for careful power-up sequencing. Hot-Join handles a device joining an already-initialised bus, but a device that's mid-boot or in an undefined electrical state when the controller first initialises the bus can still cause the same kind of bus contention issues I2C designs already have to guard against.