screen glitching and redraw prioritization

[tehn]

screen redraw needs optimization

partial redraws moving between edit and tracker, for example

[samdoshi]

@scanner-darkly has a fix for this in libavr32, it was done for Earthsea (maybe?). The Teletype code just needs updating to use it.

Maybe @scanner-darkly and @burnsauce can coordinate to get the changes in?

[samdoshi]

Added some comments here: https://llllllll.co/t/new-teletype-operators-and-features/9076/191?u=sam

[scanner-darkly]

there were changes made both in libavr32 and teletype.

the libavr32 changes were merged into the master already: monome/libavr32@7170c9a

these changes include:

• changing trigger priority from 3 to 1. the most important part here is to leave i2c as the only thing with priority of 3 so that trigger and timer interrupts do not interfere with it. i2c implementation is brittle and doesn't recover well. also imo timers should have higher priority than triggers (but we could set them both to 2 or 1 too - up for debate).
• reducing i2c speed - don't remember why i did it, possibly it showed improvement in stability without affecting the i2c speed too much.
• timers_pause / timers_resume replaced with irqs_pause / irqs_resume. previous implementation assumed both trigger and timer IRQ levels would be disabled at the same time which is not necessarily true.
• SPI writes protected with irqs_pause / irqs_resume including screen.c. this is important for removing screen glitching. but perhaps a better way to go is for SPI updates to use their own queue...

teletype changes are here: scanner-darkly@c47eaaf

they include:

• libavr32 updates - i believe these are the same updates as above (i used my dev branch in libavr32 for experimentation, and then i cherry picked commits into the stability branch which was merged into master)
• SPI writes protected with irqs_pause / irqs_resume
• keyboard, front button and screen refresh handlers are called from the check_events loop instead of relying on timers. this was the main improvement for responsiveness.

testing: with @samdoshi official 2.0 i still managed to lock it reliably and quickly with extreme scenario (10ms metro, audio rate triggers, lots of i2c reading and writing in metro). with the above changes i wasn't able to get it to crash (i ran it for over 40 hours).

[scanner-darkly]

for screen/keyboard responsiveness we just need to update teletype, for i2c stability both teletype and trilogy/ansible will need to be updated.

[scanner-darkly]

forgot to add, my change was essentially a super simple implementation of having a higher priority queue for screen/keyboard updates. i think @burnsauce had some ideas on how to do this as well.

[burnsauce]

Yeah, I'd like to create a proper scheduler to handle as many of the teletype's jobs as possible with predictable performance and timing for critical functions.

[tehn]

perhaps we should do an intermediary (say 2.0.1) release that fixes this prior to the 2.1 feature burst? i can attempt this today.

…

On Wed, Sep 13, 2017 at 7:13 PM, Poindexter Frink ***@***.***> wrote: Yeah, I'd like to create a proper scheduler to handle as many of the teletype's jobs as possible with predictable performance and timing for critical functions. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#97 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPEcE-d1ai0uibRWTxHVQhbeirdrIfqks5siGGUgaJpZM4PWGM_> .

[burnsauce]

2.0.1 did indeed solve this problem, so the issue can be closed.