a thread to discuss and document teletype i2c protocol.
devices/firmwares that currently support it:
white whale / original
white whale / orca
white whale / kria
ansible / levels
ansible / cycles
ansible / meadowphysics
ansible / kria
ansible / earthsea (eventually)
ansible / tt expander (up to 4 devices)
ansible / midi
telex txo (up to 8 devices)
telex txi (up to 8 devices)
w/ (up to 4 devices)
er-301 (up to 3 devices)
matrixarchate (up to 3 devices)
crow (multiple devices?)
i’m listing different firmwares separately, since we want i2c address to be unique per firmware, not per device, to support cases like using 2 ansibles in different modes. that’s over 40 unique addresses.
it appears we’ve been operating with the wrong assumption that the address space is 256 possible addresses - it looks like addresses are 7 bit, so we actually have 128 addresses available. also as i and @bpcmusic discovered, address 0 is reserved as “send to all” (more on this below). one of the questions is - do we want to use any other of the reserved addresses as defined in the specification (0000xxx and 1111xxx)? that’s 16 addresses which still leaves us plenty (but i don’t know how many addresses crows will use).
address 0 - it appears asf already supports it, so we can’t use it for any specific firmware, but we could use it to our advantage to support things like global clock, global reset etc. for such global commands we do need to also standardize/reserve a range, since all followers will respond to them, so if a follower already uses that command for something else it will create a conflict. i propose to reserve a range for such global commands, since we have 256 commands available that should still leave plenty for firmware specific commands (since those wouldn’t need to be unique across all firmwares).
basically, here is what i propose to do:
assign addresses to all supported devices (keep the currently assigned address wherever possible)
fix all the incorrect addresses we have right now (by doing &0x7F) - this will need to be tested
first pass at ii.h. i’ve separated addresses and commands and defined allowed ranges. i’m reserving 64 commands for global commands, which leaves 192 available for each firmware - i think that should be more than enough (i have some ideas for global commands).
in terms of addresses if we convert 8bit addresses to 7bit we have 2 conflicts - faderbank conflicts with the global address, and er-301 conflicts with meadowphysics. @bpcmusic will be updating the faderbank address, and i can change meadowphysics at some point to use a different address (which is easier than changing er-301 i think).
does aleph use any addresses?
all the existing commands are fine as is, no change required.
I remember talking at length with @tehn about why the address 0xF0 for JF ever worked in the first place. In my header for the ii implementation in JF i use #define II_ADDRESS (0xF0 << 1), which admittedly doesn’t make sense. I wonder if JF will already respond to a 0x70 address?
I was of the understanding that the avr32 library put the address in the 7MSBs hence the LSB would always be zero. But then we assigned W/ to 0xF1 and it works as expected, so I’d guess the MSB is being thrown away and we’ve had these collisions already without realizing.
Regarding W/ I had spoken to @tehn about reserving 0xF1 through 0xF4 for future expansion. I don’t have any clear design goals to use them yet, but wanted to keep that option open.
libavr32 specifies it as 0xF0 which is 1111 0000. ASF only uses 7LSB, so the address becomes 111 0000. when it’s transmitted over the wire it’ll take that and append the R/W bit, 0 for W, so the first byte in the transmission will be 1110 0000. which is 0xF0 << 1. so my guess is if we change it on the TT side it shouldn’t require any changes on the JF side. i can test this scenario.
if we apply this theory to W/ then we have:
11110001 - address specified in ii.h 1110001 - address used by ASF 11100010 - the first byte (0xE2)
do you have it defined as 0xF1 << 1 in W/? because then it matches (0xF1 << 1 == 0xE2).
Seems to me ER301 would be much easier to change as the module is still actively being developed.
Does anyone here know if OD is shipping i2c support in current modules? Looks like they’re sold out currently, but unclear if any units have even shipped with support yet (hence a much easier platform to update).
i was considering it in terms of communications required and potential confusion - it’d be easier to offer new versions of mp and tt at the same time than coordinating er-301 and teletype (or answering questions on why a particular version of er-301 doesn’t work with a particular version of tt). although since it’s all pretty new and we don’t even have an official tt release that supports er-301 maybe it’s not so bad (and there is a workaround since we already support 3 addresses for er-301). i’m good either way.
here is the proposal on universal (global) commands: Universal ops
i was also thinking of adding a feature to teletype where it would query all possible addresses and display the list of all the i2c devices that are currently connected. perhaps a shortcut in live screen? this would be super useful when you move modules around and want to make sure all your i2c connections are okay.
would you be able to coordinate er-301 update with brian? at this point i think i’ll just do one final beta which will have the new address, but can’t really say when it’ll be ready. worst case scenario i can create another beta for people who update their er-301.
do you mean faderbank? yeah we’ll need to figure out the sequence of updates.
edit: i think the best way to handle it would be to include the faderbank change in my currently open PR, merge that, i’ll update my tt branch to point to that, and then do a new PR for the er-301 change.
Hi, sorry just a quick question about TT and Ansible via i2c … the first post mentions “ansible / midi”: Is it actually possible to send midi from Teletype via Ansible or is it only Midi to Teletype via Ansible ? Thanks.