1
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I assume you don't care if one of the devices suddenly stops working? You would have no way of knowing that if you connect them in parallel. \$\endgroup\$ – Elliot Alderson Jan 16 at 15:10
  • \$\begingroup\$ What are the consequences if a NACK is missed? An I2C master would resend data if NACK was received. You could have intermittent operation of parallel switches because you are defeating the I2C communication protocol. I'd parallel masters and use two separate buses. \$\endgroup\$ – StainlessSteelRat Jan 16 at 16:55
  • \$\begingroup\$ @ElliotAlderson please see the updated question \$\endgroup\$ – Vladimir Cravero Jan 17 at 8:02
  • \$\begingroup\$ @StainlessSteelRat please see the updated question \$\endgroup\$ – Vladimir Cravero Jan 17 at 8:02
4
\$\begingroup\$

From ADG2128 data sheet:

ADG2128 Write Cycle

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?

\$\endgroup\$
  • \$\begingroup\$ Hi, thanks for your answer. I do believe you address a few key points, but still the main one remains open: will it work? I understand it is an broad question, and it depends on the definition of "work"... I will wait a few days to see if somebody else comes up with some more insights. \$\endgroup\$ – Vladimir Cravero Jan 19 at 7:58
  • \$\begingroup\$ Engineers never quibble about paying for good test equipment. You are building a switch board to test a product. The hardware will work, but cannot be verified by software. So the answer is no! If a product test fails, what has failed, the product or your test equipment. There was an axiom I had over my desk for years, When you are up to your neck in alligators, it's difficult to remember the goal was to drain the swamp. What's your goal? What do you gain if it works and more importantly, what do you risk losing if it fails? \$\endgroup\$ – StainlessSteelRat Jan 19 at 21:47
  • \$\begingroup\$ I understand your suggestion for my particular case, and we do not need to save a dollar on a 1000 dollars BoM. Main concern is PCB space, and the size is fixed. Anyway, I still want to wait a bit because I am more interested in an answer that is not strictly related to our particular case, but rather to i2c in general. \$\endgroup\$ – Vladimir Cravero Jan 20 at 15:15
1
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ I don't see the proble. I2C is an open-collector bus, so all that would happen is that multiple devices pull the SDA low. No problem in that. \$\endgroup\$ – Wouter van Ooijen Jan 16 at 12:54
  • 1
    \$\begingroup\$ Thanks Marcus for your answer. As Wouter says, I do not understand why the ACK is an issue, the slaves have no way of knowing that the ACK is also being generated by someone else, and I doubt there is a mechanism to detect that such a condition exists, if one of them stretches the ACK a bit more than the others. \$\endgroup\$ – Vladimir Cravero Jan 16 at 13:06
  • \$\begingroup\$ Why not do it the intended way? The chip has 3 address lines, A2-A1-A0. Connect A2,A1 on both to Gnd, A0 to Gnd on one and A0 to Vcc on the other, access each individually. Then each has its own address to respond to. \$\endgroup\$ – CrossRoads Jan 16 at 15:17
  • 1
    \$\begingroup\$ Keying off of Marcus's Bad Idea. Connect A3,A1,A0 together to a switch output or mux output. Drive the one you want to select low. Access via 0b1110000. Drive high when done. All would be at 0b1110111. \$\endgroup\$ – StainlessSteelRat Jan 16 at 17:10
  • 1
    \$\begingroup\$ @VladimirCravero After every byte, an ACK is expected. Parallel switches means no NACK is possible unless all parallel NACK. So rudimentary error checking of I2C has been circumvented. It may work, but is it mass producible. Pictures problem report on random failures. It could be a problem you have designed into the product or something else. You have no way to separate them. \$\endgroup\$ – StainlessSteelRat Jan 17 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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