Post Undeleted by StainlessSteelRat
2 deleted 626 characters in body
source | link

I2C uses open drain with pull-ups. Devices pull SDA to ground and a pull-up resistor pulls SDA up. If two slaves want to drive SDA to ground, there is no problem on the hardware side.

I believe your problem lies with: parallel I2C slaves defeat the rudimentary error checking of I2C.

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.

Switch 1A receives data and ACKs, while parallel switch 1B has some issue with data and cannot NACK. Software continues as if all is well with no way of knowing about a possible problem.

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.

It'sYou have defeated the rudimentary error checking of I2C. Also, but you have defeated itcannot read switch data back without getting a response from two slaves. The

The master is blind to slave problems. 

As have been suggested in the comments, prototype two in parallel andYou are making ~20 boards to test the crap outa product, so I'm sort of itwondering why you are concerned about BoM increases.

It may work, but is it mass producible. Pictures future problem report on random failures. It could beYou do a problem you have designed into thetest with your switch testing your product or something else. You have no way to separate them It does not work.

Fix Is it at design 1×cost, pre-production 10×, production 100×, but the field 10,000×. Inproduct or is it your case, the solutionswitch? You cannot do reads on switches to the problem, which you deliberately designeddetermine if they are in, would be scrap the hardware and redesigncorrect state. I'd call that priceless (or costless)!

Are you willing to risk your professional careerIsn't it better to save pennies/dollarshave a switch board that will work or a switch board that may work?

I2C uses open drain with pull-ups. Devices pull SDA to ground and a pull-up resistor pulls SDA up. If two slaves want to drive SDA to ground, there is no problem on the hardware side.

I believe your problem lies with: parallel I2C slaves defeat the rudimentary error checking of I2C.

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.

Switch 1A receives data and ACKs, while parallel switch 1B has some issue with data and cannot NACK. Software continues as if all is well with no way of knowing about a possible problem.

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.

It's rudimentary error checking, but you have defeated it. The master is blind to slave problems.

As have been suggested in the comments, prototype two in parallel and test the crap out of it.

It may work, but is it mass producible. Pictures future 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.

Fix it at design 1×cost, pre-production 10×, production 100×, but the field 10,000×. In your case, the solution to the problem, which you deliberately designed in, would be scrap the hardware and redesign. I'd call that priceless (or costless)!

Are you willing to risk your professional career to save pennies/dollars?

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?

    Post Deleted by StainlessSteelRat
1
source | link

I2C uses open drain with pull-ups. Devices pull SDA to ground and a pull-up resistor pulls SDA up. If two slaves want to drive SDA to ground, there is no problem on the hardware side.

I believe your problem lies with: parallel I2C slaves defeat the rudimentary error checking of I2C.

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.

Switch 1A receives data and ACKs, while parallel switch 1B has some issue with data and cannot NACK. Software continues as if all is well with no way of knowing about a possible problem.

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.

It's rudimentary error checking, but you have defeated it. The master is blind to slave problems.

As have been suggested in the comments, prototype two in parallel and test the crap out of it.

It may work, but is it mass producible. Pictures future 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.

Fix it at design 1×cost, pre-production 10×, production 100×, but the field 10,000×. In your case, the solution to the problem, which you deliberately designed in, would be scrap the hardware and redesign. I'd call that priceless (or costless)!

Are you willing to risk your professional career to save pennies/dollars?