Hello !
I need to adress 12 MCP4728 (with the same I2C adress/ID), with one CPU and 12 logic lines wired to LDAC of each 4728.
All the 12 MCP4728 are loaded with same I2C data, so the returned ACK are exactly in time.
And so the CPU sees only one MCP4728.
The 4728 DAC values are updated with the LDAC pin.
Is there any hardware issue with I2C bus ?
Thank you for your help !

 

Hello !
I need to adress 12 MCP4728 (with the same I2C adress/ID), with one CPU and 12 logic lines wired to LDAC of each 4728.
All the 12 MCP4728 are loaded with same I2C data, so the returned ACK are exactly in time.
And so the CPU sees only one MCP4728.
The 4728 DAC values are updated with the LDAC pin.
Is there any hardware issue with I2C bus ?
Thank you for your help !

IMHO I2C is not designed to work this way, having multiple devices at the same address. You may or may not be able to make this work, but I would hate to bet my career and the company's money on this proposition.
ETA: Given the ubiquitous nature of I2C implementations on a typical embedded processor, I would opt for the safer alternative of two separate I2C networks whose operations could be overlapped. 12 devices are actually quite a bottleneck.

 

Hello !
I need to adress 12 MCP4728 (with the same I2C adress/ID), with one CPU and 12 logic lines wired to LDAC of each 4728.
All the 12 MCP4728 are loaded with same I2C data, so the returned ACK are exactly in time.
And so the CPU sees only one MCP4728.
The 4728 DAC values are updated with the LDAC pin.
Is there any hardware issue with I2C bus ?
Thank you for your help !

And what happens when eleven of them acknowledge but the twelfth doesn't? Or one of them acknowledges but the other eleven don't? You CPU will think that everything is find and happy and everyone received the message.

 

And what happens when eleven of them acknowledge but the twelfth doesn't? Or one of them acknowledges but the other eleven don't? You CPU will think that everything is find and happy and everyone received the message.

The canonical answer is something that you may not have intended.

 

The MCP4728 allows you to specify 8 addresses. That's the limit of these devices on an I2C bus. Section 5.4.3 of the data sheet talks about the "general call software update" – this command causes all (maximum of 8) MCP4728s to simultaneously write data to their outputs.

 

And what happens when eleven of them acknowledge but the twelfth doesn't? Or one of them acknowledges but the other eleven don't? You CPU will think that everything is find and happy and everyone received the message.

Why a MCP4728 would react diferently with exactly the same conditions, and with the same I2C data and clock ?
Anyway, the I2C is open collector, so the CPU will wait until the bus is released... No ?

 

The MCP4728 allows you to specify 8 addresses. That's the limit of these devices on an I2C bus. Section 5.4.3 of the data sheet talks about the "general call software update" – this command causes all (maximum of 8) MCP4728s to simultaneously write data to their outputs.

Yes, but the LDAC pin allow you to transfer the I2C latches into the DACs latches with a hardware pin. So if you load the same data in the 12 MCPs and then you transfer data one by one with 12 separate LDAC lines, you can adress 12 MCPs...
1- CPU send the same data to the 12 MCP I2C latches.
2- LDAC transfer the data to a selected MCP's DACs.

 

Why a MCP4728 would react diferently with exactly the same conditions, and with the same I2C data and clock ?
Anyway, the I2C is open collector, so the CPU will wait until the bus is released... No ?

NO

I2C is open collector and bi directional
what happens if one device answers the ack before the others ?
the others see an ack when they should see an OC

If you want to have more than one I2C device with the same address as another,
then you need to use things like the TCA9544A

 

NO

I2C is open collector and bi directional
what happens if one device answers the ack before the others ?
the others see an ack when they should see an OC

If you want to have more than one I2C device with the same address as another,
then you need to use things like the TCA9544A

Why one 4728 would send the ACK before another 4728 if they receive exactly the same I2C data at the same time ?
I guess the tolerance with propagation delays is in the picoseconds range, and it would be seen like a very small parasitic cap...

 

Why one 4728 would send the ACK before another 4728 if they receive exactly the same I2C data at the same time ?
I guess the tolerance with propagation delays is in the picoseconds range, and it would be seen like a very small parasitic cap...

How do you know.
Are all the devices off the same die ?
Are they the same assembly house ?
Are all the tracks the same length ?
How are you taking care of reflection on the tracks. .
Are all the chips working at exactly the same temperature and voltage.
Re difference in time ,
Look at the data sheet for the range of times on a chip.
At the end of the day
All I can say is I've had to fix a system that had two devices on the same address . It does not work.
If you want to go ahead , then your the expert , good luck
Let us know how it goes

 

In case you missed it in post #2, I said this:

I would hate to bet my career and the company's money on this proposition.

Having more than 8 devices on an I2C bus has implications for the pullup resistors on SCL and SDA as well as for the capacitive loading on those signal lines. Don't do it, it will not be reliable, and you'll get no sympathy or support when it fails, and your butt is on the line. However, if you think you're brighter and smarter than all the rest of us including the folks that designed I2C, then by all means pay your money and take your chances. Just don't start whining when it blows up in your face.

Your original post seemed like it was asking for permission to do this. You'll get neither permission nor forgiveness here. Maybe another forum will be more sympathetic, but I hope not. This will be a disaster if you proceed.

 

Whenever I see a statement like this, my immediate reaction is, “Uh oh!”

All the 12 MCP4728 are loaded with same I2C data, so the returned ACK are exactly in time.

Good design practice addresses the exact opposite situation, because all of something will never be exactly the same

 

Why don’t you want to individually address the MCP4728s? If for some reason you just can’t manage two I²C busses, you could do something hackish like change the addresses of half of them to something you don’t use, then call the others, then switch the addresses of those to the dead addresses and repeat.

You can use the LDAC line to tell a particular MCP4728 to write a new address to its configuration. So with a little care, you could juggle addresses and still have the 12 on the bus without expecting the very unlikely case that somehow they will never have collisions when they try to ACK.

 

What everyone has so far mentioned, can be summarized in a single phrase: Murphy’s Law.
Ignore at your own peril.

 

Why don’t you want to individually address the MCP4728s? If for some reason you just can’t manage two I²C busses, you could do something hackish like change the addresses of half of them to something you don’t use, then call the others, then switch the addresses of those to the dead addresses and repeat.

You can use the LDAC line to tell a particular MCP4728 to write a new address to its configuration. So with a little care, you could juggle addresses and still have the 12 on the bus without expecting the very unlikely case that somehow they will never have collisions when they try to ACK.

For this peripheral there are a total of 7 address bits, four of them are fixed and three are variable. It is not possible to have more than eight of these devices on a single bus. I believe there is an I2C variation with more address bits, but this peripheral does not support that extension. We need to convince this guy that he is risking his career and his professional future with this scheme.

 

Why a MCP4728 would react diferently with exactly the same conditions, and with the same I2C data and clock ?
Anyway, the I2C is open collector, so the CPU will wait until the bus is released... No ?

You seem to like throwing around that word "exactly" a lot. You need to break that habit. No two things in the physical world are ever "exactly" the same. Every device is going to have somewhat different thresholds and delays than the other chips. If there is any noise present (and there is ALWAYS noise), then if it is bad enough some of the devices may interpret it as a SCL pulse and others may not.

Do you know what happens if one of your devices goes to acknowledge its address but senses that the SDA line is LO (because one of the other chips was slightly faster in getting its acknowledgement out first)? Does it just blindly go ahead and issue its own acknowledgement? Or does it assume something was wrong and not issue its acknowledgement in light of recognizing that it doesn't have control of the bus? Does the I2C protocol specifically cover this case? If not, does the device data sheet cover it?

 

Another approach: It may sound crude, but you can bit-bang as many I2C busses as your I/O pins will allow. With a little work, the particular pair of I/O pins to be used for each bus can be passed to a single I2C routine as parameters.

 

For this peripheral there are a total of 7 address bits, four of them are fixed and three are variable. It is not possible to have more than eight of these devices on a single bus. I believe there is an I2C variation with more address bits, but this peripheral does not support that extension. We need to convince this guy that he is risking his career and his professional future with this scheme.

The way this particular device gets it address bits set is via the LDAC pin. So, it is possible to change the address of a particular device out of band, so to speak. To be clear, while I believe the scheme is possible, I don’t think it is a good idea. It would ba a nice hack if something actually prevented doing it the right way, but that doesn’t seem to be the case here.

I completely agree that using two busses is the right way to do this, and that depending on a behavior that is not guaranteed by the manufacturer is a grave error.

 

Just do it propped and use the I2C expander .

 

Just do it propped and use the I2C expander .

Either way, but the key is to address each device individually and not assume the part of the protocol that tells you if things are working is not important.