You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
Use an C routine to extract into a transmit buffer... this is fast and lets you use the the Graphics class for Espruino style drawing and push out the buffer as is. Claiming contiguous memory should not be an issue... (see use of C in Efficiently moving things around in zig-zag Graphics buffer visualized w/ 24/32 bpp displays / neopixel strings. Using this technology you can trigger the update of the display anytime and it can run to its own beat. Used that technology in the same application context: drawing/writing to the Graphics object is event driven and updating the display/reading the Graphics object is event driven. Update you can trigger by time or at application flow specific points where you know that updating the display makes sense. I'm not sure if you use partial update... which I know was tried and shared in the forum, but I cannot recall final conclusions (your fourth color could be used for that - using a bit pattern for the white, red and black colors that share a bit - to determine what zone to update and clear it on update).
Having the drawing and updating the display separated allows optimizing of automated update and at the same time on demand update as the application can control it (fire an event and move on, and update requests can be queued and skipped to do the least number of). Separation also makes it easy to exchange the displays type.
If you are short on memory, doing it inplace? Not sure what you win, because transformation would have to happend before AND after transmission to display.
@MaBe is one of the forum members who has extensive experience w/ 3-color ePaper displays. I'm sure he has his ideas too.