Closed tehn closed 6 years ago
@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?
Added some comments here: https://llllllll.co/t/new-teletype-operators-and-features/9076/191?u=sam
there were changes made both in libavr32
and teletype
.
the libavr32
changes were merged into the master
already: https://github.com/monome/libavr32/commit/7170c9ab03ab4754197fa91b55bde6e2fb21aadd
these changes include:
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. 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: https://github.com/scanner-darkly/teletype/commit/c47eaaf0cf84b8e1eeb6de63612e2a01cf66c3c6
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
)irqs_pause
/ irqs_resume
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).
for screen/keyboard responsiveness we just need to update teletype, for i2c stability both teletype and trilogy/ansible will need to be updated.
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.
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.
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 notifications@github.com 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 https://github.com/monome/teletype/issues/97#issuecomment-329323027, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcE-d1ai0uibRWTxHVQhbeirdrIfqks5siGGUgaJpZM4PWGM_ .
2.0.1 did indeed solve this problem, so the issue can be closed.
screen redraw needs optimization
partial redraws moving between edit and tracker, for example