The OP seems supremely confident that he can hack the I2C bus protocol. All attempts to discourage / enlighten him seem to fail. He is bringing out all the old bus ideas that were rejected long ago. I don't know maybe he is young and doesn't realise many people have been round that block many times before.
Well you are living up to your moniker! Which is cool with me by the way, too much PC BS these days.
It's been a long time since anyone's called me anything close to "supremely confident". I going to have to take it as a compliment. So thanks, appreciate it!
Not young. Here's a hint: I bought a Motorola 6800/MIKBUG based computer for $1K in 1976 just after I graduated from high school. Taught myself how to program machine language (hand assembled of course). No it wasn't an Altair, a Commodore, a PET or an Apple I - the 6502 had just come out and the Z-80 was the next big thing.
Simply the wrong protocol for the job
I agree the SMBus is the right way to go. However it isn't clear if there is an Arduino library for it. If the SMBus and I2C are "compatible" as the Intel blurbs say, then I should be able to use I2C to replicate the SMBus protocol (which implies that someone from Intel "hacked" I2C to come up with SMBus). But that doesn't sound like a pleasant thing to do.
He could use I2C to have master assigned slave addresses, by controlled sequential startup of the slaves, as example.
I don't need a "controlled sequential startup" at all. I just want the master to assign the slave addresses.
For most practical purposes (as opposed to academic), storing a unique address in EEPROM is a good option.
I agree that storing the addresses in EEPROM is easier. But being nuts is more fun. And besides once an address is assigned to a slave, it can be stored in EEPROM and the whole situation becomes sane again.
[quote\Otherwise, WHY HAVE MULTIPLE SLAVES if they are all doung the same thing and calling home with the same names???[/quote]
It is very reasonable to have a large array of slaves doing all the same thing. It is very unreasonable to have them call home with the same address -- that's why I'd like to have the addresses assigned by the master.
As BenF says, multi-master bus arbitration is available on the AtMega. Still unknown if the Arduino I2C library can handle it in a reasonable way.
The link I gave clearly shows that it is possible for an Arduino to be both Master and Slave at the same time (unless that guy was throwing some BS out into the ether).
Like I said, those two aspects open up a lot of opportunities....
This generally works when arbitration is only required once every blue moon, but it will not work when two or more devices try to claim the bus at the exact same clock edge (such as may be the case when multiple identical devices are powered on at the same time).
I think the scheme I proposed would prevent them from hitting the exact same clock edge nearly all the time, but there is a very small probability it could happen. Each slave is quiet until the master kicks the process off with the first message. The slaves all back off randomly, so with high probability, the first slave to respond after that will be the only one to respond. If the other slaves don't blindly rush forward at that point, then there will be a second slave to respond, and again with high probability the only one to respond. And so on.
This process will be slow, but once they have their addresses in EEPROMs, it doesn't need to occur again until a brand new device is added to the array.
For this some software retry scheme will be required.
Yes, as long as the collision can reliably be detected by *all* the colliding parties. If so, then random back-off would work, even if it had to be repeated until it did. It all depends on the Arduino's I2C library ability to handle collisions in a clear and reasonable way.