Well it's been a while since I posted. I've been working on another project using a Motor Shield and a IR tachometer.
In the meantime, I've found out a couple of things.
I've been reading the code at Wayne Truchsess' site http://dsscircuits.com/articles/arduino-i2c-master-library.html and http://dsscircuits.com/images/code/I2C_Rev5.zip .
(Note his code references Nick Gammon for the scan of the devices on the bus.)
The code seems to trap one return value (LOST_ARBTRTN) related to bus arbitration. This value is part of the AVR TWI interface, which in turn is the C/C++ front end to the ATMega chip's I2C built-in interface. All in all, it might be a very simple effort to change Wayne's i2c code to let that particular return value through to let the calling code handle it.
I've also been reading the ATMega328p datasheet. There is a section that specifically talks about multi-master arbitration.
The TWI protocol allows bus systems with several masters.
and
The losing Master should immediately go to Slave mode, checking if it is being addressed by the winning Master.
I knew this already from Nick's site, but it clearly shows the ATMega folks designed these scenarios into the chip, i.e. it's not a case of trying to make the chip do something it wasn't designed to do.
A very interesting quote is:
Note that arbitration is not allowed between:
• A REPEATED START condition and a data bit.
• A STOP condition and a data bit.
• A REPEATED START and a STOP condition.It is the user software’s responsibility to ensure that these illegal arbitration conditions never
occur. This implies that in multi-master systems, all data transfers must use the same composi-
tion of SLA+R/W and data packets. In other words: All transmissions must contain the same
number of data packets, otherwise the result of the arbitration is undefined.
To me this means that during those times when the slaves could act as masters, I have to ensure that all the data transmitted have the same length. And to achieve that, there needs to be a very clear start and end to those periods to tell all the slaves they can start transmitting their fixed-length packets.
I know, not much progress, but still, it's looking more possible the more I look into it.
It's also becoming crystal clear that Rob's advice to pick up a logic analyzer is bang-on. Having read all this, I can't imagine trying to debug the code with Serial.println's!
One concern I have come up with is that the random number generator may not be random enough. Using a random number to fake a processor id depends on the first random number coming out of it (after power on) to be different from all the other processor's first number. I haven't looked into Arduino or AVR code to determine how it seeds the generator but it's important for the first number coming out of the random number generator to be ... random. Depending on how it's seeded, it may be ok or this might be a showstopper.
JohnA