#21

I’ve been having my grid lock up when using Ansible. My current theory is that the external clock is somehow playing a part. I’ve reflashed the firmware a couple times, and everything seems to run normally until I started using my Pamela’s workout to clock Ansible. Once it starts freezing, though, I can remove the external clock and it will still lock up it seems. I haven’t tried using my arc yet…waiting on a white whale to get here. Anyways, anyone who has experienced a hardware freeze, have you had an external clock at any point before it froze?

#22

Quite a few users have reported similar behaviour, arc also.

I believe there is a update in that thread which addresses the issue though I’ve not installed it myself yet

#23

Can someone with issues try the firmware linked:

#24

I’ve been a way for a while and lost track again - would it be possible to bundle the latest working firmwares somewhere so everyone knows what the latest improvements are, which firmware should work and which do fix something important.

As far as I understood there are some firmware versions around that work better but need other modules to have similiar adjustments? I can’t follow the tech talk threads where they are spread.

#25

I will try and post a version of Ansible with the same underlying library changes that Teletype 2.0 has, later on today. Once that’s been tested I will tag it as 1.5.1 and call it a release.

In the interim, if anyone get’s a chance to try the version linked above that would be helpful.

To the best of my knowledge the issues with grids needing reconnecting is the same issue that Teletype had with it’s keyboard. In theory all the modules are afflicted with the same bug. Essential each time an external trigger occurs there is the possibility that part of the USB handling get’s corrupted (technically it’s the timer code…).

There are some newer changes to the underlying library (libavr32) that @scanner_darkly made, but I don’t have the time to go through those so I will leave that for others to do. Ideally each of the modules should have a new firmware released.

#26

I just updated both my ansible modules with 1.5.1b01
Ran for 1h30 - Kria on one, Levels on another - both clocked externally with irregular clocking.
No problems.
(No Teletype integration)

I’ll report any bugs I subsequently find on this version but so far so good.

#27

it’s up on the releases page now, apologies for the confusion

1 Like
#28

As @Leverkusen mentioned is it worth having a “sticky’d” and “wiki’d” thread with the latest firmware versions listed.

I can get it off the ground, as I have plenty of time for one handed typing.

#29

this was done back in june btw (EDIT: only ES was done, not the others)

perhaps i can write a little script to scrape the most recent version numbers from each repo? in the meantime i’ll do a manual list at monome.org/docs

another tricky thing is that all modules except TT give no visual indication of what version they’re on, so it’s a bit of a guess whether they’re up to date or not.

1 Like
#30

There is also this change to libavr32 that @scanner_darkly made.

As far as I know it’s not included in any firmware yet. @scanner_darkly is that change ready to be cut into all the firmwares?

#31

as @tehn mentions it’s included in the latest ES release, but not others yet. ideally i would prefer to make sure all known earthsea issues are resolved before we apply the change to other firmwares. if we could get more people try the latest official ES and report issues that would help a lot (see this thread: https://llllllll.co/t/earthsea-edge-lock-up)

1 Like
#32

Ah, excellent. I’m glad there is a plan.

#33

Yes, and the files and folders normally do not indicate this either - I have a download folder full of monome related firmware folders and single hex files just called earthsea-1, ansible-2 and so on…

#34

Just for the ones who are less familiar with all those libraries - is it important to have all firmwares fitting to each other now? As in “Don’t install this in case you have the original Meadowphysics module connected to your i2c chain which does not have a modified firmware by now”?

#35

no, they are all compatible. it’s really only important if you have any i2c related issues, or pushing extremes on teletype (super quick metro script / audio rate triggers etc). in this case you want to have all modules updated to the latest version.

it should be clarified there were 2 groups of changes made to the libavr32 library - there were some i2c fixes a few months ago. i believe all the official firmwares should have those now.

then there were some additional stability changes i made in june, only the official ES firmware and the beta TT version i posted a while ago have them right now. at some point these changes will likely go to TT 2.1 (along with improved keyboard and screen response), and we will update all the other firmwares as well.

hope this clarifies things! have you had a chance to try the latest ES firmware? are you experiencing any issues still?

#36

you should be downloading a zip file named ansible-1.5.1.zip which should make a similarly named folder. i don’t see why you should both moving the individual hex files around? just leave them in the folders, if you somehow feel compelled to save old versions.

#37

I think TT 2.0 and Ansible 1.5.1 have the timer IRQ masking fixes too (that fixed USB issues). That was done at a similar time to the i2c changes.

#38

Okay, I see that the zip files are individually named now - they get extracted automatically and I never see them on my system.

The folder then has the first number (before the first point) from the file and then a generated number if it is not the only Ansible-1 folder in the download folder. So actually they are named ansible-1, ansible-1-2 ansible-1-3 and so on. Teletype is now named teletype-2 the next firmware versions will be named teletype-2-2, teletype-2-3 and so on. But this seems to be something my computer does (MacBook, El Capitan). Maybe it just does not bother about numbers separated by points that much.

The individual hex files is what gets posted as trial versions for bug fixes on the forum every now and then. Normally I just shift them into an existing folder and confirm the replace or keep both request with replace to upload them to the module.

I feel compelled to save old versions since it was not always clear which one actually does work or fix a bug and often it seems to be needed to go back to an older firmware to check something or show where it started to go wrong.

You are right about my download folder being a mess though. Now that everything seems to work together it could be time to erase at least all monome related firmware things…

#39

all the old firmware versions will continue to be on github, unless you’re talking about intermediary debug version, which i wouldn’t bother keeping around because we have no idea what code is actually in them.

i can’t explain why your .zip files would automatically unzip that way. on el capitan (as i have forever) i double-click the .zip file and it makes a folder with the same name as the zip.

#40

There’s a setting for this in Safari’s settings, and I think it defaults to “automatically unzip stuff”. :confused: