Handle "special-frames" with EInkDynamicDisplay #3356
Conversation
responds to meshtastic#3339 (comment)
|
This does the trick for the T-Echo. It now shows the boot screen and the “Sleeping…” screen and all looks good. However, on the Wireless Paper v1.1, it seems to not properly perform the fast updates anymore. It looks like it doesn't properly erase the pixels, see the picture below.
When it does the full refresh, it is fixed, but immediately the next frame after a fast refresh is already garbled.
|
|
@GUVWAF Wow thanks for catching that! I think what has happened is that you might have built the meshtastic/GxEPD2 dependency, which hasn't yet merged meshtastic/GxEPD2#6. Just for the draft, I'll point it at the fork again, but I must remember to revert this before merge. The reason this upset Wireless Paper v1.1 in particular is that in order to standardize the post-update code, a few lines were moved from the firmware repo, into the GxEPD2 repo. It's a good thing though that this did come up, because it highlighted two other issues that should now be resolved:
Thank you for all your help with testing! If you do have the time, it would be great to hear if the code runs properly now on your hardware. |
Oh, you’re right. I did change it for the T-Echo, but not for the Wireless Paper -- my bad. After applying it, all works well. Thanks! |
* Move Wireless Paper V1.1 custom hibernate behavior to GxEPD2 * Async full-refresh for EInkDynamicDisplay * initial config for T-Echo * formatting responds to meshtastic#3339 (comment) * increase fast-refresh limit for T-Echo meshtastic#3339 (comment) * change dependency from private repo to meshtastic/GxEPD2 * rename setFrameFlag() method * move storeAndReset() to end of update() * change order of determineMode() checks * add init code as a determineMode() check * add BLOCKING modifier to frameFlagTypes * add frameFlags to LOG_DEBUG() messages * function macro for tidier addFramFlag() calls * handle special frames in Screen.cpp * fix fallback behavior for unmodified GxEPD2 Issues exposed by meshtastic#3356 (comment) * while drafting, build from todd-herbert/meshtastic-GxEPD2#async * reorder determineMode() checks * Swap Wireless Paper V1.0 dependency to meshtastic/GxEPD2 * purge unused enum val * refactor: remove ACKs in range tests so zero hops is honored (meshtastic#3374) * fix heap use after delete (meshtastic#3373) * fix of tryfix SHT31 sensor (meshtastic#3377) * Don't spam logs if no position with map reporting (meshtastic#3378) --------- Co-authored-by: Todd Herbert <[email protected]> Co-authored-by: Ben Meadors <[email protected]> Co-authored-by: Thomas Göttgens <[email protected]> Co-authored-by: Andre K <[email protected]> Co-authored-by: Manuel <[email protected]> Co-authored-by: GUVWAF <[email protected]>
Aim
Create custom behavior for certain important UI frames
Key changes
BLOCKINGflag: option to block execution while refresh completes.The flags set in Screen.cpp are largely stylistic choices. Please feel free to suggest any alternate behavior that you would prefer, or any additional behavior you would like added.
Hopefully these changes address the issues identified in #3339 (comment).
@GUVWAF, if you have the time, please do let me know if there has been any improvement (and if it's ready for merge), or if there's anything that could still use attention.
Known issues:
If Async Full Refresh GxEPD2#6 has not yet been merged, you may need to temporarily change lib_deps to point at https://github.com/todd-herbert/meshtastic-GxEPD2#async
Some Screen class methods (such as
setWelcomeFrames(),setSSLFrames()) do not seem to serve any frames to the display class. I'm not sure whether this is just the current situation, or a new issue to look into.When waking from sleep, there is a gap of ~10 seconds between display init and the first frames being served to the display class. I'm not sure whether this would be considered something to explore, or just a normal part of start-up.
Diagrams:
To reduce future headaches. Diagrams are only an outline.