[ad_1]
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?
[ad_2]
Source link
