E-Ink "Dynamic Partial"

[todd-herbert]

The other issue to include in discussion is the need for a full update to be includes after so many partial updates - e-ink displays are not meant to be partially updates for ever.

#3075 (comment)

What it is

Selects between full refresh, partial refresh, and skipped updates, balancing urgency and display health. Non-intrusive, disabled by default. Implementable for individual boards.

How to implement it

For individual boards

1. Configure in variant.h

#define USE_EINK
#define USE_EINK_DYNAMIC_PARTIAL
#define EINK_LOWPRIORITY_LIMIT_SECONDS 30
#define EINK_HIGHPRIORITY_LIMIT_SECONDS 1
#define EINK_PARTIAL_REPEAT_LIMIT 5

• EINK_LOWPRIORITY_LIMIT_SECONDS: interval between "low priority" updates
• EINK_HIGHPRIORITY_LIMIT_SECONDS: min. interval between "high priority" updates
• EINK_PARTIAL_REPEAT_LIMIT: max. consecutive partial refreshes, before a full refresh is forced

2. Adjust configForPartialRefresh() and configForFullRefresh(), if necessary

These methods are used internally to execute any code required to switch the display between partial and full refresh configurations. The should work out-of-the-box, but any "display specific" code can go here.

In GFX code

Graphics code should suggest that an update is either "high priority" or "low priority". This is considered by the Dynamic Partial code, when determining whether to use partial or full refresh.

• EInkDisplay::highPriority() - subsequent updates are important: show ASAP
• EInkDisplay::lowPriority() - no rush with these ones

For the EInkDisplay class as it currently exists, this pull request has already implemented the required changes.
This is hooked into the existing update display() and forceDisplay() methods:

• updates called via display() are considered low priority - receives one per loop() (?)
• updates called via forceDisplay() are considered high priority

What does it change?

The main selection process is handled by this block, in EInkDisplay::forceDisplay()

#if defined(USE_EINK_DYNAMIC_PARTIAL)
    // Decide if update is partial or full
    bool continueUpdate = determineRefreshMode();
    if (!continueUpdate)
        return false; // Abort forceDisplay()
#else

For the most part, the changes are additions, selected by the preprocessor. One exception is the minor refactoring of the "rate-limiting" code in forceDisplay():

firmware/src/graphics/EInkDisplay2.cpp

Line 131 in 1085b54

if (adafruitDisplay && (sinceLast > msecLimit || lastDrawMsec == 0)) {

Structure has changed from:

if (condition_met)
  doStuff();

to:

if (!condition_met)
  return;

doStuff();

What will I notice?

Probably, nothing. This pull request only enables Dynamic Partial mode for HELTEC_WIRELESS_PAPER_V1_0. Ideally, there should be no impact on other boards.

The hope is that devs will test Dynamic Partial mode on their own hardware, and if the result is good, implement it for the relevant boards; even if only as an interim measure, pending a rewrite of the EInkDisplay class I had seen mentioned in passing.

How is the refresh mode selected?

I will admit, the logic is slightly convoluted. I do believe though that the resulting behavior feels intuitive.

A rough outline:

[markbirss]

@todd-herbert nice to see the display working without line at the bottom like the RAK14000

@thebentern sent me a v1 board and i already flashed your wip tree, just wish it had a i2c port.

[thebentern]

Great work. This is a good approach that we can slowly test out on other eink boards.