ePaper partial update

[peterhinch]

Partial updates provide a means of performing a fast update of an ePaper display. The price is "ghosting" where the display shows a faint image of areas which have changed from black to white. At any time a full update can be done, in which case all ghosting disappears.

The last time I tried this was several years ago: results were poor. Evidently EPD display technology has improved.

I have updated this dfriver for the Waveshare 4.2" display to support partial updates. The following image is of a test which ran for an hour, updating the time every minute. Ghosting is visible, but arguably not intrusive. Particularly noticeable is that the digital time display looks excellent, despite having been updated 60 times.

Note that the Waveshare display is designed for Pico and Pico W which just plug in. A cable is supplied, enabling the display to be used with other hosts.

The quality of partial updates opens up the interesting possibility of using this display with micro-gui. I currently recommend ePaper only for nano-gui because of its slow update time, but with judicious use of full and partial updates it could be sufficiently responsive to work well with user input.

[peterhinch]

I have updated the driver for this display. See driver docs.

This documents its use with micro_gui. The color demos work, but benefit from minor changes for a 1-bit monochrome display.

I'm very impressed by the usability of this display in applications with user controls. There is a lag between pressing a button and a visual response, but it's manageable and ghosting is minimal. I think this opens up some interesting application possibilities, notably given that the display is retained when the device is switched off..

[peterhinch]

Here is an example image:

[kingtimm]

This is awesome! With driver updates, would similar capabilities be possible for the Waveshare Pico-ePaper-3.7 (the 3.7in version of that display)?

[peterhinch]

@kingtimm My Waveshare drivers are ported from their C drivers. ePaper drivers require lookup tables (LUT's) which are sets of constants which must be passed to the display controller to set the controller's mode. The values in the LUT are entirely opaque and are presumably supplied to Waveshare by the manufacturer of the ePaper display module.

In porting the 4.2" driver I noticed that there were LUT's available for partial updates: I implemented them and was amazed how well they worked.

Unfortunately their 3.7" C driver has no partial LUT, so I'm afraid the answer is no. I'm keen to find other displays which do support good partial updates, but in the mean time I can only suggest using the 4.2" unit, which will work with hosts other than the Pico.

[phoreglad]

@peterhinch They use lut_1Gray_DU LUT to perform partial updates on 3.7" display. I used it in my driver and it worked pretty well.

[peterhinch]

Looking at your driver you might be interested in this bit reversal algorithm which does it in fewer steps with loop unrolling. I would expect it to be faster (with Viper).

Another general point about the Waveshare source: their method of instantiating LUT's is horribly inefficient because it creates a list of integers and then sends it one byte at a time. Far quicker and more RAM-efficient to declare them as bytes objects and send the entire object in one SPI transfer here for example.

[phoreglad]

Thanks for the tips, I'll probably implement them in the next update, whenever it may be. When I think about it, I don't know how it never occurred to me to use bytes for storing LUTs, it seems so obvious now that you mentioned it.
As for the bit reversing algorithm, in the main branch I've added an EinkPIO class that uses PIO to communicate with the display and do bit reversing in hardware right before sending the data, so I never really looked for a more efficient software solution.

[peterhinch]

Interesting. Following the link from your driver to Waveshare's original, they claim support for nano-gui. This is incorrect as the driver isn't subclassed from framebuf.FrameBuffer. It would require some work to make it compatible.

@kingtimm What is the reason for wanting a 3.7" driver? The difference in cost is small ($27.99 vs $30.99) and the 4.2" one has a socket for a Pico, making it very user friendly.

[kingtimm]

@peterhinch you're correct, it's probably easiest to get the 4.2. I have the 3.7 with Pico headers link. I hadn't realized how different their 3.7 and 4.2 drivers were! link to drivers

[nickovs]

I'd like to use this driver with the slightly smaller (and significantly cheaper) 3.52" epaper display module. Do you have any hints or tips for porting to a different module?

[peterhinch]

I'd start by studying the Waveshare C code for the 3.52" display and compare with that for their 4.2" unit. If there is plenty of commonality porting should be easy by modifying my driver, otherwise it may be a start from scratch. Waveshare code tends to, er, need a lot of adapting to make it reasonably efficient...

[nickovs]

Ah, yes. Waveshare's code makes for some interesting reading! It looks like it mostly just needs a different reset/power-up sequence and different values for the LUTs. To that end, I started a discussion item about possible refactoring.