Memory footprint of epd_init()

[lyusupov]

The issue was found while using LilyGO's port of the epdiy library for Arduino/ESP32:
https://github.com/Xinyuan-LilyGO/LilyGo-EPD47
However, is seems to be applicable for the 'master' library as well.

Ok. Let's add few debug print messages near epd_init() function, as follows:

Serial.print(F("before epd_init: Free heap size: ")); Serial.println(ESP.getFreeHeap());

    epd_init();

Serial.print(F("after epd_init: Free heap size: ")); Serial.println(ESP.getFreeHeap());

This is a console output for the test above running on WROVER-E with 8 MB of PSRAM:

before epd_init: Free heap size: 194912
after epd_init: Free heap size: 97856

So, the epd_init() takes about 97 Kbytes of built-in ESP32 static RAM.

Is it good or bad? The answer depends on whether or not we gonna use other functions of the ESP32 SoC...
The space remaining is Ok to bring up Wi-Fi stack or Bluetooth, but not both. 😞

The epd_init() function code contains the following:

conversion_lut = (uint8_t *)heap_caps_malloc(1 << 16, MALLOC_CAP_8BIT);

When we alter the line onto this (valid for built together with Arduino/ESP32) :

    conversion_lut = (uint8_t *)heap_caps_malloc(1 << 16,
                          psramFound() ? MALLOC_CAP_SPIRAM : MALLOC_CAP_8BIT);

 - it's getting much better now:

before epd_init: Free heap size: 194912
after epd_init: Free heap size: 163408

My sketch works fine to me when connversion LUT table is located in PSRAM. However, we yet need to:

• find an equivalent of psramFound() in ESP-IDF, and
• make sure that there is no significant performance reduction.

[vroland]

Hi,
yes, 97k may be a bit high for some applications...
Moving the lookup table to PSRAM however will incur a large performance hit, because it is larger than the PSRAM cache and interferes with reading the framebuffer from PSRAM.
But I could implement the option to reduce the size of the LUT: 64k allows to look up 4 pixels with one load, which is also a full cycle of parallel data to the display. But I could split that up in two loads + shift + or, which will not be as fast but reduce the LUT size to 256 bytes.
I'll have a look if the changes needed are small enough to implement it in #61.

[ashald]

Beating a somewhat dead horse here - I'm trying to minimize energy consumption of a run cycle in between deep sleep, and I found that enabling PSRAM adds ~800ms to the boot time, which is about 1/3 of the entire runtime.

If I only need black & white (I'm experimenting with Lilygo FWIW), and MODE_GC16 (which gives me the crisp image I'm looking for), can I reduce the size of the framebuffer from EPD_WIDTH / 2 * EPD_HEIGHT somehow, so that I could fit it into the main memory?

Thanks!

[vroland]

You can, using the low-level api: https://github.com/vroland/epdiy/blob/master/src/epd_driver/include/epd_driver.h#L136 as a starting point. This packs 8 pixels in one bye. I don't have an example for this mode though, and haven't used it in a long time...

[ashald]

@vroland thanks for a quick reply! I had high hopes ever since I noticed that flag, but couldn't figure out how to use it on all mentions I could find https://github.com/vroland/epdiy/search?q=MODE_PACKING_8PPB.

Does it mean I'd have to re-implement all the primitive drawing functions, so that I can flip proper bits in the framebuffer?

[martinberlin]

@ashald if you check the codebase a bit more you will realize that epd_hl_update_area uses MODE_PACKING_2PPB as default (exactly coherent with the slow mode you are using that is MODE_GC16). In order to use that 8PPB mode you will have to make your own function if I see that correctly and call epd_draw_base using that mode (There is no example so far I think).
Anyways will all due respect this question is a bit off topic for this issue considering that is about the initial memory footprint on the initialization of the library and not about the drawing modes of EPDiy.

update: Will be nice to leave an example about 8PPB mode to understand better how to use and also add it in the documentation. As I understand even if you call an hl_update using MODE_PACKING_8PPB it adds it to the | (OR) mode concatenation, but if you try to use it "as is" you get a white screen.

Updating this line in epd_hl_update_area:

err = epd_draw_base(epd_full_screen(), state->front_fb, diff_area, MODE_PACKING_2PPB | PREVIOUSLY_WHITE | mode, temperature, state->dirty_lines, state->waveform);

to the MODE_PACKING_8PPB you can experiment how it is. You can use the Slack epdiy.slack.com channel to ask questions in different channels.

[ashald]

@martinberlin thanks! Would appreciate if you could suggest a better place to ask such questions.

One thing that I'm confused about is that it seems that the base drawing function for a single pixel is explicitly using 2-pixels-per-byte approach

epdiy/src/epd_driver/epd_driver.c

Line 87 in f3feb5a

if (x % 2) {

, which in my understanding means it cannot work with any other packing mode (as is), and therefore would require a buffer of the same size.

[martinberlin]

Closing here, since there is no more feedback since mid-February, and does not seem a bug that can be solved with EPDiy.