ok so i did this a bit.
for sure the TWI peripheral in the avr32 performs arbitration correctly. page 236 of the datasheet is extremely informative:
most relevantly, there is an
ARBLST bit in the status register that the user is supposed to check after each attempted write. when arbitration is lost, the peripheral saves the data that would have been transmitted and sets that bit. so far so good.
but, looking at the TWI module in the ASF (
twi.c), the C-language support seems incomplete. there is a
TWI_ARBITRATION_LOST error code defined, but it’s never used and …AFAICT… the relevant status bit isn’t checked (i could be missing something.) so i don’t think it will work “out of the box” without adding to this driver.
looking at this stuff, (and for whatever reason it’s been bugging me today), it is all coming back like a bad dream. the problem with multi-leader is that checking the arbitration-lost state is inherently unreliable, because it relies on detecting when SDA is low but should be high. with the open-drain design, it’s all too easy to have a spurious false negative, due to integration times, wonky levels, &c - it works fine if you are just waiting for rising-edge interrupts on SCL/SDA, but there’s a good chance that SDA won’t quite be high enough at the exact moment when you read it after a write.
so when you do try and correctly perform lost-arbitration behavior, you open up a huge headache in the form of this error condition where the leader keeps giving up on writes because of spurious lost arbitration. this is why you get ugly kludges like the
i2c_t3 library “bus reset.”
also, the odds of this feature working perfectly are much worse when you have an ad-hoc network of devices connected by DIY cabling and who-knows-what bus terminations…
so long story short, i’m skeptical that a multi-leader system can be reliable, and it’s not going to happen without some work on pretty much every platform. (which doesn’t mean it’s not worth trying.) in real systems, i have never seen it - there is always a workaround involving multiple potential leaders using some message protocol on the broadcast address to figure things out. (that’s probably all i can say without getting into protected IP danger zone.)
it’s been said but i’ll emphasize: this kind of discussion is necessary exactly because the i2c spec is not a law of nature and implementations diverge. in fact the very first post is about the fact that avr32 devices have a more limited address space than the 10 bits dictated by the phillips/NXP i2c spec.
there’s a historical reason for this particular mess: i2c is not a public standard, and phillips tried to monetize it through licensing in the 80’s and 90’s. many manufacturers, including Atmel, chose to inplement very similar but not identical protocols that are typically subsets of i2c by a different name - Atmel calls theirs TWI for instance, but it is the same thing in most respects.
so, this is how we navigate this perplexing territory: by sharing our real-world experience. which, taken collectively, is actually kinda extensive by this point…