Why I3C Exists: The Evolution Beyond I²C
Embedded Systems Fundamentals #4
If you've worked with embedded systems for any length of time, you've almost certainly used I²C.
It connects:
Temperature sensors
Accelerometers
Gyroscopes
EEPROMs
PMICs
Touch controllers
Camera sensors
Real-Time Clocks
For decades, it has been the de facto low-speed communication bus.
So why did the industry create an entirely new protocol? Was I²C broken?
Not at all.
In fact, I²C remains one of the most successful communication protocols ever designed. The problem wasn't I²C. The problem was that embedded systems evolved.
This article explores why I3C was created, what problems it solves, how it works internally, and what changes firmware and driver developers need to understand when migrating from I²C.
The Evolution of Embedded Systems
Twenty years ago, a typical microcontroller board looked something like this:
MCU
|
+-- EEPROM
|
+-- RTC
|
+-- Temperature Sensor
Only a handful of peripherals shared the bus. Bandwidth requirements were modest. Power consumption was manageable.
Today, the picture looks very different.
Application Processor
|
+-- IMU
+-- Magnetometer
+-- Barometer
+-- Camera Sensor
+-- PMIC
+-- Battery Monitor
+-- Touch Controller
+-- Ambient Light Sensor
+-- AI Sensor
+-- Audio Codec
The number of devices has increased dramatically. Many of them continuously stream data. The communication bus has become a performance bottleneck.
The Limitations of I²C
I²C is elegant, but it carries several architectural limitations.
Static Addresses
Every device has a predefined address.
This creates problems when:
Two identical sensors are used.
Address pins are limited.
Large sensor networks are built.
The driver often has to work around these hardware constraints.
Pull-Up Resistors
I²C relies on open-drain signaling.
This means:
Slower signal rise times
Higher power consumption
Careful resistor selection
Increased sensitivity to bus capacitance
As bus speed increases, these physical limitations become more significant.
Separate Interrupt Pins
Many peripherals require an additional GPIO interrupt line.
Example:
I²C
+
Interrupt GPIO
This increases routing complexity and consumes valuable pins.
Clock Stretching
Clock stretching allows slower peripherals to delay communication.
While useful, it also introduces:
Timing unpredictability
Driver complexity
Timeout handling
Bus recovery logic
Many modern high-performance systems disable clock stretching entirely.
Limited Bandwidth
Common I²C modes include:
Standard Mode – 100 kHz
Fast Mode – 400 kHz
Fast Mode Plus – 1 MHz
High-Speed Mode – 3.4 MHz
For modern imaging, AI, and sensor-rich systems, this is often insufficient.
Enter I3C
The MIPI Alliance designed I3C to modernize the low-speed peripheral bus without forcing the industry to abandon existing I²C devices.
The design goals were ambitious:
Higher bandwidth
Lower power
Dynamic addressing
Simplified board routing
Better interrupt handling
Backward compatibility
Rather than replacing I²C overnight, I3C allows both protocols to coexist.
Backward Compatibility
One of I3C's greatest strengths is that an I3C controller can communicate with traditional I²C targets.
Example:
I3C Controller
|
+-- I3C Temperature Sensor
|
+-- I²C EEPROM
|
+-- I²C RTC
This allows gradual migration rather than complete redesign.
Push-Pull Signaling
Unlike I²C, I3C does not spend most of its time operating in open-drain mode. After initial arbitration, communication transitions to push-pull signaling.
Advantages:
Faster rise times
Higher speed
Lower power consumption
Improved signal integrity
Open-drain is retained only where it provides functional value.
Dynamic Address Assignment (DAA)
Perhaps the biggest architectural improvement. Instead of assigning addresses through hardware pins, the controller assigns addresses during initialization.
Benefits:
No address conflicts
Multiple identical sensors
Simplified PCB design
Easier manufacturing
This is especially valuable in modular products.
In-Band Interrupts (IBI)
Traditional I²C devices require:
I²C Bus
+
Interrupt GPIO
I3C eliminates this. Devices can request controller attention directly over the communication bus.
Benefits:
Fewer GPIOs
Reduced PCB routing
Simpler driver architecture
Lower pin count
For compact embedded products, this is a significant advantage.
Common Command Codes (CCC)
I3C introduces standardized commands.
These allow the controller to:
Discover devices
Assign addresses
Configure features
Broadcast commands
Manage bus behavior
Unlike vendor-specific approaches, CCCs provide a common management interface across compliant devices.
HDR Modes
High Data Rate (HDR) modes further increase throughput.
Examples include:
HDR-DDR
HDR-TSP
HDR-TSL
These modes trade protocol complexity for substantially higher bandwidth.
Applications include:
Imaging
AI sensors
High-rate telemetry
Controller Architecture
An I3C controller is considerably more sophisticated than a traditional I²C controller.
Typical blocks include:
Application
↓
HAL
↓
I3C Driver
↓
Command Queue
↓
Dynamic Address Manager
↓
CCC Engine
↓
Transfer Engine
↓
Interrupt Logic
↓
DMA
↓
I3C Bus
The controller becomes an active bus manager rather than simply shifting bits.
Driver Architecture
A robust I3C driver typically consists of:
Bus manager
Dynamic address manager
Transfer engine
CCC handler
Event manager
IBI handler
DMA interface
Error recovery module
Compared to I²C, the software architecture becomes significantly more state-driven.
Error Handling
Firmware must handle scenarios such as:
Dynamic address assignment failures
IBI conflicts
HDR negotiation failures
Legacy I²C compatibility issues
Bus initialization failures
Controller handover
Good driver design becomes increasingly important.
DMA and Interrupts
Like modern SPI controllers, I3C controllers typically support:
Interrupt-driven transfers
DMA transfers
Transfer queues
Hardware scheduling
This reduces CPU overhead while supporting high-bandwidth peripherals.
Real-World Applications
I3C is increasingly appearing in:
Smartphone sensor hubs
AI vision systems
Industrial automation
Wearables
Automotive electronics
Camera subsystems
Edge AI devices
Robotics
Many next-generation sensors now provide I3C support alongside I²C compatibility.
Migration Challenges
Migrating from I²C to I3C isn't simply a driver update.
Engineers must consider:
Mixed buses
Legacy devices
Power sequencing
Dynamic discovery
CCC implementation
Firmware architecture
Validation strategy
The migration is as much about software design as it is about hardware capability.
Looking Ahead
I3C isn't replacing SPI. It isn't replacing UART. And it isn't making I²C obsolete overnight. Each protocol serves a different purpose.
But for sensor-rich, power-sensitive, and bandwidth-demanding systems, I3C represents the natural evolution of I²C.
Understanding I3C today prepares firmware engineers for the next generation of embedded platforms, where intelligent sensors, AI accelerators, and high-performance peripherals increasingly expect more than traditional communication buses can provide.
Key Takeaways
I3C was created to solve the scaling limitations of I²C.
It retains backward compatibility with existing I²C devices.
Dynamic Address Assignment simplifies hardware design.
Push-pull signaling improves speed and power efficiency.
In-Band Interrupts reduce the need for dedicated GPIOs.
Common Command Codes standardize device management.
Driver architecture is more sophisticated than traditional I²C implementations.
I3C is becoming increasingly common in modern embedded and Edge AI platforms.
What's Next?
Part 5:
Interrupts in Embedded Systems: From Hardware Events to Firmware Execution
We'll move beyond communication protocols and explore one of the most fundamental concepts in embedded software:
What is an interrupt?
How does the CPU respond?
NVIC and interrupt prioritization
Latency and jitter
ISR design guidelines
Nested interrupts
Deferred interrupt processing
Common pitfalls and debugging techniques
Understanding interrupts is the foundation for writing responsive, efficient, and reliable firmware.
