"Fast Mode" and clearing

[Avamander]

I have a Heltec 1.54" V2 (BW) that seems to work properly with the fonts example if DEPG0150BNS810 is defined on an Arduino Mega 2560. But for some reason fastmodeOn seems to have the exact opposite effect. Meaning for a proper full clear I have to do:

  DRAW(display) {
    display.fastmodeOn();
    display.clear();
  }
  delay(1000);

Then the display clears the entire contents without ghosting.

2. Is this a display (driver) quirk or nuance of this library's clear()?

So the resulting minimal working code looks like this:

void setup() {
  display.setRotation(PINS_RIGHT);
  display.setFont(&FreeSerifBold12pt7b);
  display.setDefaultColor(WHITE);
  display.setTextColor(BLACK);

  DRAW(display) {
    display.fastmodeOn();
    display.clear();
  }
  delay(2000);
}

void loop() {
  DRAW(display) {
    display.fastmodeOn();
    display.clear();
  }
  delay(2000);

  DRAW(display) {
    display.fastmodeOff();
    display.setCursor(5, 25);
    display.print(millis());
  }
  delay(5000);
}

If I merge the two DRAWs in the loop text starts overlapping (seems to do a partial update only). If I don't do fastmodeOn() in the first DRAW there's always slight ghosting. If I don't do fastmodeOff() in the second block, it displays the previous value and then (with ghosting) the new value on a previously fully cleared display.

What I'm getting at is that I'd expect this to work (draw the new text once in a while without ghosting), but it doesn't:

void setup() {
  display.setRotation(PINS_RIGHT);
  display.setFont(&FreeSerifBold12pt7b);
  display.setDefaultColor(WHITE);
  display.setTextColor(BLACK);

  display.fastmodeOff();
  display.clear();
  delay(2000);
}

void loop() {
  DRAW(display) {
    display.clear();
    display.setCursor(5, 25);
    display.print(millis());
  }
  delay(5000);
}

What wrong assumptions am I making about the display or the library?

[todd-herbert]

What wrong assumptions am I making about the display or the library?

I think the key thing here is that both clear() and fastmodeOn() should be called outside of the DRAW loop.

• clear() is a standalone method, called outside of the DRAW loop, which replaces the display's contents with WHITE (unless changed using setDefaultColor()). Fastmode setting is ignored by the clear() operation; a full refresh (non-fast) is used, in order to reduce the chance of ghosting.

• fastmodeOn() configures the display to use fast mode ("partial refresh") for all subsequent DRAW operations. It should be called before the DRAW loop.

  The purpose of the DRAW loop is to identify which commands should be re-run if the display image needs to be recalculated several times, as part of the "paged drawing" technique used to save RAM.

Because clear() performs an "all-at-once" wipe, and fastmodeOn() sets a persistent config. option, neither should be placed inside the DRAW loop. This will cause them to be run, and possibly re-run, after the hardware init process which occurs at the start of DRAW.

This concept is not made particularly clear, and I will need to look into re-writing the doc to highlight the true purpose of DRAW. A simpler fastmode example might also be called for, and possibly a lockout to prevent fastmodeON() and clear() from being called inside DRAW altogether.

You may find it useful to reference the code snippet given in the API:

#include <heltec-eink-modules.h>

DEPG0150BNS810 display(2, 4, 5);

void setup() {
    display.clear();

    // Begin fastmode
    display.fastmodeOn();

    DRAW (display) {
        display.setCursor(10, 10);
        display.print("ON");
    }
    delay(2000);

    DRAW (display) {
        display.setCursor(10, 10);
        display.print("still ON");
    }
    delay(2000);

    // Back to normal drawing
    display.fastmodeOff();

    display.setWindow(0, 40, 100, 100);

    DRAW (display) {
        display.setCursor(10, 40);
        display.print("OFF now..");
    }

}

void loop() {}

Note that if you are 100% certain your display is blank, you do not need to call clear() before entering fastmode.

---

Arduino Mega 2560

Note that with Mega2560 and DEPG0150BNS810, there is sufficient RAM that paging is not used by default. This uses 5000kB of the 8000kB available SRAM (>60%). If you wish to reduce this, you can renable paging in the constructor. The trade-off is reduced speed.

If you choose not to enable paging, you are also free to use the alternate syntax outlined in API: update(), and the update.ino example.

---

Hopefully this helps point you in the right direction. Please let me know if I have misunderstood the problem.

[Avamander]

Thanks for the reply! I'll try out the approach described soon.