I3C Bus Explained: A Modern Sensor Bus (and the Successor to I2C)

If you have ever designed a board with "just one more sensor" and hit a wall with address conflicts, interrupt pin count, or I2C rise-time limits, I3C is the bus that tries to fix those pain points while staying familiar. I3C (typically written I3C) is a 2-wire, multi-drop serial bus standardized by the MIPI Alliance, and it is widely positioned as the modern successor to I2C for sensors and small peripherals.

This guide is a practical, engineering-first introduction: what I3C is, what it changes electrically, how it discovers devices with Dynamic Address Assignment (DAA), what Common Command Codes (CCC) do, and how features like In-Band Interrupts (IBI) reduce wiring complexity.

I3C vs I2C: What Actually Changes

I3C looks like I2C on the schematic (SCL + SDA), but it modernizes both the electrical behavior and the protocol. Here is the high-level comparison that matters in practice:

If you want a deep refresher on the classic bus (START/STOP, ACK/NACK, pull-ups, timing), see the I2C Communication Guide.

Wiring & Electrical Layer: Why I3C Is Faster (and Lower Power)

I2C is fundamentally open-drain: devices only pull the line low, and pull-up resistors bring it high. That is simple and safe, but it also makes edges slow as bus capacitance grows. I3C keeps open-drain behavior where it needs to (especially for compatibility), then switches to push-pull signaling for most I3C traffic.

• Pull-ups still matter: even on an "all-I3C" bus, pull-ups are used for the open-drain portions (startup, bus arbitration phases, and any legacy I2C transfers). The good news is that they can often be weaker than what you would choose for a fast I2C bus.
• Push-pull changes everything: when the bus is driven actively high and low, you are less dependent on RC rise time. This is why I3C can reach higher data rates and reduce static pull-up current.
• Be careful with level shifters: many "I2C level shifters" rely on open-drain behavior and will break (or degrade) push-pull signaling. Mixed-voltage I3C typically requires an I3C-capable translator or a system-level architecture that avoids translating the bus.
• No clock stretching (in the classic I2C sense): many I2C designs rely on targets holding SCL low. I3C communication is built around higher-rate, more structured transfers and generally does not use the same clock-stretching model; check your controller/target documentation if your firmware assumes stretching.

I3C Terminology (Controller, Target, and Friends)

You will see slightly different naming than legacy I2C documentation:

• Controller: the device that initiates transfers and manages the bus (roughly "I2C master").
• Target: a device that responds to transfers (roughly "I2C slave").
• Multi-controller: some I3C systems allow more than one controller, with standardized mechanisms for more advanced arbitration/hand-off. Many embedded systems stick to a single controller.

I3C vs "I3C Basic"

In the wild, you will encounter three compatibility buckets:

• I2C-only: legacy devices that never speak I3C.
• I3C Basic: a widely implemented subset meant to make adoption easier while retaining the key ideas (dynamic addressing, CCC, event support depending on device).
• Full I3C: devices/controllers that implement a broader set of optional features and modes.

For engineering decisions, the important part is not the label, but the feature checklist: DAA support, CCC coverage, IBI capability, and which speed modes are actually implemented.

Dynamic Addressing (DAA): How I3C Avoids Address Conflicts

On I2C, devices typically ship with a fixed 7-bit address (sometimes with 1-2 strap pins). If you need two identical sensors with the same address, you end up adding an I2C multiplexer or extra GPIOs. I3C solves this with Dynamic Address Assignment (DAA):

1. Targets identify themselves (using a unique identity / ID) during a standardized discovery phase.
2. The controller assigns a dynamic address to each target.
3. Normal communication uses the dynamic address, making "two identical parts" much easier to handle.

Common Command Codes (CCC): Standardized Control & Discovery

One of the most "bus-level" differences is that I3C defines a set of standardized commands called Common Command Codes. CCCs let a controller discover devices, configure bus behavior, and enable/disable events in a uniform way.

Even if your application "just reads registers", CCCs matter because they define how the bus boots and how it stays manageable as you add more devices.

Events: In-Band Interrupt (IBI), Hot-Join, and More

A classic I2C pattern is "poll every sensor" or "wire a dedicated interrupt pin per sensor". I3C introduces bus-native event mechanisms so that targets can request service without extra GPIOs.

• In-Band Interrupt (IBI): a target requests attention on the bus; the controller can then service the device and optionally read a small payload. This is a big deal when you have many sensors and few GPIOs.
• Hot-Join: a newly connected target can request to be discovered and addressed without a full system reset (useful in modular designs).
• Multi-controller concepts: I3C supports multi-controller topologies (more advanced designs), but most embedded systems use a single controller in practice.

Speed & Bandwidth: What to Expect

You will see "I3C is much faster than I2C" everywhere. The useful engineering framing is:

• SDR (single data rate) transfers use push-pull signaling and run at a much higher clock than classic I2C modes (often up to around 12.5 MHz on capable systems).
• Byte transfers are not "8 clocks per byte": in SDR, data is commonly followed by an extra T-bit (similar in spirit to an ACK/NACK bit, but I3C-specific). A useful rule of thumb is "about 9 bits on the wire per 8-bit byte", before you even count command/address overhead.
• Optional HDR modes exist for higher throughput, but the real-world number depends on which HDR mode is supported by both the controller and the target, and on your traffic pattern (many short register reads vs. longer bursts).
• Effective throughput is workload-dependent: bus arbitration, command overhead, and "many small register reads" can dominate. I3C helps, but it does not magically turn a shared 2-wire bus into a point-to-point high-speed link.

Hardware Design Checklist (What Engineers Actually Get Wrong)

• Assuming any I2C level shifter works: a common failure mode is putting a MOSFET-based bidirectional I2C level shifter on an I3C bus, then wondering why the bus is unstable at higher rates.
• Underestimating the pull-up network: even if most transfers are push-pull, you still need pull-ups for open-drain phases and for any legacy I2C devices on the bus (the I2C Pull-Up Planner is still a useful sanity-check tool).
• Ignoring bus topology: stubs and long branches increase capacitance and reflections. Keep the bus short and "linear" when you care about speed.
• Mixing legacy I2C devices without a plan: mixed-bus operation is supported, but it can restrict which I3C features you can use and may change electrical/timing assumptions.
• No recovery strategy: define how your firmware handles a stuck bus, a misbehaving device, or a hot-join event. Treat enumeration and error recovery as first-class logic, not an afterthought.

Migration Strategy: From I2C to I3C

If you are already shipping products on I2C, I3C adoption usually happens incrementally:

• Start with the controller: verify your MCU/SoC actually has an I3C controller (not just "fast I2C").
• Pick one I3C-capable target: add a single I3C sensor on an otherwise familiar bus and validate enumeration (DAA), drivers, and bus monitoring.
• Keep legacy devices where it makes sense: EEPROMs and simple peripherals are often still fine on I2C. Use I3C where its features remove real system cost.
• Refactor interrupt wiring: if you adopt IBI, you can often delete multiple GPIOs, simplify routing, and reduce connector pin count.

FAQ (Engineers Ask These First)

Can I put I2C and I3C devices on the same bus?

Yes, that is a core I3C design goal. In practice, your controller must manage compatibility constraints (timing, signaling, and which features are safe to use) when legacy I2C devices are present.

Do I still need pull-up resistors?

Yes. Even on an I3C-only bus, pull-ups are used for open-drain phases. If you have legacy I2C devices, pull-ups are mandatory. The difference is that push-pull I3C traffic is less dependent on pull-up strength for edge speed, which can reduce static current compared to an aggressive "fast I2C" pull-up design.

Can I debug I3C with an I2C logic analyzer?

Sometimes you can see the electrical activity, but decoding is usually incomplete: I3C uses additional protocol features and signaling behavior that basic I2C decoders do not understand. For serious debugging, use an analyzer or software stack that explicitly supports I3C.

References & Further Reading

• MIPI Alliance: I3C and I3C Basic specifications and overview material.
• MCU/SoC reference manuals: look for the "I3C controller" peripheral chapter, especially enumeration (DAA), CCC support, and IBI handling.
• Sensor datasheets: confirm whether a device supports I3C, I3C Basic, or I2C-only operation, and what features (IBI, dynamic addressing) are actually implemented.