@sam I don’t think it has been sufficiently and successfully tested yet to be able to say reliably this.
Are you saying this from an empirical rather than a theoretical point of view?
The theoretical point of view is that this is how I understood the new bus board thread: as a proposal that probably will fix the issues but is not yet tested. Plus there seem to be differences in working with a lot of TX modules vs. a few of the original monome modules as the @bpcmusic’s testings suggest.
The empirical part would be that i2c is supposed to work reliably with four modules on the bus but does not for me, while it generally does with two Ansibles.
So I am not sure if it is fully understand how those pull up resistances have to be set and contributed. And if they fix all of the issues or if there is something left to do in the code. I hardly understand anything of all this and my impression comes solely from common knowledge and the experience that we have been on several “it should work know” points by now.
All this is not meant to be rude - I know I might sound like that sometimes. It is just very important to me to have the ecosystem in a stable working condition. So I am a bit afraid that we might overlook something as it had taken a while until the i2c issues have been taken seriously and tracked down that far as they are now, which is great!
1 Like
IMHO, go ahead and land it. If it turns out that there’s more to the issue than the pull up, then reverting to the current revision in github for further investigation is always an option.
2 Likes
you should be able to go ahead.
i just pushed libavr32, with pullups/etc disabled-- this is what we want.
I think I’m going to get the PR opened. Even if it’s not merged immediately. Mainly I’m worried about it starting to bit rot if too many other changes come along. It shouldn’t really affect the i2c stuff anyway as it’s all on the programming language side of the teletype rather than the hardware side.
@bpcmusic given the monstrously large pull values that the teensy has, have you tried running the i2c bus at 400kbs (or higher)?
3 Likes
avr32 is limited to 400kbs so it won’t go higher, but it’d be great to test at this speed with a full bus!
1 Like
@sam - the teensy can go way beyond the 400kbps rate, but I’d locked them all to that in their config during our initial bus testing to rule out the auto-negotiation as a factor. I haven’t measured the real-world rate in any scenario. All I know is that, with the appropriate amount of pull-up, the thing is still screaming fast!
@Leverkusen - from the perspective of the expanders, this isn’t a code issue anymore but one of having the appropriate amount of pull-up resistance for your bus to counter its length past the 4ish devices that the current bus configuration supports.
@tehn’s new bus board should solve it quite nicely for larger configurations as my TX firmware hack really only got things into grenade range.
2 Likes
@bpcmusic I’ve rad this a few times now and I seem to not understand it right - does it mean 4 modules connected to teletype should work or 4 modules as in teletype and three other modules?
I haven’t tested the combinations of various modules to identify where the breaking point is. Different modules, lengths of cable and other details may play a part in where someone will need additional pull-up on their bus. Best I can suggest is to experiment with your own configuration.
For larger configurations, get/make a bus board and you will be off to the races!!
From reading through your issues across the different threads it seems like you would definitely benefit from the new bus-board / mezzanine / resistor-mod. I know you’ve had issues with Earthsea which I don’t think this will solve, but I believe it will help with your issues involving Ansible.
1 Like
Thanks for the confirmation - I ordered the v1 of the v2 busboard and will try it out.
1 Like
I tried the new bus board with the pull pup resistors but it does not solve the issues I have.
Instead teletype does weird things now as hanging outputs (not the ones connected to i2c but its own CV and trigger outs) and display errors.
I am not sure which firmware I should use now with the bus board. Official is 1.4.0 but there seem to be different 1.4.1 versions around.
Can someone point me to a teletype firmware that is supposed to be the one that works with the new bus board?
the bus board is certainly not causing new issues. it’s likely just revealing other issues now that the i2c is working on the electrical level.
i’m sidetracked with a few other priorities before i’ll be able to check back into the state of TT.
1 Like
(continuing the discussion from [another thread][thread])
[thread]: Ii bus board, v2, with pullups)
Looks like we’ve got another i2c bug that needs fixing, as discovered by @trickyflemming, I think @Leverkusen has also confirmed it too.
Minimal failing example:
Scripts 1 through 8 are empty.
#I
M 50
M.ACT 1
#M
TO.TR.PULSE 1
Connect a fast trigger to input 1. The M script just needs to send a packet out over i2c, so it could also talk to Ansible or a non-existent module.
I’ve posted some theories on the [other thread][thread], but let me repeat them here:
Tagging: @tehn @scanner_darkly @bpcmusic, I’m not set up for debugging i2c…
2 Likes
Quick question: is it any i2c command in the M that will cause the problem? In other words, would TR.PULSE 5 also cause the problem (with no Ansible)? Accurate, @trickyflemming?
@trickyflemming tried the following scenarios out for us
- Pulse TXo
#M
TO.TR.PULSE 1
- Pulse non-existant TXo
#M
TO.TR.PULSE 9
- Pulse Ansible
#M
TR.PULSE 5
All 3 fail with a trigger connected to input 1, and work if there is no trigger.
I don’t know if he explicitly tried a non-existent Ansible output. Or even one of the older II commands. Would be worth a quick go if someone has the time.
1 Like
I can confirm the minimal failing script. It runs for over 30 minutes and crashed after 1 minute twice when a trigger gets patched in.
I sometimes experience little hickups in the script when I switch from live to edit mode and back. Also are the hickups on saving scenes expected normal behaviour? Probably yes as the other modules show them too.
Cannot say anything about the regularity of the display glitches yet. Of course when I had the new bus board freshly built in I tried a lot of i2c stuff with M and triggered scripts. They are a bit harder to find though as you have to change the display view for getting them - not just start a script and wait for the crash while doing something else.
2 Likes
just a quick note to say - i’ll be traveling for the next 4 weeks, so unfortunately won’t be able to help until i’m back (traveling super light, so no monome gear with me).
from the description does sound it could be a new bug…
@tehn @sam @trickyflemming @Leverkusen
Ran the script for over an hour with triggers patched. Totally stable for me. Even added corresponding trigger pulses on the TT’s triggers for the script and turned on the TX’s pulse divider to make it more complicated. Solid.
Sigh. Kinda wish it would have locked up - at least things would be consistent.
I have 4 TXo, 2 TXi and 1 Ansible connected to the Teletype.