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
3.5 seconds for 176*264 (/8*9) bits makes about 15k baudrate... indeed very slow...
But I have to break bad new to you, it is what it is, as the specs say: https://www.waveshare.com/2.7inch-e-paper-hat-b.htm : 15secs for a refresh / full update, and it has nothing to do with Espruino or any other driving platform.
Why the technology is so slow? I assume it is inherent to the electrophoresis, which by matter of facts takes time. The discovery - https://en.wikipedia.org/wiki/Electrophoresis - speaks of migrating - vs the term of moving - in a liquid. Particles with different properties and color move on different polarity in different direction with different speed in a liquid, which allow the third color (simplified in a nutshell how ePaper works).
I assume the slave device does a lot of clock stretching, which should be visible by looking at the clock with an oscilloscope. I'm pretty sure that ePaper displays do not have built-in buffer. No need for, because after the pixel (distribution of colored particles in cell) has changed, it it stays. No refresh (of same state) is needed. Even with a built in buffer, it could not be made faster. Yes the update of the buffer could be made faster, and some build it logic with more buffer could figure out what to update and go and update only the changed pixles (cells) and then go to sleep after all is updated.
ePaper are for applications that 'rarely' change the content... rarely compared to how long a content stays displayed until updated.
What is the application you have in mind and why did you choose this display technology versus other available ones?
If the answer is "low power", then you may take a look at this paper: https://www.mdpi.com/2071-1050/7/8/10854/pdf