I need a wired connection between one Master and several (5-10) slave devices. I've considered UART, SPI, I2C, RS232 and RS485. In the end, I've narrowed down the options to I2C with a repeater or RS485. Please have a look at the schematic diagram in 1

In particular this I2C range repeater (p82b715) looks reasonable for my application: https://www.ti.com/lit/ds/symlink/p82b715.pdf

My project needs to fulfil following requirements:

  • 5-10 Slave devices
  • Master/Slave communication
  • Maximum of 10m wired connection
  • Power should be as low as possible since it will be battery-powered

I am interested in your experience with wired connection beyond the stable limits of I2C and how you would realize it. Thank you a lot!

enter image description here

  • 1
    \$\begingroup\$ Mind you that many video cables such as VGA, DVI and HDMI are available at 10m lengths and they don't use I2C repeaters. But they are also point to point connections. Many people that have used those I2C repeaters have still had difficulties getting it to work. So if you ask for opinions, if you have the option for real RS485, then forget tricks and band-aid that would enable I2C over 10m multi-drop bus. \$\endgroup\$ – Justme Feb 10 at 12:32
  • \$\begingroup\$ thank you @Justme : one important constraint I have that I shouldn't burn too much power so I would need to design the RS485 communication efficient. \$\endgroup\$ – Marco Bobinger Feb 10 at 12:47
  • \$\begingroup\$ This is a question-and-answer site. Do you have a specific question or are you just looking for opinions? \$\endgroup\$ – Elliot Alderson Feb 10 at 12:49
  • \$\begingroup\$ My question is: Will my schematic with two I2C repeaters on each side work if I need to send and retrieve data from slave devices? \$\endgroup\$ – Marco Bobinger Feb 10 at 13:01

I've narrowed down the options to I2C with a repeater or RS485.

The important thing that will make this work is that you have data and clock from only master to slave. In other words, you don't have clocked data back from a slave as per this statement: -

Master/Slave communication

And, if that is the case, it should work just fine. I've done the same with one slight difference; my interface was SPI and I was wanting to drive a bunch of DACs down 10 metres. The DACs were only reading data and I used an RS485 conversion to achieve this and I fed power down the same cable. Data rate from memory was 2 Mbps.

If you are hoping to retrieve data from the slaves then it won't work due to the clock signal originating at the master.

I note that your diagram implies bidirectional data (blue double ended arrows) and again, I emphasize that this will not work unless data rates are a lot lower than the forward direction (master -> slave) data rates: -

enter image description here

  • \$\begingroup\$ Thank, that's helpful. I need to retrieve data from the slaves as well. They are intended as MCUs that also collect data. In that case I2C and an I2C repeater IC do not seem to be an option, so I could go for RS485 or I2C with very short cables, which doesn't really fit my constraints. \$\endgroup\$ – Marco Bobinger Feb 10 at 13:00
  • 1
    \$\begingroup\$ If the originating data is SPI or IIC, using RS485 does not exempt you from transmitting the clock (as another 485 signal). if you want full forward and full return speeds then, you need to engineer a solution that alternates master and slave for each data direction. Not too tricky if using MCUs at each end. In other words, apart from very short distances (a few cm to a metre) clock has to accompany data from the end transmitting that data. If it can be done, better to transmit data asynchronously in both directions then clock "round trip" delay isn't an issue because clock isn't needed. \$\endgroup\$ – Andy aka Feb 10 at 13:08
  • \$\begingroup\$ Speed can be low and each of the 5-10 slaves only needs to send at a maximum of 30-60seconds. The data also doesn't need to originate from SPI or I2C. I want to interface two MCUs, where the MCU in slave mode collects some sensor data. I could e.g. use the UART of the MCUs to convert to RS485 and use that architecture. I'm not sure, maybe I didn't get your answer completely. \$\endgroup\$ – Marco Bobinger Feb 10 at 13:47
  • 1
    \$\begingroup\$ I'd consider UART in both directions as being the most promising. On the job I did, the coding was a done deal so I was forced into an SPI (clocked) interface but, if I'd have had the choice I would have used UART comms converted to RS485 @MarcoBobinger \$\endgroup\$ – Andy aka Feb 10 at 13:51
  • \$\begingroup\$ thank you for your helpful comments! I'll most likely design my schematics for UART to RS485. \$\endgroup\$ – Marco Bobinger Feb 10 at 14:01

From the comments, it seems there is no actual i2c device that must be used, communication is always initiated by the central device, and UART lines are available on both ends. In that case I don't think there is any advantage to i2c. Half duplex RS485, for example, would use the same number of lines and perform better all around.

This answer is just for completeness, and because the question title says it. This is to address extending the range of i2c. I am not talking about the repeaters themselves, just general i2c-in-a-cable. To be totally clear, this entire scheme is not recommended, more like if you have to do it, here are some things that could help.

First of all, here is an app note from NXP on the subject.

I tried to catalog various i2c issues I became aware of in a previous post, here.

Doing extended range i2c would make some limited sense to me in a situation where a sensor is used that requires i2c, speed is limited, and especially if a working design already exists, but the range must be increased -- e.g. from a 100mm internal connection to several-meter remote sensor. I went through this exercise with 100kHz data rate and did get it to work well (tested to 15m+ in a M8x4 SAC cable, with both PVC and PPE inner insulation, and the unfavorable wire arrangement. Deployed with 5m length to be safe).

The main points IMO are to choose drivers with a relatively low dV/dt limit on each end, to avoid placing SDA and SCL next to each other in the cable (whether linear or circular), to optimize the pull-up current for your setup, and minimize capacitance in the cable. If the cable format is fixed by specification, different inner insulation materials and thicknesses can still change this quite a bit.

In my case, the MCU I was using had dV/dt limited open-drain driver in i2c mode, but the sensor did not, and the cable was made the "wrong way" for legacy reasons. On the other hand I had Vcc = 5V, which gave a little extra margin vs the crosstalk glitches.

I used constant current pull-up, about 1mA on each end of each line, via PNP simple current mirror. Added 68 ohm series termination. Plus ESD protection using a diode array designed for USB, which fit nicely - although big caveat, the devices built for this project were not tested for ESD, to the best of my knowledge. The order of the parts was, ESD protection on the "outside", then the 68ohm, then the pull-up mirror, then finally the chip with the i2c.

Another note is that the series termination won't work when the transceiver is high (and thus high impedance). The current-mirror pull up arguably helps this to a limited degree, on the theory that the output transistor of the mirror is initially in saturation when the falling edge arrives. I'm not too sure how much effect this really has, but in any case, we are getting some termination at the source.

For the crosstalk victim line, however, the constant current pull-up makes a noticeable difference. It does this by sourcing the full current almost immediately, whereas a resistor pull-up would source current only in proportion to how much voltage had already been dropped. As a result, the voltage drop on the high victim line from the same transition on the source line is reduced by something like 50% vs a resistor sized to produce the equivalent current in the low state. The rise time improves too, as you get a constant slope rather than the familiar RC shape.

Despite all this I was not really happy with this design, and if I had to do it over, I would use some kind of differential i2c extender chip.


Not the answer you're looking for? Browse other questions tagged or ask your own question.