I know twisted pairs are important for differential signals, which I2C is not. I also know I2C is not intended to be used over long wires. However, I made a design where I need to use a cable to connect two devices over I2C. The expected length is 0.2m to 0.5m. I am shopping for wires now and there is a nice 4-wire cable that fits the specs and a very similar cable with wires twisted in 2 pairs. I wonder, does I2C communication benefit from a twisted pair? Or might it hurt it perhaps? Or should I just choose the cable of the better color?
A twisted pair would not hurt, or particularly help I2C across a short cable run. You may have issues getting things to work if you're trying for 400kHz+ speeds, but standard 100kHz I2C won't be horribly attenuated by a .5m of cable.
However, there are very good reasons why you should not use I2C in any other application besides connecting two devices on the same PCB. I say this from direct experience writing robust baremetal I2C drivers (more or less successfully) for cable runs between two devices. It is a protocol fraught with opportunities to lock up and cause persistent communication failures, and there is nothing inherent to the protocol that allows you to recover from such a failure. In fact, the exact failure mode of I2C between any two microcontrollers that support it will depend wildly on the implementation of both the peripheral itself and the code to drive it. Cables exacerbate this problem because of momentary disconnects, noise susceptibility, etc.
An example of something that can go wrong: You are in the middle of an I2C read. The slave device is asserting a 0 bit (holding the line low) when something jostles the cable and it causes a brief disconnection. The cable is disconnected long enough that the master reads a 'nACK' and ceases to send SCL clock cycles. Upon reconnection, the slave is still holding the SDA line low while waiting for SCL cycles to continue asserting its data. However, the master device can't assert a start condition because the SDA line is being held low, so no new frames can be generated.
There are some obvious logical solutions to the above problem (write a timeout on the slave side, write detection code on the master side that injects clock edges to unlock the slave...). But the reality of writing robust I2C is that there are going to be many more issues like this that are not easy to predict on inspection, and take debugging prowess and intuition to fix. Particularly when working with microcontroller peripherals, it's often the case that you can catch an error, but struggle to properly recover from it. It is for this reason that I highly recommend using a different protocol. If you don't have to bus data to multiple devices, UART would be a far superior choice (as long as you have good framing logic for multi-byte transmission). CAN is likely the best option if you do end up having to talk to multiple devices.
I don’t think it would be beneficial to twist the SCL and SDA wires together as this would increase crosstalk between them. Nor do I think it’s best to twist them together with GND, as this increases capacitance.
Consider an HDMI cable for example. There is an I2C bus embedded on it (DDC) along with ground and 5V. These are run near each other, but not twisted together. They are however run inside the overall shield to help reject and suppress interference.
That said, I2C can do fine without twisted pairs. For the distance you’re talking about (0.5m) just about any wiring could work, even the cheapest phone cord. If what you have is two twisted pairs, then use the pairs as signal/GND even if it increases capacitance (I know I’m contradicting myself here). The best choice for a high noise environment would be a non-twisted pair with separate return, with an overall shield.
If you follow a proper EMI concept, then nothing speaks against connecting two devices over I2C.
Yes, you should use a twisted pair cable, as this is the weapon of choice against inductive coupling. If you use a shielded cable, you can suppress capacitive coupling, too (You must connect both ends of the shield, but beware of ground loops).
You can do even better if you isolate the I2C transceiver at one end.
The cable length used is not sufficient to have to apply the line theory. It's just an extra capacity added and it will influence the rise and fall times of the signals. In other words and accordingly, the speed of the signals will have to decrease. Twisted or not don't really benefit. Only EMI are concerned.
This is not the case when you use Ethernet cables, these must be have the "good" resistor matching termination. Only delay is then concerned.