Multiple instances of same device on I2C bus

Question

I am currently designing a board where I need to include a whole bunch of I2C devices. Since the number is quite high, address clashing is an issue, that of course we can solve implementing different bus segments, or with translators.

There is a particular situation though, where I had an idea.

I have two arrays of 8xADG2128, and I want them to be configured in the exact same way. The I2C-compliant solution is to use a bus isolator, or an address translator, and get over it, but I was wondering if it is advisable to just hook them all to the same bus, and hope for the best.

To abstract a bit:

I have two identical devices, with an I2C slave interface, with the same address. I want to send them the same packets, in the same order and so on. Can I just connect SDA and SCL in parallel, and get away with it?

I do not need to read from the devices, and I am aware that a NACK would be hidden. Also, the devices do not support clock stretching.

Edit, to clarify some comments:

Yes, I do not care if a device stops working and understand I have no way of knowing

The master we are using does not resend data on a NACK, but raises the error to the host.

The board we are designing is meant to be used in an electronics lab environment, as a support to evaluate a product that my company is making. We expect to make ~20 boards, no mass production, no board will be sent to a third party.

Answer 1

From ADG2128 data sheet:

Every byte requires an ACK. With parallel devices, the only way you can get a NACK, is if all generate a NACK. Effectively, you have no way of verifying if the the slave received the data. You have turned a communication protocol into an unknown.

From Understanding the I2C Bus.

There are several conditions that lead to the generation of a NACK:

1. The receiver is unable to receive or transmit because it is performing some real-time function and is not ready to start communication with the master.

2. During the transfer, the receiver gets data or commands that it does not understand.

3. During the transfer, the receiver cannot receive any more data bytes.

4. A master-receiver is done reading data and indicates this to the slave through a NACK.

You have defeated the rudimentary error checking of I2C. Also, you cannot read switch data back without getting a response from two slaves.

The master is blind to slave problems.

You are making ~20 boards to test a product, so I'm sort of wondering why you are concerned about BoM increases.

You do a test with your switch testing your product. It does not work. Is it the product or is it your switch? You cannot do reads on switches to determine if they are in the correct state.

Isn't it better to have a switch board that will work or a switch board that may work?

Answer 2

Well, if you attach these chips directly to the bus, you definitely risk that they simply do what they are allowed by the standard to do – use the bus actively.

In fact, I²C and the datasheet says they'll do exactly that:

The peripheral whose address corresponds to the trans mitted address responds by pulling the SDA line low during the ninth clock pulse, known as the acknowledge bit. At this stage, all other devices on the bus remain idle while the selected device waits for data to be written to or read from its serial register.

What you could do, of course, would be attach them through hefty series resistors – whilst these shouldn't matter much while SDA and SCL are in high-Z "input" mode on your ADGG2128, they'd suffice to stop the IC from actually pulling down the bus, should they ever decide to do so.

Problem is that the bus master then would never notice that a chip acknowledge it was on the bus. So, maybe try prefixing 7 of your 8 identical chips with a hefty series resistor on their SDA and SCL, and use one (ideally, the one furthest away from the bus master) normally.

I've never tried this.

Another idea from the heap labeled "Marcus' bad ideas that might turn out to be helpful": You could use 3 of the outputs of these switch matrices to control a device's own address pins – or that of others. Maybe that helps you come up with a clever solution.