This week’s EYE ON NPI (video) has an extra I bonus feature – we’re featuring the NXP P3S0200GM I3C Switch with Hardware Select and Enable.
You might be thinking we made a typo there, as you may be familiar with I2C but have you heard of I3C? Yep, that’s three I’s for ya, and you’ll probably start seeing more sensors, devices and microcontrollers that support I3C which is an extension of I2C with many improvements.
I2C is a sensor interface you are probably well familiar with, just about every microcontroller has I2C hardware support, and about half of peripheral devices and sensors use I2C for data transfer or configuration. I2C is easy to wire up: you only need two data lines. It’s a fairly simple overall communication system: each devices has a 7-bit address, with 1 bit for read/write commands, then data is sent after. You can put multiple devices on one I2C bus as long as the addresses don’t collide, great for low-pin-count setups or chaining. And, hey did you know that NXP invented I2C? Philips, which then became NXP, originally published version 1.0 the I2C specification in 1992 in app note UM10204 – and because it was a well-written, open, and royalty/license-free standard, the entire industry joined in.
But, there are a few things about I2C that can drive folks a little batty. First up is the speed limitations. I2C uses pull-ups for raising the voltage on the ‘open drain’ connections, but it takes time to charge and drain the capacitance of lines and gate inputs through a resistor. I3C does not use external resistors, instead there’s an active pull-up that transitions between Open-Drain and Push-Pull mode. This reduces power usage and allows I3C to run at a spicy 12MHz, well in line with SPI speeds.
Next up, there’s bus contention – woe is the engineer who has to deal with clock stretching on a bus, or missed clocks. I3C thankfully does not permit clock stretching! Peripherals cannot take control of the clock by keeping it pulled down. Instead all devices must respect the clock. “But!” you are saying “what if I’m designing a peripheral and over I3C we get a sensor wakeup or read request, and I’m not ready to immediately answer in time?” Normally you’d have to have to either use polling for a data-ready bit (yuck, uses a lot of power, bandwidth and time) or you can use an IRQ pin. But if you’re using IRQ pins then you’ve just lost the benefits of having a shared 2-wire bus! Well, there’s another nifty capability in I3C for in-band interruption management where the controller can hand off the bus to peripherals to notify when they are ready to be listened to. There’s a great document from NXP showing the high and low level implementation / trace details of I3C vs I2C that we recommend you check out here.
As you start adding I3C controllers and targets into your embedded systems, you may still find yourself dealing with address collisions, or maybe you want to have two controllers connect to one peripheral. Since I3C has a stricter timing requirement for dealing with the high speeds it can perform at, you’ll want a switching chip that is designed for I3C. That’s where the NXP P3S0200GM I3C Switch will come to your rescue. It’s from NXP who helped bring I3C to market, so you know it’s going to work exactly as the specification intends and will also be back-compatible with I2C devices.
And, best of all, the NXP P3S0200GM I3C Switch is in stock now for immediate shipment from Digi-Key, perfect for placement into your next design. Even if you’re only using I2C right now, you’ll be future-proof ready for when sensor and chip revisions start coming out with I3C support. Order today and you’ll be switchin’ by tomorrow afternoon.
Too bad i3c is managed by MIPI, who really like their patents and license fees.