I3C is coming

[SiliconWizard]

Up to 12.5MHz, still 2 wires and backward compatible with I2C.

https://www.mipi.org/specifications/i3c-sensor-specification

Vendors are starting to deploy it:
https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/i3c-interface-devices:I3C
https://www.microchip.com/en-us/product/PIC18F16Q20

[ataradov]

I don't see that having a huge success. Just like there are not a lot of I2C HS devices out there.

If MIPI forces this into their stuff, it would be one place where it is used. Otherwise, if you really need speed, SPI works. Shared bus in that case does not help. And layout requirements become to strict for that to be an easy to use interface.

[ataradov]

It is also backwards compatible with I2C devices that implement proper glitch filtering. And there are a lot of devices that either don't implement it, or it is not fully compliant to the spec for various implementation reasons. Things are still likely to work, but you would have to test coexistence really well.

[woofy]

If I3C was there on a device I needed to use and an easy controller available in my chosen MPU, then I would probable use it, but I really don't see the point of it. I3C seems to have no advantages of importance over what we have now. I2C, SPI and UART's cover all the low speed comms I need. Its just another protocol for the sake of it. Unless I absolutely must use it because of a needed functionality not available elsewhere, I wouldn't bother.

[Siwastaja]

What bullshit. I2C is already complicated by earlier "speed improvements" no one wants and no one uses, and again no one has asked for yet another "improvement".

[janoc]

This is old news. I3C has been around since 2016 - and didn't exactly take off like a wildfire in that time.

[ejeffrey]

If I3C was there on a device I needed to use and an easy controller available in my chosen MPU, then I would probable use it, but I really don't see the point of it. I3C seems to have no advantages of importance over what we have now.

The only real point I can see is basically the MIPI situation.  If you have a standardized interface that specifies an i2C auxillary channel that you wish was faster.  I3C would seem to get you a migration path that was backwards compatible with existing devices.  If you aren't in that situation just use SPI.

[Scrts]

This will be very helpful in automotive, especially radars and cameras.

[SiliconWizard]

The first revision may date back to 2016, but MCUs and peripherals are starting to appear from major vendors (STM, NXP, Microchip...), some of them having made recent announcements (hence the topic, it's not just "old news") and after reading the specs I find it a nice addition. I'll certainly use it if it's available for the parts I need. The STM32H5 series, which was released a few months ago, embed I3C peripherals.

Yes it's from MIPI, so what? I2C was from Philips and people were probably whining as well for years until it became mainstream. SPI is no direct substitute for a two-wire, multi-device bus.

The ideas behind it are quite simple in fact, but unfortunately, it always has to be "owned" by some organization to see standardization and widespread use. The value of these "standards" is all in that, the fact they are standards. It's not particularly the technical aspects, which are not revolutionary by any means.

Contrary to SPI, the idea that synchronous communication between devices is rarely required to be full-duplex (the need for full-duplex being usually the exception rather than the norm), using a single wire for bidirectional data sounds pretty obvious. The same has been used for SWD, and actually for QSPI as well.

[ataradov]

I2C sucked at the very beginning with Philips trying to charge license fees (hence generic TWI in Atmel parts). And their idea of manually assigning addresses from 7 bit range was "interesting".

I'm all for a fast and simple addressable bus, it would be great to have as an option. But I don't think peripheral adoption outside of the mandated by MIPI devices would be good. This is my only concern and this is the only reason I'm not too excited.

For a fast bus like this peripheral support follows the MCU anyway, so we need to get to the point where it is not an exciting announcement, but an expectation that a random MCU you buy will support I3C.

With I2C you can trivially bit-bang the whole thing, not so much with I3C.

[westfw]

What about single pair Ethernet?

[ataradov]

It would be fine if it replaces CAN. There is no issue with the MCU side - both RMII and SPI transceivers exist. So, it can be readily used with any existing MCUs. And the supporting components and circuits are very simple.

I've been looking at it for personal projects, but the existing transceivers are quite expensive in low quantities. I assume things will get cheaper if it gets any adoption. From what I hear, there is a lot of interest for automotive applications. But they also have a ton of inertia, so it would be interesting to see what vendors adopts it first.

[SiliconWizard]

I'm all for a fast and simple addressable bus, it would be great to have as an option. But I don't think peripheral adoption outside of the mandated by MIPI devices would be good. This is my only concern and this is the only reason I'm not too excited.

We'll see about further adoption. But while I would also like options, and possibly options that are fully open, that looks like something not very likely to happen.
Surely we can design a synchronous two-wire bus, even faster than I3C and release an open standard. The issue will be adoption.

I would like to see something like the RISC-V ISA, but for busses.

[Fredderic]

The new EEVBus?

[mike449]

The group I worked in couple years ago looked at implementing I3C target device (we are not allowed to use the s* word anymore). It is actually fairly difficult from the timing point of view and requires using custom I/O cells to meet the timing spec.
Then there is lack of test equipment and adapters to connect devices to PC on the bench.
Maybe just my limited perspective, but chip designers don't like I3C.

[abyrvalg]

Qualcomm SoCs (a quite widespread thing, check your phone) support I3C for years already (as one of many modes of their “generic serial” QUP peripheral), but I’ve never seen a device having something connected via it yet. These SoCs also have MIPI DSI/CSI ports, perhaps I3C just came in bundle with them.

[SiliconWizard]

The group I worked in couple years ago looked at implementing I3C target device (we are not allowed to use the s* word anymore). It is actually fairly difficult from the timing point of view and requires using custom I/O cells to meet the timing spec.
Then there is lack of test equipment and adapters to connect devices to PC on the bench.
Maybe just my limited perspective, but chip designers don't like I3C.

I'm reading the specs (446 pages), and it's quite complex, at least if one wants to implement the full specs with all supported modes (there are many). It supports DDR and even ternary symbols. Full compliance looks like a big endeavor.

[Darkover]

> I'm reading the specs (446 pages), and it's quite complex,

I agree with that. It will be interested to read the error list of the first implementations.

So I think it will need 5-10years before I will look in it.

Olaf

[mtwieg]

From what I understand, I see two major roadblocks:
1. Getting this to work is likely going to put big constraints on the number of devices on the bus, and the way the bus is laid out. For example, with I2C I can take a random slave on a breakout board and connect it to an existing I2C bus with a few feet of hookup wire. I'm betting that would not work with I3C. Even if the new slave is just I2C compliant, the presence of those long, uncontrolled transmission lines will probably destroy signal integrity for any I3C communications on that bus.
2. The interoperability of I2C and I3C devices depends on the I2C devices ignoring SCL pulses less than 50ns wide. I'd surprised if most slave devices out there actually implemented this at all, which means they couldn't be used on an I3C bus.

I'm guessing these challenges could be overcome by sprinkling buffers/repeaters along the bus. More sales for NXP...

[mark03]

Real question is, do you pronounce it "eye-three-see" or "eye-cubed-see"?