Remember old hard drives with their giant ribbon cables? They went serial and now the power cables are way thicker than the data cables. We’ve seen the same thing in embedded devices. Talking between chips these days tends to use I2C or SPI or some variation of these to send and receive data over a handful of pins. But now there is I3C, a relatively new industry standard that is getting a bit of traction.
I2C and SPI are mature but they do have problems. I2C can be relatively slow and SPI usually requires extra pins for each device. Besides that, there is poor support for adding and removing devices dynamically or discovering devices automatically.
I3C, created by the MIPI Alliance, aims to fix these problems. It does use the usual two wires, SCL for the clock and SDA for data. One device acts as a controller. Other devices can be targets or secondary controllers. It is also backward compatible with I2C target devices. Depending on how you implement it, speeds can be quite fast with a raw speed of 12.5 Mbps and using line coding techniques can go to around 33 Mbps.
Not I2C
The bus looks like a typical I2C bus, but addressing is dynamic, except for legacy I2C devices which still use their normal address. In other words, the controller assigns addresses to devices that it finds on the bus. Legacy devices can’t use extended addressing. You can also connect devices without stopping the bus. There is the capability for broadcast messages, multiple operations, and in-band interrupts. It also has specific features for designs that need low-power operation. In addition to specifying the physical connection between devices, there is also a specification for the host controller interface. That means software has a standard interface to talk to the controller and the bus.
There are a variety of ways to increase data throughput, although some require that no legacy I2C devices sit on the bus. For example, when talking to a target device, it is possible to agree to use a double data rate scheme where data appears on both edges of the clock. There is also a way to conscript both lines to use a base 3 encoding in a self-clocking scheme. The idea is that two bits can encode any of four states. From each state, there are three possible next values. So each transition provides a base 3 digit packing more data into the same amount of time compared to a traditional scheme.
Unfortunately, the full specification is available only to MIPI members. However, you can download the basic specification. This, unfortunately, documents a subset of all the available features. For example, only single and double data rate appear in the public spec. However, hosts and devices will negotiate, so it is possible to have a device that, for example, only speaks SDR coexist with other devices that want to do something more exotic.
Nothing Simple
If you want to try implementing any of this, it is significantly more work than bit banging an SPI interface. For example, check out the transaction for dynamically allocating addresses on the bus, which also works around having static allocations, including those for I2C devices.
The ability to join devices while the bus is in operation is another complex issue. If you just want to keep part of a board powered down, it probably is pretty easy. But if you want to literally plug something in, you’ll need to figure out how to do that without disrupting the bus in action electrically.
Although the public spec isn’t everything, it still weighs in at nearly 450 pages! There’s a lot to digest. It is unclear, too, how much motivation there is to implement this yourself in software. There’s a bit of a dragon and egg problem here: Most processors don’t support I3C out of the box because there aren’t many devices that use it. But until there are more processors that support it, why build devices?
In Practice
That may not be the case in the future. But for most of us, the question is what devices use this protocol today? The Linux kernel has an I3C driver available, and there are a few devices out there. NXP, for example, lists a few products with I3C, with a few temperature sensors “coming soon.” They also offer several ARM CPUs with I3C peripherals, such as the LPC553x. Microchip has the PIC18-Q20 which can act as a target, but not a controller. In addition, Renesas, ST, TI, and a handful of other vendors offer a few I3C target devices ranging from 6-axis IMU chips to temperature sensors. If you have a Saleae logic analyzer, there is firmware you can get for it that will help you read I3C.
Will it catch on? Maybe. As cheap embedded CPUs get more powerful, there’s less reason to stick with simple protocols. However, there’s something gratifying about knowing you could bit bang your UART or SPI bus in a few hours of fun coding if you had to. With I3C, you are probably going to rely on an embedded peripheral to do all the heavy lifting. Then again, if they become common, why not?
> Unfortunately, the full specification is available only to MIPI members.
That’s gross. Hopefully they release the full spec after a while, but the fact that they’ve released a stripped-down one doesn’t make me hopeful. While I’m sure it won’t be too difficult to reverse-engineer, there’s really no reason for a closed spec.
The public spec contains 444 pages of stuff, minus 10 for “This page intentionally left blank.”
That is indeed gross/gros/gras!
Yes, especially when the pages should have
“This page intentionally left unblank”.
Always irritating
“I really want people to use my chips and adopt my standards, but nope, I won’t freely publish it”
It seems a subset of the specification is available upon registering:
https://www.mipi.org/mipi-i3c-basic-download
Could this be implemented on RP2040 using PIO?
Turning support Into a matter of software* seems like a potential solution to the “dragon and egg” problem.
*Obligigatory xkcd: https://xkcd.com/644/
Entry-level FPGAs (mostly ICE40s) are also finding their way into more and more products, both due to their accessibility and the recent abundance of easy-to-implement RISC-V based soft-cores and soft-SOCs. I foresee neorv32 getting a I3C implementation right quick.
next obligatory xkcd: https://xkcd.com/927/
Well that’s because they just didn’t make the 15th standard BIG enough!
(There are 16 standards, the 16th is an XSD file which can encode the other 15 plus itself)
I wonder if the reason for a clsed specification is because this is, at least based upon, a trickle down technology. If some of it is still being implemented in convert or classified items it may be what’s prompting their hesitation to fully disclosure the details. Then again, maybe they just haven’t worked out all the bugs yet of they’d rather keep a monopoly on the hardware, until such time as a stable market becomes available to them, so they can make more money, with less risk of a flop.
If the spec is proprietary then they can extract a promise that the spec will be properly implemented with no shortcuts and no omissions. If they give the spec away for free then they can’t ensure that companies will create full implementations. Since the tech is new, some folks might find parts of the spec to be “unnecessary” when in fact it all needs to be there
They could just trademark “I3C” and enforce compliance that way, ie. any non-compliant implementations will get a letter saying they must remove all mentions of I3C until they are in compliance.
They close their spec but don’t particularly care if hobbyists get their hands on it. It’s done so that they can secure written agreements on trademark and conformance from companies looking to sell implementations of the spec. It’s way easier to enforce a simple contract than it is to chase down trademarks.
Maybe it’s closed because it’s but finished yet and they don’t really everybody just running with I2.7aC?
OMG
The base-3 system reminds me what I was musing with a decade ago…
Except that the self-clocking used 2 lanes, so it could be full-duplex…
I gotta make a project now to document it !
Done…
https://hackaday.io/project/187000-spi4c
So how do we pronounce this ?
eye-cubed-see ?
I three C. Just like I two C.
My brain always screams “I square C” at me. I’ll probably end up calling this “I cube C”. It’s a good thing all the interaction I do about embedded is via text, otherwise the plethora of things I mispronounce would be a distraction far too often.
Thought exact same thing. Ha
Oh I C…. But I 4 C this will be replaced very soon.
Thank you William Steig!
B^)
Oh no! That’s OK, but what happens when we get to I4C?
Nobody will know until it happens, but everyone will claim to…
I-tesseracted-C.
I hypercubed C
I 4 C a problem here. 😉 all puns intended
eye-three-see?
India-Tree-Charlie?
What is the other I for, anyway?
Inter-Inter-Integrated Circuit?
Inter-Integral-Integrated Circuit?
Integral-Inter-Integrated Circuit?
Illuminati-Inter-Integrated Circuit?
Idiotic-Inter-Integrated Circuit?
inaccessible-inter-integrated-circuit protocol of course
I really like the idea of automatic addressing however it will only really work if you can identify which kind of device it is. This could be done pretty easily by making the first few registers of the device contain an identification code, that the master reads and knows what device is on address 1 for example. This would be very useful for having multiple of the same device on the same bus. You could theoretically have the maximum address size of peripherals on the bus, even if they were all the same. I see that as a major advantage as a lot of I2C sensors, etc, either can’t change the address or only change it between a few or you need to move resistors or solder bridges to change the address, this would make it much easier.
I can also see it being a problem though, if you have multiple of the same sensor, measuring different places or different things then since the master automatically assigns the addresses, how will it know which sensor is which or in which location? Since they may change address. I suppose this could be fixed by having both a device identifier and a serial number or other unique identifier. That way you use the device identifier to tell what it is and you use the unique identifier to tell which one it is.
Overall I think I3C is a pretty good idea as long as they avoid or find a solution for the potential pitfalls which could be solved pretty easily.
Intelligent I2C?
Maybe it is supposed to be sung to the tune of Cielito Lindo.
I-I-I-Cielito Lindo!
https://www.youtube.com/watch?v=ezVpSH8PzZE
It is stretching the word “firmware” to refer to a python plugin for the software interface for the Saleae logic analyzer. https://binho.io/pages/i3c-basic-protocol-analyzer. I’d prefer to reserve the word firmware for software that runs on hardware. A PC is rarely considered hardware in this context.
I stopped reading after “Unfortunately, the full specification is available only to MIPI members”
If you can’t even look at how it works without jumping though idiotic hoops I have no interest in it.
Apart from that, it’s just one of the many buses available. If there are both a lot of different microcontrollers and IC’s that interface via this bus available I may have a second look at this, but I’m guessing that would take years.
MIPI plays the long game…
TBF, MIPI doesn’t really care about hobbyists. That’d be like NASA publishing everything they come up with and making it available to hobbyists. I3C is being promoted for applications from high-performance embedded systems to PCs to servers, and the people building those are already MIPI members or are people MIPI wants to lure in because there’s already dealing with other closed specs controlled by MIPI and similar groups.
Basically, unless your latest product has a 5GHz+ CPU and DDR5 then I3C really isn’t for you.
I3C will be useful to hobbyists once enough manufacturers support it for those bigger clients and the price drops enough to be accessible to hobbyists. Even then, most MCUs and I2C devices don’t fully implement the I2C spec, so why worry about implementing the whole I3C spec? When was the last time you used I2C clock stretching?
When was the last time you used I2C clock stretching?
> Last week.
“That’d be like NASA publishing everything they come up with and making it available to hobbyists”
Well actually…
https://www.earthdata.nasa.gov/engage/open-data-services-and-software/data-and-information-policy#:~:text=NASA%20promotes%20the%20full%20and,academia%2C%20and%20the%20general%20public.
Smells like HSIC.
Haven’t we seen already enough broken I2C hardware and software?
Forgotten clock stretching, single-master-only implementation, hardware-glitches in micro-controllers, …
Shall we really expect an even more complicated successor to make our lives better?
I heavily doubt that!
My guess is that’s why they’re keeping the protocol secret; can’t implement it if you can’t read it, can’t read it unless you sign a document that you will pass some kind of certification test.
I too have experienced buggy I2C hardware/bit-bang-firmware crashing a I2C bus and the protocol has no required timers so the bus is dead usually until next power cycle. Not even limited to buggy implementation, enough noise on the bus and it’ll eventually lock up. Thus the popularity of interfaces like SPI for “important” tasks, or put the I2C devices power under the control of some GPIO ports (which also can be an opportunity to save significant power… sometimes)
Your average name brand I2C “thing” works well enough most of the time that its not an issue. But if you have something that’ll never shut off, like a house thermostat, you kind of have to use SPI or have GPIO control of the device power leads, if you want it to work “forever”.
I3C will be implemented as core units in microcontrollers and devices, that will be required to be certified by the standards body, and they will work and interoperate just as well as Ethernet or USB.
I’ve used SPI and I²C for decades, usually bit-banged, where I wrote the bit-bang software myself, and never had any trouble at all with them. It always worked on first try. Some SPI devices are capable of nearly 200MHz clock speeds not (and my information might be outdated), and if the hot-plugging were a problem, they could just implement a connector that would take care of it.
However, it says above, “Although the public spec isn’t everything, it still weighs in at nearly 450 pages!” That’s one of the many things I hate about USB. The USB 2.0 spec. is 650 pages, and it’s definitely not hobbyist-friendly. How can I get excited about I3C? Hopefully it won’t really catch on.
One of the reasons SPI and I2C became popular was because they were simple enough to implement in software of reasonably simple complexity. I implemented I2C (simplified: single master, no clock stretching) by bitbanging on a micro in the mid 90’s. This protocol is way too complex on both the physical and software (protocol) level to enjoy the benefits that drove popularity for I2C and SPI. I don’t see this protocol following in their footsteps.
Gigabit Ethernet, USB 3, SATA, HDMI are all very successful and you’re not going to bit-bang any of them with a microcontroller.
…because no one with a microcontroller uses those standards? I’m not sure why you pick those protocols? Was any of them a extension of an existing protocol used on microcontrollers? USB3 might be the closest, but no one bitbangs even full speeed USB1.0, so not sure why you would talk about 3.0. It sounds like you’re trying to make a philosophical point well divorced from reality.
full speed usb was recently done on RP2040 -both device and host
https://github.com/sekigon-gonnoc/Pico-PIO-USB
and BTW the HDMI/DVI too https://github.com/Wren6991/PicoDVI
People are already bit banging HDMI on the pi pico…
I know about bit-banged transfers of meta-data on HDMI ports (the channel where a display tells model and capability).
But bitbanging of actual video data displayable by an actual display?
Well, it’s actually DVI.
https://hackaday.com/2021/02/12/bitbanged-dvi-on-a-raspberry-pi-rp2040-microcontroller/
I’ve found this Embedded Linux Conference presentation on I3C to be very informative:
“I3C in Tomorrow’s Design – Miquèl Raynal, Bootlin” – https://www.youtube.com/watch?v=lMncnFsTJhA
Personally, I think they way they’ve achieved interoperability with I2C and higher speeds is very clever and I’m looking forward to seeing more I3C devices become available.
Closed spec in this day and age, no thanks.
I guess that means no HDMI, USB, Ethernet, Wifi, Bluetooth…
Of those seven, only HDMI is truly closed. (And even then you can find leaked PDFs online.) Ethernet and WiFi specs are available for free with registration via IEEE GET, while USB and Bluetooth don’t even require that.
Patents are another issue entirely…
There’s a difference between using it as a black-box consumer item and OTOH designing projects with it. I don’t use WiFi (my internet connection is wired) or bluetooth anyway, and I hate USB with a passion but I’m forced to use it for my scanner, and on rare occasions, other things. I don’t even use a cell phone. This may be hard for young people to believe, but there really was life before cell phones, and in some ways, it was better. I won’t own a modern car either. I’m constantly straining to make software more efficient, powerful, maintainable, etc., and to demonstrate what can be done with simpler hardware.
yay! an excuse to bloat a simple protocol.
though to be fair its nice to be able to get more throughput.
more throughput than I²C, yes; but at least a few years ago SPI devices were closing in on 200Mbps. If my information is outdated, they might be well above that now.
Fuck MIPI five ways. They are evil in ways you cannot imagine. Secret specs. Thousands of dollars to learn how things work. Thousands of pages of NDAs. Just no.
Too complex, I stick with uart!
Simple is good. SPI and I²C are even simpler than UARTs, because the strict timing requirements are gone. But even with UARTs, RS-422 and -485 can go both much farther and much faster than RS-232. RS-422 can do 10Mbps at 40 feet, and RS-485 can do 35Mbps at 33 feet. Both can go at least 90kbps at 3/4 mile. USB can’t do that. The only difference from RS-232 is the line drivers and receivers, and the cabling and connectors. You can use the same UART, and see basically the same things on an oscilloscope if you use one for troubleshooting.
I looked into this 1-2 years ago, and at the time I thought “if the community got together they could co-opt the basic spec, and enhance the basic spec” but there was one major issue, that three letter combination “I3C” is copyright.
So I thought about joining the MIPI Alliance, because there is some higher tier stuff available (inetmediate spec) before you get to the level of proprietary “bits”, along with access to the I3C device database, but that was cost prohibitive for an individual
They should never have been allowed to copyright I3C, how is I2C ever meant to evolve otherwise..
Looks like they’ve gone woke. They changed the terms from master/slave to controller/target. Controller I understand, but target is so vague. Why change terminology, when you want to be backwards compatible? Now instead of two terms we have four; if an I3C controller wants to address an I2C slave as a target the controller will act as I2C master. Nothing is replaced, nothing is improved. Meanwhile chips are made in countries with actual slave labor.
best comment!
Quite a number of standards have removed the words master and slave, and quite a number of large comoanies have had projects to update their source code correspondingly.
Drupal changed master/slave to primary/replica 2014. Same year as Django selected leader/follower.
Many companies have also dropped whitelists/blacklists as terms and changed to allow/deny lists.
Realtors are even stopping to use master bedroom as term.
Check for master/slave on Wikipedia and you will find a page with lots of alternate terms.
“If we ignore it hard enough, it will go away”
With something this complex we’re probably going to see either libraries or blobs for driving I3C IP blocks.
Automatic address assignment sounds great at first, but my immediate thought was “oh crap how do you assure each device gets the same address each time the system boots?!”
Does each device report a UID of some sort? Does the controller device then need flash space for the lookup table? Does your code have to handle these issues?