Memory footprint of epd_init() about epdiy HOT 7 CLOSED

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.

from epdiy.

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!

from epdiy.

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...

from epdiy.

@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?

from epdiy.

@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.

from epdiy.

@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

from epdiy.

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

from epdiy.