Issue #64: Display sometimes gets messed up with Teensy 4

[patrickdowling]

So curiosity got the better of me...
To simulate an app taking longer than the allowed time slot I added a delay at the end of CORE_timer_ISR:

if(!(OC::CORE::ticks & 0x3))
  delayMicroseconds(80);

This immediately produced garbage output on the display so I take that as confirmation of the "misbehaving app => DMA transfer corruption" theory. Even without DMA.

A minimal fix is to make SH1106_128x64_Driver::Flush wait for sendpage_state to be 0 in the __IMXRT1062__ code path. When active, values now run from 1..4 => 0, and the display was stable.

Notes

• "works for me" and I didn't test anything else (especially T4.1) so feel free to put it in some other branch...
• A busy wait in the ISR always was questionable, and volatile always seems icky, but this might be that rare occasion where it's ok (memory ordering doesn't seem critical here).
• A non-blocking approach could be a return value from Flush to exit the ISR early, then hope for better luck next time?

But that might be overthinking since ultimately this is just bandaiding the symptom.

• It'd be good to know when an app is being greedy, even without visible artefacts the timing is out of whack.
• The ISR gets profiled anyway (OC::DEBUG::ISR_cycles) which could be used for a simple "overload counter" or similar (the old school method would be to flash the screen border).
• Apps with extended processing requirements might want to implement the common top/bottom half split and do longer processing the main loop.

[patrickdowling]

For reference #64

[djphazer]

Thank you for this patch! Trying it out now on T4.1, just stress-testing with previously buggy scenarios - seems solid. I'll dig a little deeper with testing later.

I do like the idea of flashing the screen border if/when things overrun, for the sake of development at least. It's a relatively rare occurrence, so I'm not too concerned about timing as long as it doesn't crash... Maybe things that need accurate timing should rely on a different mechanism instead of ticks, and it will be a non-issue ;)

[patrickdowling]

Cool, thanks for testing.

I have a hunch that some apps might benefit (in terms of cpu cost) from calculating blocks of samples (outside the ISR?) but
a) that has tradeoffs
ii) it'll probably make sense to have a KISS overload indicator and get a reading on how often it actually triggers before diving in too deep. I tend to gravitate towards worst-case scenarios 😬

As I write this it occurs to me that a different but similar indicator might be to check if Flush actually has to wait.

[djphazer]

This feels right, so I'm merging for stability. We can worry about profiling it on a rainy day ;)