Teletype I2C protocol

[scanner_darkly]

somebody asked for a description of the protocol so i put together a wiki page: https://github.com/scanner-darkly/teletype/wiki/II-protocol

would be good to add a description of the hardware side of things if somebody wants to take that on!

[Galapagoose]

Thanks for doing this @scanner_darkly! Been meaning to throw some extension ideas at you, and talk more about the co-existence of multiple leaders on the bus. Soon!

[desolationjones]

Is the Teletype hardware open source in any fashion? I don’t know that it needs to be for such standard things as I2C but I find myself curious about the hackability of the hardware…

[scanner_darkly]

the hardware is not open source, but if you just want to hack something together to utilize i2c there are much simpler ways to do it. also take a look at @bpcmusic’s telex which is open source (both firmware and hardware).

[mdoudoroff]

Just learned that the forthcoming Sinfonion (monster quantizer) from ACL has an i2c port. Maybe some interesting potential there?

[csboling]

In working on and discussing a TT op for changing which app Ansible is running, I realized that trying to guess which app is running on a follower in order to address it is pretty error-prone, and I think this might benefit in some ways from being a universal op/broadcast command. This is a bit of an odd one because you would only want a specific module to respond to it, but that module might be running multiple firmwares with different I2C addresses. The design problems to solve for this to work include:

• each app has to have a unique identifying number, so that the command can specify which app the target module should switch to
• each piece of hardware on the bus would have to get assigned an identifying number, so that the command can specify which module should change to another app.

One way you could accomplish the second one is with another broadcast command reserved for “roll call” - TT/Crow/another bus leader broadcasts a roll call command, each follower responds, ideally with something unique and identifying (current i2c address + CPU serial number + name of the device?), and the leader chooses a sequential numbering for all the modules on the bus, notifies the individual devices of the numbering, and saves it to flash. Such a command could be used to implement this:

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.

and this page could show you what number to use when you want to address a specific device with a broadcast op.

[Galapagoose]

I’ve certainly thought about systems like this, as have many of the developers operating in the euro-i2c realm. I think the reason nobody has done this so far is due a number of reasons: large development time, few perceived use-cases, needing to coordinate with other developers to provide an implementation for each device, and then to have all the users do the firmware update.

Wow! I was 100% not trying to dissuade you! Rather, trying to say it’s a great idea, and if you have the passion to make it a reality, I think ‘roll call’ would be a great feature. I think there are likely a lot of interesting use cases we have yet to identify that would be possible once network-discovery is available.

[scanner_darkly]

not sure if universal broadcast would work reliably for polling (when several followers reply to the same command). an easier way to do a roll call could be simply to call each known address and see if you get a response. it could perhaps do this on a bootup (assuming it doesn’t add significantly to bootup time).

[odevices]

I just came across this interesting tidbit that might help with Teletype (and 16n) lockups caused by i2c being held by a slave:

https://www.microchip.com/forums/m814828.aspx

Here is the key part:

You only do it on startup and if the bus has hung. Start your timer, zero it on every successful I2C operation and when it times out check the bus. If SCL is high and SDA is low, poll it for longer than the slowest device takes to send a byte. Any transitions - reset the timer. No transitions - abort any I2C operations, disable the MSSP (I2C) peripheral, bitbang the 9 SCL: bus reset sequence, wait and check the bus is free then reenable the MSSP in I2C mode.

Apologies if this has already been considered!

[scanner_darkly]

as this is not really teletype only at this point we should probably change the name for this thread. what should we call it? “monome i2c protocol”?

[Galapagoose]

Not so much a user issue, but I was looking at implementing i2c support on crow for the 16n faderbank, and noted there’s a potential collision between multiple 16n devices & the proposed intellijel tetrapad support.

16n is on address 0x34, and Tetrapad has reserved 0x35-0x37. from libavr32.

16n stays on 0x34 for sliders 1-16, but if you attach multiple 16n devices it uses sequential i2c addresses. So a second 16n, referred to as slider 17-32, will send on address 0x35 which collides with the tetrapad.

Doesn’t seem like a problem now. 1: I’m not sure if the 16n firmware even supports changing the i2c address to respond on 0x35+, and 2: It’s been long enough now, I’m doubtful i2c support is coming for Tetrapad. But just wanted to raise it to whoever the relevant parties are (I’m not sure who that would be).

[scanner_darkly]

here is the pull request with some background on the reserved addresses: https://github.com/monome/libavr32/pull/36

and yeah, it’s easy to change the faderbank i2c address: https://github.com/16n-faderbank/16n/blob/master/firmware/_16n_faderbank_firmware/config.h#L37

@kisielk are there still plans on integrating tetrapad with the monome i2c ecosystem? if so, would it be possible to change the addresses reserved for tetrapad?

---

should we move this to Teletype I2C protocol? probably a better place for it

[kisielk]

The Tetrapad I2C implementation is basically finished now, so I guess we could make it publicly available soon. I’m not sure I understand the question about changing the addresses though?

[scanner_darkly]

is it meant for integrating with teletype and other monome devices, or is it for communicating with tetrapad’s own expander? and does tetrapad act as a leader or a follower?

within the monome ecosystem each i2c supporting device is assigned a specific address or a range of addresses, to avoid conflicts with other devices. there were 3 addresses reserved for tetrapad (so that up to 3 tetrapads could be connected simultaneously). it would be good to change these addresses so we could support multiple faderbanks too. and if we do this we could add another address, so we could support 4 tetrapads (not sure why we went with 3 initially).

[kisielk]

Tetrapad can only be a follower device. I think actually we only need to support two devices, that is all we plan to support with the Tete. Going beyond two the I2C bandwidth starts limiting the performance to below what we feel is acceptable.

I don’t mind changing the address to whatever, since we’re not shipping the Tete for a couple of weeks.

[scanner_darkly]

could you confirm which address are you using now?

[kisielk]

0x2d and 0x2e. 0x2f and 0x30 for the 3rd and 4th, can be enabled on the tetrapad via the jumpers on the back but are currently unsupported by the Tete…

[scanner_darkly]

would it be possible to change them to 0x3B..0x3E instead? i can make a corresponding change in libavr32.

[kisielk]

Ok, done (in 20 characters)!

[forrest]

I love how tightly-knit this modular community can be…