Multiple I2C slave devices on Arduino - Pull-up values

Question

This question is asked a lot and I've found many usable details on different forums regarding adding pull-up resistors on SDA/SCL lines. I know that only one resistor should be added on these lines regardless of how many devices are attached.

One thing that is not clear for me is that what if I2C devices are powered on from different sources, at different timing? In following schematic, I have used pull up resistors for both I2C devices. Considering devices might be turned on and off at different timing, or even one device might be absent, is it fine to remove the second pull up resistors (second I2C device) and connect them directly to SDA/SCL pins on uC? In this case (removing pull-up resistors from second device), what happens if device 1 is not available and only second device is connected?

---edit:

• Schematic was updated to include only one pair of pull up resistors connected to master side.

• I will not how swap or hot plug I2C devices.

• I2C devices are sensors (BME280 here, and Chirp capacitive soil moisture, here), not on breakout boards with preset pull up resistors.

• Is it possible to just connect resistors on master side and not slave side? In this case, would it be fine for both sensors?

^{simulate this circuit – Schematic created using CircuitLab}

Answer 1

You should consider adding some bus isolation between each slave and the master. The reason being is that the ESD diodes in the SCL/SDA pins of a slave that is powered down could be interfering with the I2C bus as they leech power from the bus to feed through the internals of the slave. Given the low current imposed by the pullup resistors being the only power source this shouldn't cause any damage to the slave, but it may well cause the I2C bus to be seen as LOW when it shouldn't, causing communication to fail.

You should add a buffer with an "enable" pin of its own between each slave and the bus. My device of choice is the PCA9306 from Texas Instruments. It also means that the slave has its own separate pullup resistors powered by its own 3.3V rail, keeping all the power separate.

You would then have sequences such as:

1. Power up slave
2. Give short powerup delay (if needed)
3. Enable PCA9306
4. Do I2C transactions
5. Disable PCA9306
6. Power off slave

The PCA9306 can also be used to connect 3.3V slaves to a 5V MCU if needed.

^{simulate this circuit – Schematic created using CircuitLab}

Answer 2

I wanted to add this as a comment but I ran out of characters, so this isn't an answer, just more comment.

@Majenko "I would never suggest using I2C over anything other than short PCB traces. i2C + wires = no thank you sir."

And that made me write the following.

We had one product that needed an external radio module. I put a connector in to extend the I2C bus. Total length of the additional cable was about 4 feet. Enough to route it outside the box and mount the radio close by.

Much later I am asked to look at why the communications is failing. The engineering manager had the cable extended to 20 feet. It worked for him on the bench when he tested it. No scope check on waveforms. No calculations. (he was a firmware programmer with just enough hardware knowledge to do his job)

I looked at the waveforms with a scope and I was shocked that it worked at all. The I2C lines were cpu to cpu. The radio had a microcontroller that acted as a slave I2C device.

I put a couple of buffers on either end and all was back in spec and it worked reliably after that, in the field and not just on the bench.

We have a bigger control box that uses I2C to communicate to modules in the back of the box. I have a buffer at the CPU end. The cpu is 3.3v, the modules are 5 volts. The buffer does a level conversion and stronger drive than the cpu could handle. The back of the boxes are shown below. Space for 14 modules. The bigger box is about 2 feet wide and 3 feet tall. The I2C lines run vertically down the center of each of the columns on the back of the board.

There also can be a secondary slave box for an additional 14 modules. The same back board. I used a second I2C port with and isolated I2C buffer for driving the lines. The slave boax was to be mounted beside the main box. Again I specified a short cable, this time six feet in length.

So one day I am asked if the cable can be extended. The contractor installing the panels wanted to put the slave boax on the other side of the hall by another electrical panel. I ask how long do they need. I'm told it is ten feet away. Yeah, ten feet line of sight. Once the cable was touted up into the ceiling, across the hall, and then down to the other box, the 10 feet turned into 30 feet.

I did a check with a scope. The rise times were still in spec, it seemed to work, so we made up a cable and told them that it may or may not work. Use at their own risk. I told them this was an exception and it is not to be a part of the product offering. But I'm sure there will be more exceptions.

And while it can work over those kind of distances the following shows how I2C can fail over short distances.

Same equipment. The smaller box in the picture was expanded with an additional larger box. The smaller box was mounted eight inches above the bigger box. (display and main cpu in the front panel of the product) Only temperature input into the modules in the smaller box. The bigger box was loaded with modules with control relays. Four 17 amp relays per module. Same electronics as in the exception described above. But they were having lots of sporadic behaviour. Pictures of the wiring, the installation, looked clean and well done. I had no idea why it was failing.

After this had been going on for a couple of months I asked our customer service person to ask what they have connected to our relays. Normally it would be motor up to 1 hp. They were controlling bigger motors and they had our relays turning on power contactors in a different panel. Lots of power contactors. All generating voltage spikes when they were turned off. I had them put snubbers across the contactor coils and the problems went away.

So I2C can work over longer distances, and it can fail over shorter distances. The whole picture needs to be taken into account. The problem is the whole picture often is hard to see.

Answer 3

I would include one resistor on each line at the master, powered by the master. That isn't the only option, just what I consider a cleaner simpler option.

The resistance is needed to provide the high seen on the line. The value of the resistance can vary. There is no one correct value. The pull up resistance needs to provide a high in the required time. There are specifications for this.

https://www.i2c-bus.org/specification/

If the lines do not have a lot of capacitance (wire and device capacitance) then a higher value resistance may be sufficient to meet the timing specification. If there is more capacitance then a lower resistance would be required to provide the stronger pull up in order to meet the timing requirements.

As far as multiple resistances. Yes there can be more than one on the line. But the accumulated resistance must be taken into account.

Many I2C devices mounted on a breakout board have pull up resistors. Typically these are around 5K Ohms. So if there are two devices, each with their own resistors, the combined total will still be within the lowest resistance that would be acceptable.

One thing to note. The specification does not list a lowest resistance that can be used. Instead it specifies the minimum sinking requirement of a device that would need to pull the voltage low enough. So a current is specified, and this current can be used to calculate the minimum resistance on the line.

The current spec (somewhere about 3ma I think, or maybe 2ma??) would calculate to being a 1k6 resistance when used with a 5 volt supply. With a 3.3 volt supply the calculated value would be about 1k1 Ohms. (again, this is a rough calculation, close enough for handgrenades)

This is enough of an answer considering what was asked. There are different modes/speeds and different combinations that can be applied and things can get very involved. And then you must spend the time and look at the specifications. But for most Arduino work this rough guide should cover most "normal" situations.

It really is quite an interesting technology.