#75

So those stacks aren’t what you think.

STACK_OP_SIZE defines the maximum number of commands you can add to the S mod.

STACK_SIZE is how large the stack can grow inside the teletype language. 8 is plenty. e.g. L 1 8 : TO.TR.M I MUL I X will firstly use multiple different stacks, one for the PRE and one for each run of the loop. Loops from L are processed sequentially, not concurrently. In the given example the stack will never get larger than 2. The actual stack is defined in the linker script and is 8kb.

You’re right that there is an issue between the i2c code and triggers / M scripts. A few options (a.k.a. a bit of brainstorming):

  • The i2c code is not ‘thread safe’ enough. Maybe there are some critical bits that need masking from interrupts.

  • Possibly an issue with messages being sent and received out of order.

  • Long running code in an interrupt (which will be masked by default?) causing the i2c internal rx or tx buffers to overflow

  • Too many long running processes (e.g. i2c) which lead to the event queue overflowing or generally fubaring.

More simplifications if possible, can you try the following 3, all with empty scripts 1-8, but a fast Varigate trigger into input 1.

The I script is the same for all of them:

#I
M 50
M.ACT 1
  1. Pulse TXo
#M
TO.TR.PULSE 1
  1. Pulse non-existant TXo
#M
TO.TR.PULSE 9
  1. Pulse Ansible
#M
TR.PULSE 5

If you remove the trigger do the crashes stop?

2 Likes
Teletype Firmware i2c Debugging
#76

I finished my powered i2c bus board tonight. Together with a simple one trigger to four random CV’s on output 1 - 4 this crashed within a minute:

I have two Ansibles, ES and MP connected. When I started the Metro script Ansible was not in the right mode, which was no problem. I switched it to telepepe output mode then and it started to blink. But not for long.

I also have a lot of display errors with truncated lines. Like this:

IMG_4275.JPG2448×2448 793 KB

:cry:

#77

Just ran all six scripts.

For all three with the cable inserted: failure.
For all three without the cable inserted: stability.

From all of these tests, I’ve noticed we have a set of three things:

  1. External triggers (i.e. gates plugged into the TT from other modules).
  2. The M script.
  3. Anything ii related.

Right now, any two of these co-exist peacefully on my TT. The moment all three are in action, I experience a lock-up within 5 minutes or so.

Teletype Firmware i2c Debugging
#78

I can also report that the issues have changed a bit.

What I experience is that outputs get simply inactive while the whole system keeps working.

For example Ansible stops emitting CV changes transmitted form teletype but the trigger outputs still work as expected and patching in the grid still switches to kria. But no response on CV changes via scripts or in live mode. When I change the output numbers in the script from CV 5,6,7,8 to CV 1,2,3,4 while the script is running and repatch the four cables from Ansible CV to teletype everything is working again.

I also experience something like this on the teletype outputs occasionally, e.g. a trigger output just stays on and does not react to any commands.

It seems to me that this occurs with the newly build bus board but I could imagine that it is about the teletype firmware and I just did not use it that much while I was waiting for me building the new bus board.

#79

I concur with this. Sorry for not helping with the testing myself, but my Teletype is currently out of my main case and has no other modules alongside it. I’m going to move this over to the Teletype Firmware i2c Debugging thread and tag various people as this is almost definitely a software bug in the i2c implementation.

@Leverkusen are you too only seeing the display errors when using triggers and an M script that transmits over the i2c bus?

Also is the display corruption happening all the time or just when using i2c? (fyi, display corruption like that is usually caused by memory corruption, which may be indicative of the type of i2c bug we’re dealing with). @trickyflemming have you seen any display artefacts like that?

#80

I’ve experienced this as well. You can see it in the video I shared the other day on the expander thread; the ansible should be mirroring the CV values for the teletype - but at some point the CV became frozen while the triggers continued to function:

I’m assuming this is an issue in the Ansible itself and not the Teletype as all other i2c messages are still reliably transmitting.

@trickyflemming and @sam - apologies as well for not testing myself. I’m in Argentina for business through tomorrow and have been away from my TT to try your scenarios. It looks like you have done an excellent job of narrowing down the issue. I’ll work to replicate when I’m back in town. :slight_smile:

#81

Hi all. This seemed like the best thread.

I find myself needing to make some II bus board cables that are “just the right length”.

So I need some 2x3 2.54mm pitch IDC connectors right?

Like this one: RS-Online?

And also some 1.27mm pitch 6-way flat ribbon cable? I’m going to buy some 16-way for use in other projects. It’s easy enough to reduce down to 6 cables right?

2 Likes
Source for TT I2C Cable?
#82

both correct. ribbons separate quite easily.

1 Like
#83

Yay, got my cables made!

I’ve got the following II cables and an unpowered bus board if anyone wants them?

ii_cables.jpg1024×768 138 KB

Free to anyone who wants them in the UK, or anywhere where it won’t cost too much to post.

edit: cables and bus board gone

1 Like
#84

I’m about to order a set of V2 bus board PCBs if anyone else in Boston needs one.

Also, does teletype plus the bus board still fit comfortably in the isms case? I assume so, but wanted to confirm. Thanks for everyone’s hard work!

#85

absolutely, it fits just fine

1 Like
#86

Apologies for necroposting, but: I am about to put an order into Oshpark for PCBs for these (along with boards for https://www.whimsicalraps.com/pages/slashes and some other goodies). My Teletype network is starting to grow.

Oshpark has a minimum order of 3 PCBs, so I will have 2 extras on hand. I’m happy to build out and ship the extras if folks are willing to split boards, components, and shipping.

This would more be a labor of love than a business proposition, especially as I am an amateur DIY builder - competent enough, but I would not sell my builds for profit :slight_smile: So, let’s say I would build a limit of 4 boards maximum, if there is even that much interest. More than that and it starts to become work.

Alternately, if you would just like a single board, I’m amenable to that too, though it’s probably more cost-effective to get Oshpark to make them for you and to have the spares.

PM me for either if there is any interest. Thanks!

(Mods, let me know if this belongs in Trade and I can put it there instead, but this is definitely a zero-profit endeavor, including free labor.)

1 Like
#87

Are 5 modules enough to cause the problems the pull up resolves? I have 2 W/, 2 JF, and an Ansible.

Looking specifically to test bus boards I’m building, so I would want to have a reliable failure scenario to be sure the boards are working.

#88

I think the problem is intermittent in its nature: too much load on the bus leading to missed commands? that’s only coming from my reading on here though

#89

Yes. I recall three units to be the number one should get a powered busboard.

Edit: some background in this thread Teletype Firmware i2c Debugging

#90

Is anyone offering an iiBackpack or something similar for sale? I’m planning on having a Teletype connect to four different devices in the near future. I see that bpcmusic has in the past but is currently out of stock.

#92

You all are awesome, thanks for the offers! Looking forward to getting one in the near future.

#93

(just needed to tell someone/anyone who might appreciate it)

Just built my first DIY: a teletype backpack! and it works!

16n fader next…

3 Likes
#94

Are these available anywhere?

Looking to do er-301 + teletype + just friends + possibly the faderbank and or mannequins w/
at what point would I likely need this? Could I do the first 3 with just a single cable possibly? Sorry for the newb questions

#95

check this out: A user's guide to i2c

likely fine with a single cable, worth a try first.