I3C Communication


If you have a controller that talks to many devices along a bus, chances are you are familiar with I2C. (If not, don’t worry – you can check out our article on it HERE!) As industrial and consumer technology advances, the modules that rely on previous protocols risk becoming obsolete, forcing designers to either adopt the new but many times limited hardware or keep the reliable but old and limited protocol. Standing for Improved Inter Integrated Circuit, I3C aims to solve that issue.

What is it?

Before we get into the specifics of how I3C is an upgrade to I2C and what it offers, it needs to be known that there is no new breakthrough that I3C will be bringing to the world in a never-before-seen way. That is, the Ethernet protocol has existed for some time to fulling the role of the high-speed signaling over long distances. The CAN bus still remains a great option for reliability in robust systems that could be subject to high levels of noise. I3C aims not to replace all protocol by doing everything all at once, rather it instead offers to fill the role of I2C with more ease, reliability, and scalability.

Where is it used?

I3C is strongest in markets that already utilize the I2C, so we would see it more in the mobile phone and wearables market. Additionally, because of the simplicity and backwards compatibility, the presence is growing in the Internet of Things (IoT) segment. In these applications, however, one might wonder why upgrade from I2C if it does the job just fine. One cannot claim to be improved just in self-declaration alone, though, so let’s take a look at a few of the qualities that makes I3C better than it’s predecessor.


As stated before, I3C is backwards compatible and therefor it can be assumed that most advantages - save for price - that exists for I2C also exist for I3C. What I3C has that I2C does not is dynamic addressing. For I2C, the address of a target (or peripheral) is considered static and must be set manually. I3C uses dynamic addressing which in turn allows the controller to assign an address to the target device automatically. Although saving a step in the process is appealing, the true benefit lies in the implication of dynamic addressing – hot joining.

I3C has the capability of hot joining in which devices are able to join the bus dynamically while the system is still running. As part of this, the controllers are also able to perform what is traditionally known as Mastership Handover – allowing other controllers to take ownership of some of the peripherals and/or duties. This opens the doors for complexity and flexibility not available with the I2C itself.

One of the reasons that people prefer to use I2C over SPI is the reduced number of wires required to operate the protocol. I3C takes that one step further and allows everything to be communicated along the same two wires. With in-band interrupt, there no longer needs to be separate wires for each device to have it’s own interrupt line. Not only will this allow the system to save space (which is typically of high value in wearables and IoT applications), but it also plays a role in another benefit of I3C – efficiency in power consumption.

Finally, and although there are additional benefits to I3C beyond this, it is worth mentioning the increase in speed over I2C. Interestingly, the difference in speed what allows the controller to detect an I3C peripheral vs an I2C peripheral, allowing the backwards compatibility as it interfaces with the devices separately. I2C running in the High-Speed mode would allow for up to 3.4Mbps of communication, whereas the I3C protocol can reach up to 12.5 Mbps.


The question must be posed, then – if I3C does most of what I2C does but better is there even a reason to continue I2C? Absolutely. With I2C devices being so available and standard, and I3C still being fairly new, I2C can be expected to stick around for quite some time. Apart from the availability (and usually in turn cost), switching to I3C for many applications will be overkill. If an application does not need to consider power constraints, has available room, and will not benefit from the higher data rate, then there would be no need to consider using I3C over I2C. If scalability and future implementation is a concern, however, then I3C may still be a great contender.