#14

Sure - I’ll coordinate with Brian at Orthogonal. Let’s also coordinate on that beta as some things will need to change on the TT side to use any renamed defines.

1 Like
#15

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.

1 Like
#16

faderbank and ER-301 code would be trivially affected.

#17

i’ve added your changes to my PR, can you take a look when you get a chance? (once it’s merged i’ll do a PR for the er-301 change).

#18

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.

#19

it’s to control some midi and arp parameters on ansible in midi mode from teletype. you can see available teletype ops here: https://monome.org/docs/modular/teletype/manual/#ansible

1 Like
#20

Ok, I see, thanks for your reply! maybe not I’m looking for but I will read the manual of Ansible :wink:

#21

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!

4 Likes
#22

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!

7 Likes
#23

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…

#24

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).

1 Like
#25

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

3 Likes
#26

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:

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

3 Likes
#27

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.

3 Likes
#28

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).

#29

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! :bowing_man:

6 Likes
#31

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”?

1 Like
#32

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).

2 Likes
A user's guide to i2c
#33

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

1 Like
#34

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?