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?
\$\begingroup\$
\$\endgroup\$
6
-
1\$\begingroup\$ "I need to use a cable to connect two devices over I2C". I would suggest not to do it. Can't you use some other bus like CAN or old fashioned RS232 ? \$\endgroup\$– Mathieu G.Commented Mar 8, 2020 at 13:48
-
11\$\begingroup\$ For 0.5m and low speed I2C you are probably OK. If you have 4 cores, in pairs, make them SCL/GND, and SDA/VCC, where VCC is well decoupled at both ends, forming an AC GND. \$\endgroup\$– user16324Commented Mar 8, 2020 at 13:56
-
3\$\begingroup\$ @MathieuG. HDMI and DVI interfaces have I2C running through the cable and it works for 10+ meters so it will work over 0.5 meters if done properly. Like exactly the way BrianDrummond suggested. \$\endgroup\$– JustmeCommented Mar 8, 2020 at 16:42
-
\$\begingroup\$ @Justme interesting ! I will look at it. You say it works but would you recommend to do it ? \$\endgroup\$– Mathieu G.Commented Mar 8, 2020 at 18:31
-
1\$\begingroup\$ @MathieuG. It would depend a lot of factors not revealed here. But just connecting two boxes directly with I2C and power for max 50cm it seems easiest solution, than to use separate microcontroller on both boxes for protocol conversion and use tranceivers for RS232, RS485, or CAN, between them. Not many MCUs even have CAN peripheral, but nothing prevents using a CAN PHY for simple UART though - it's just overkill. \$\endgroup\$– JustmeCommented Mar 8, 2020 at 20:51
|
Show 1 more comment
4 Answers
\$\begingroup\$
\$\endgroup\$
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.
\$\begingroup\$
\$\endgroup\$
3
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.
answered Jun 17, 2021 at 17:11
-
\$\begingroup\$ Indeed, twisting the two digital signals together would be wrong. I agree that a shield is far superior for this case than twisted pair. \$\endgroup\$ Commented Jun 17, 2021 at 17:21
-
\$\begingroup\$ It’s a balance between minimizing loop area to the return and keeping capacitance low. Given you can’t really terminate I2C to minimize reflections, it’s just better to try to get the lowest capacitance possible. \$\endgroup\$ Commented Jun 17, 2021 at 20:07
-
\$\begingroup\$ Would it be better to send SDA/SDA and SCL/SCL in two twisted pairs versus SDA/GND and SCL/GND? I guess it would reduce capacitance? \$\endgroup\$– NateSCommented Apr 10, 2023 at 3:13
\$\begingroup\$
\$\endgroup\$
1
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.
answered Mar 8, 2020 at 13:56
-
2\$\begingroup\$ ensure you have timeouts and retries implemented in the i2c code. Glitches tend to cause the i2c bus to lock up, so you need a mechanism to recover from this. \$\endgroup\$– KartmanCommented May 9, 2021 at 11:17
\$\begingroup\$
\$\endgroup\$
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.