[semi-extrinsic]

Yes, I2C is technically meant for intra-board use. But it works surprisingly well over large distances if you avoid daisy chaining and run one cable to each target. If you use multiple identical target chips you need to route everything individually to a central MUX anyways.

As an example, the Nintendo Switch used I2C over a ~2m cable to communicate between the controller and nunchuck. Worked fine even in noisy household settings with wifi and microwaves and whatnot.

At work we've used sensors for data logging that communicate using I2C over distances more than 20 meters, using plain Cat5 cable.

[phero_cnstrcts]

Do you mean the Wii?

[semi-extrinsic]

Yes, of course I meant the Wii, sorry about the mix up. Too late to edit now.

[TaylorAlexander]

Thanks for this! I recently designed a sensor board that connects to our main board with I2C, and in chatting with an EE about it she mentioned I2C is not intended for intra-board use. I just put a scope on the signals yesterday and they seem okay. The cable is only 15cm long, and it connects to a multi-use port which would be difficult to make work with differential signals in addition to the other things that port can do. I’ll keep an eye on it but maybe it’s okay.

[crote]

I2C doesn't really care about cable length all that much. The thing to keep in mind is the interplay between bus capacitance, pullup strength, and drive strength.

A longer cable means more bus capacitance, which means with the same pullup resistor the signal rise time will be higher, which means you need to reduce the bus speed. A stronger pullup will reduce the rise time (allowing a higher bus speed), but each chip's driver has to be able to overpower the pullup too. If the pullup is too strong for the drivers, you end up being unable to send a zero.

In practice your cables can be quite long, you just have to run it at a lower speed. If you really want to push it, there's always transceivers like the PCA9615 which turn it into a differential bus.

[kenz0r]

If you _must_ use I2C, then look at SMBUS if its an option for the parts. I2C's biggest failing is that there is no protocol level timeout, so one stuck device can block your entire bus unless you have a reset line for all the peripherals on it. https://www.analog.com/en/resources/design-notes/guide-to-co...

[fl7305]

Classic I2C problem. After your CPU resets, at least clock out a bunch of cycles onto I2C to get interrupted I2C transactions to finish.

[TaylorAlexander]

Ooh this is great to know thank you!

[tinco]

Not an EE here, but I've dragged some circuits together as a hobby and have only used I2C. Why would Nintendo opt for I2C instead of a differential pair? Is there some extra part cost? What part(s) would you use to go from I2C to differential?

[semi-extrinsic]

I don't know why Nintendo did it. But it's certainly quite convenient, there are even standard form factor breakouts for the Nunchuck like in the link below. This gets you a controller with accelerometer, 2 buttons and a 2 axis joystick with plenty of libraries available for using it with Arduino, RPi etc.

https://learn.adafruit.com/adafruit-wii-nunchuck-breakout-ad...

[joshvm]

I don't know about I2C specifically, but a related device is a serdes (serial-deseria) which converts between a parallel interface and one or more differential pairs.

https://www.latticesemi.com/what-is-serdes

Someone else mentioned the PCA9615 which looks like it'd to the job.