#15

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 (libavr32/asf/avr32/drivers/twi.h, 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.)

@corpusjonsey
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…

8 Likes
#16

thank you - i feel like each one of your posts is saving me two weeks of research. really glad we have a thread to accumulate all this info.

2 Likes
#17

Was doing some ref manual scanning, and good news on the STM side is that multi-leader is implemented on the hardware level. The documentation suggests the handling of a lost arbitration is automatic and even if the losing-leader is the addressee of the winning command, it will still ACK and be able to receive. On the library side it’s not immediately apparent to me how such an arbitration loss is handled, but I’m confident it can be dealt with after we have a good test bed for it.

Personally I’m planning to get into the inter-W/ communication over the next 2-3 weeks, so I’ll use it as an opportunity to test a nice closed-system version. I figure getting 2 identical chips (and firmwares) to share the bus is a safer starting point than the full TT ecosystem.

Will report back, but if all fails a broadcast-leadership-request approach seems like a good backup plan.

4 Likes
#18

i was wondering about this, since we’d want to support this case if we go with the push workflow (which i think is still preferable to pull).

so, does arbitration only happen when 2 leaders somehow start at the same time? from what i’m reading, normally devices should be able to detect when the bus is busy (i assume either by tracking a start condition or any activity on the bus until a stop is received). how reliable is such detection? edit: sounds like there are some additional conditions that need to be accounted for: http://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html

i’m thinking, if it’s just the case when 2 leaders somehow start simultaneously, wouldn’t it be easier to address arbitration by both leaders issuing a stop and withdrawing and then trying again after a randomly selected interval?

i think it’s also worth thinking about it within the context of overall reliability, which i guess comes down to 2 scenarios, some device stretching the clock indefinitely due to some bug in implementation - this is probably not recoverable without implementing a timeout in clock stretching in all devices, and some device pulling down SDA and missing the next clock, which creates a problem where it needs to somehow differentiate between a stuck follower and an arbitration in progress. which could also be addressed by a leader detecting it and issuing a stop (which hopefully will reset the follower) and then trying again at a later point.

#19

yes. and as described above, the spec is really quite clever. it assumes the worst case: that not only do two masters start at precisely the same instant, but they send data that is bit-for-bit identical, up to some bit. as soon as the data differs on one bit, or the devices drift out of sync, then the device sending 0 (or the slower device) wins arbitration.

the problem is the gulf between the spec and the real world. b/c of the open-drawin requirement, the unspecified bus termination circuit, potentially long cable runs, &c, i2c clock and data edges are never very sharp. plus, many devices are designed to use either 5v or 3.3v high values. it all adds up to this:

(with variations) being a very, very common scenario.

this general business of “randonly retrying” is hard to get right and has no deterministic guarantees of actually working for every scenario. so engineers are correctly skeptical of such approaches. you could keep “retrying” foerver and if you’re unlucky then your device is stalled.

anyways, i think this is where we’re at so far, please correct me:

  • avr32 fully supports multi-leader arbitration in silicon. but the ASF driver doesn’t support it out of the box, AFAICT.

  • i’m assuming teensy parts also fully support it in silicon, because they are NXP parts and NXP owns i2c! but the i2c_t3 library definitely won’t work with multiple leaders out of the box, and i’m going to go out on a limb and guess that it’s not a simple matter of changing some #defines.

  • sounds like the STM situation is similar. i think most of these libraries just punt on this feature because it’s rarely used, has a lot of failure modes, and is very sensitive to circuit design decisions. (in other words, it’s a tech support nightmare for library providers.)

btw, it looks like ChibiOS has particularly full-fledged support for these features. might be worth taking a look…

1 Like
#20

retrying at a random interval would work with the assumptions that the bus is normally not too busy, each communication is fairly short, and all leaders are capable of properly detecting when the bus is busy. it feels like a simpler way to deal with arbitration than the official mechanism, which i agree is smart in that it keeps the winning communication uncorrupted without the need to resend, but relies on other really smart bits such as the losing leader still being able to respond to a communication that is already in progress (assuming that’s who the winner is trying to communicate with).

i realize though this and smarter ways were likely considered and for various reasons abandoned - and i appreciate you taking the time to offer detailed explanations.

random retrying wouldn’t address hanging devices holding the lines in any case, which i still think is the main problem. i’m much more surprised the above libraries don’t seem to support graceful recovery.

#21

Does anyone know what the I2C pinout is on Just Friends (top to bottom)?
Would be nice to document this somewhere for modules that don’t have it printed on them.

#22

I don’t have the schematic handy, but the pinout is identical to Teletype. White silkscreen stripe is ground. This is the same for W/ and Crow and I believe every device apart from er301 (i think).

To me the teletype (and monome trilogy) pinout is the standard as it defined the protocol.

1 Like
#23

The pins are: gnd, scl, sda on every module by monome, Whimsical Raps, or bpcmusic. The only exceptions to this ordering that currently have Teletype support are the SSSR Labs Matrixarchate and older ER-301s. I don’t know about the Tetrapad. I’ll add a note that this is the ordering on this docs page. Currently this is not linked from the sidebar but only from some other pages. Not sure what kind of sidebar structure makes sense for some of these miscellaneous pages.

1 Like
#24

Was just curious, has anyone worked on a 1u i2c trs on the front, 3/6 pin on the back adapter? Considering adding a 16n to my setup but have nearly maxed out space in my case and just have a bit of 1u space left

#25

Hi peeps,

Now that i want to use i2c, I see i dont have the i2c header on the white whale.

I have been looking everywhere to find some information about how and where to install the header on the white whale. But found nothing.

Can somebody post a picture,of the back of a WW with the i2c header?

Thx

#26
1 Like
#27

Thank you very much 20 characters

Is the alternative orca firmware for WW also compatible with i2c?

#28

yeah it can respond to i2c commands from teletype (see full list here) but it doesn’t sequence i2c followers, if that’s what you meant.

#29

all good info thanks, yes I understood that the WW is a follower and can’t therefore not send but just receive from TT for example.

#30

to be more precise, WW module can be either a leader or a follower, depending on the firmware it’s running (if you use it with polyearthsea or orca’s heart firmware, for instance, it will work as a leader). WW firmware only supports being a follower.

#31

OK, have to check what the commands are then to use ORCA and polyES as a leader. I thought only TT could make commands. Maybe TT is to be used as interconnection . Have to check what I find in the ORCA doc from TT

#32

make sure to check this thread, it has detailed explanations: A user's guide to i2c

basically, there are several devices/firmwares that can act as i2c leaders. each one will have different hardware requirements (see the thread above) and might require additional configuration (described in their respective manuals).

(and specifically, you don’t need to use TT as interconnection but you might need something to provide bus power and pullup resistors, the thread above has the details. also, orca and orca’s heart are different firmwares, the former is a follower, the latter is a leader).

#33

I drilled out a hole to install a 3.5mm trs jack on the back of my case specifically for my 16n connection. But I didn’t add any pins, it’s just the 3 wires soldered to the jack with female headers at the other end. It works great and I just run the I2c cables to my TT back back directly.

2 Likes
#34

Trying to convert (usb)Midi to i2c via arduino to the ER-301
sending triggers works fine:

  Wire.beginTransmission(0x31); // begin transmission to er-301 (0x31)
  Wire.write(0x05); // send pulse
  Wire.write(3); // to channel 4
 
  Wire.endTransmission();

But cant get CV to work, this is the code i tried:

  Wire.beginTransmission(0x31); // begin transmission to er 301 (0x31)
  Wire.write(0x10);  //  cv
  Wire.write(x);  // value?
  Wire.write(x);  // channel?
    
  Wire.endTransmission();