As I'm waiting for my Good Display to be delivered I'm examining the examples. It seems the general flow for ePaper is:
init();
write, clear, etc to the display.
refresh();
sleep();
Then go do something else until the display needs to be updated.
I'm trying to get a basic framework in my mind while waiting for delivery.
Is this correct?
Also I can't see how pages are used with the ePaper.
Is it:
The µC has enough memory to create two images in memory and when time to update the display it writes one of the pages to the display.
If so I don't see the benefit. I'm assuming creating the image in memory if faster than updating the display.
Hi JohnRob,
I've been working with a few different displays lately and that does seem to be the basic framework.
Depending on the library you are using, refresh() may or may not block further code execution until the display finishes updating. The library may also let you pick which behavior your prefer.
As for pages, the purpose is really the opposite of what you are imagining. A small display may be 200x200px. 200 squared = 40,000 = 5kB. This presents a problem given that an Arduino UNO has only 2kB of SRAM.
In the context of e-paper displays, the goal of paging is to draw a larger image than would otherwise be possible, by calculating the screen in several small sections, and transmitting the data one "page" at a time, before ultimately refreshing to display the finished mosaic all at once.
If your microcontroller has resources to spare, there is no advantage to paging, but it can be a very useful "trick" if your board is overwhelmed.
The tradeoff is that the calculations needed to draw the screen image will have to re-run for each page, so the trade off is time vs. resources. Given the slow refresh time of these displays, the extra time taken for paging does tend to be fairly insignificant.