#146

not all the SPI code (i think there are other calls elsewhere) but i did move the screen refresh and the CV refresh code out of the timer callbacks / event queue. i think iā€™ll move CV refresh back to the timer callback though - itā€™s set to run every 6ms, and itā€™s probably the most timing critical code, so the event loop is not a good place for it since an event can in theory take longer than 6ms.

it shouldnā€™t affect i2c anyway - timer interrupts have lower priority than i2c interrupts.

in what way? any specific issue? iā€™m running my tests with ansible firmware updated to my version of libavr32, i can test if the issue is still present.

1 Like
#147

Nothing specific, just from my experience of it and from various threads. I guess thatā€™s what I meant by ā€œanecdotallyā€.

#148

yes, in my initial testing updating teletype firmware made it more stable unless ansible commands were used - if i added any ansible commands it would still freeze pretty quickly. this was while using the official ansible firmware.

all my latest tests are done with ansible updated with my latest libavr32 and it seems much more stable now. but itā€™s entirely possible there are still some outstanding bugs in i2c code in ansible that are not libavr32 related.

1 Like
#149

here is a short video showing improved screen refresh and keyboard response - this is with a 2ms metro script and 4 triggers getting hit at audio rates - previously this would make it sluggish to the point where you could hardly type anything (which made it difficult to get out of this state as it would be difficult to change the metro rate):

2 Likes
#150

update:

with the latest fixes to improve screen and keyboard response i broke USB read/write, made some additional changes and was able to fix it. also moved CV updates back to a timer callback, which introduced issues with screen refresh again, so i went through all the SPI code and protected it with irqs_pause / irqs_resume which seems to have fixed the issue.

the latest code seems fine so far and iā€™ve been running an extreme test for almost 17 hours now with no crash.

at this point i donā€™t anticipate making any further changes, so my plan is to incorporate all the latest changes from the official 2.0 branch (including telex updates) and post beta versions for testing next week.

2 Likes
#151

Anyone fancy trying to calculate how many milliseconds it takes to send a full screen refresh over SPI?

It might be useful to know.

:smiley:[quote=ā€œscanner_darkly, post:150, topic:7564ā€]
at this point i donā€™t anticipate making any further changes, so my plan is to incorporate all the latest changes from the official 2.0 branch (including telex updates) and post beta versions for testing next week.
[/quote]

Donā€™t forget to post betas for everything if you keep the i2c speed change!

1 Like
#152

yep, my plan is to post tt/ansible/trilogy firmwares all updated with the latest libavr32, not just for the i2c rate update but there are other changes as well that are important (most critical being the i2c interrupt level). anything using the older version will still be able to cause a crash.

3 Likes
#153

@sam - all the latest changes are on github btw if you wanted to take a look! and i moved irqs_# methods from conf to src.

https://github.com/scanner-darkly/libavr32/tree/dev
https://github.com/scanner-darkly/teletype/tree/dev

2 Likes
#154

Looks interestingā€¦ particularly the changes to check_event. I do think trying to find a better solution to the SPI issue than masking all interrupts might be worth exploring (but I donā€™t have the time to do it, so feel free to ignore me!).

Will try to digest once Iā€™ve got rc1 out the door on Monday.

Are you going to squash the commits down before the PR? I take it the plan is still for this to make it into 2.1 right?

Youā€™re going to have a lot of work coordinating the release of new code for all the modulesā€¦ :cold_sweat: I feel for you.

(Wonā€™t you need betas of TXi and TXo too? And JFā€¦)

1 Like
#155

a better solution for SPI would probably be a queue for SPI updatesā€¦ but really not sure what is the best approach. at this point iā€™m just happy to have improved stability but this definitely needs more extensive testing with different scenarios and testing how well CVs are updated specifically, including slews (my latest extreme test has slew enabled on one of the outputs, btw, just to check how it affects stability - i think at this speed it doesnā€™t really have a chance to actually slewā€¦).

yep, the plan is to beta test this separately from your 2.0 firmware - iā€™ll make sure any changes in your branch are merged. and then this can be released as 2.1 at some point likely including some other stuff - i also have some things in mind i want to add :slight_smile:

not sure about JF - TXi and TXo code doesnā€™t use libavr32, and so far doesnā€™t seem to cause any issues (another interesting thing to do would be compare i2c implementations between telex and libavr32 but iā€™ll leave that to somebody else i thinkā€¦)

1 Like
#156

:smiley:

Donā€™t you need to change the i2c rate though?

#157

i had ansible at 132000 and tt at 100000 at one point and it didnā€™t seem to cause any issues. i doubt the i2c code negotiates the rate so probably has to be adjusted in the code, iā€™ll check where itā€™s set in telex.

1 Like
#158

For the TELEX, it is set at 400k in the code - but the Teensy can do a lot faster.

This is the library that I used - optimized for the Teensy and based on the Arduino Wire library:

https://forum.pjrc.com/threads/21680-New-I2C-library-for-Teensy3

I donā€™t think we will need to do anything to the rates due to the nature of the protocol:

1 Like
#159

now i remember you mentioning 400k before - this is interesting, when i tried 400k it was much less stableā€¦ but perhaps only the rate set on i2c master matters?

#160

ā€¦ the latest extreme test has been running with no crash for over 24 hours now.

2 Likes
#161

i let it run for almost 54 hours before finally turning it off - no crash! at this point i feel itā€™s ready for beta testing but it makes sense to wait for 2.0 to be finalized as there are still some changes being made there and i want to make sure theyā€™re all incorporated before we start beta testing this version.

if anybody wants to give it a try now though this would be super helpful. iā€™m also including updated ansible firmware here - it is important to update both as the older ansible firmware can still cause teletype to crash!

same for trilogy - if you use the latest official firmwares they might cause issues when using remote commands. iā€™ll post updated versions for each when we start beta testing, if youā€™d like to try it now just let me know and iā€™ll send you whichever one you need.

what to test? just try everything, throw anything you want at it. if you get it to crash itā€™s not necessary to retry it with the official 2.0 version - just post the description of your setup and the script (although if you have scripts that donā€™t work with the official version but work with this one please post that as well - itā€™ll be good to have additional confirmation that the fixes actually do work!)

teletype.hex (327.8 KB) c47eaaf

ansible.hex (225.1 KB) 85184e4

the teletype firmware includes all the latest changes to the official 2.0 version as of today (dedicated keys for pattern and live pages). remember that flashing firmware deletes your presets!

3 Likes
Is it normal for ansible to freeze after a lot of arc activity?
Is it normal for ansible to freeze after a lot of arc activity?
#163

How do both the Ansible and the teletype firmware versions proposed above relate to the teletype beta / release candidate published by @sam today here:

And the fixed Ansible 1.5.1.b01published by @tehn here:

?

I am getting lost a bit what to install and test nowā€¦

#165

to expand a bitā€¦

@samā€™s and @tehnā€™s versions you linked are the latest official beta versions. at this point we should concentrate on testing those versions. the ones i posted here are only for people willing to try my fix for teletype crashing under a heavy load (such as audio rate triggers or i2c commands in a fast metro script, for instance). my fix also includes improvements for keyboard response and screen refresh.

if your teletype doesnā€™t crash with the official version iā€™d use those versions. if you can get it to crash and have the time and desire to try my version this would be very helpful - but i am not asking for beta testing my version yet - i will do this once 2.0 is officially released. when that happens my version will include everything from the latest official versions and will likely include other stuff so that it can be considered 2.1 and will be tested as such.

for those who want to try the versions i posted - both ansible and teletype include everything from the official versions as of today (teletype rc1 and ansible 1.5.1b01).

3 Likes
#167

this is great - thanks for testing it! are you using the latest earthsea version (posted in the earthsea lock up thread) or the one i posted earlier in this thread?

1 Like
#170

excellent, thanks again for testing! the reason i asked about the version - there were some additional changes since the version i posted here but sounds like they didnā€™t introduce any new bugs, which is good.

re: loop mode affecting start/stop - not sure about this one and i donā€™t have my es connected to i2c yet, so canā€™t test, perhaps somebody else can comment if this existed before?