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.

[KnorkFox]

Generally, i would say, that partial update is a good thing, because some displays full update time, could be 8 or even 30 seconds!
Thank you Peter, for your awesome work.

[GitHubsSilverBullet]

One thing to keep in mind:
Waveshare states a Life of 1_000_000 times or 5years.
Which equates to almost 550 refreshes per day.
Updating every second will exceed the lifespan in 11 days.
Just saying…

[peterhinch]

Some Waveshare documentation would put you off using the kit at all! They make decent hardware these days, but code and docs can be a little random.

FWIW I ran a demo which performed a partial update every 10s for 1,000 hours (360K updates). No full updates. Alongside the display was another, unplugged, unit showing a static image of the same demo. At the end of the run ghosting on the working unit was visible if you looked carefully. The overall white and black levels of the two screens looked identical. After a full update the screens looked identical.

[DoubleVee73]

@peterhinch as always, thank you for your work here. I am about to start evaluating this small screen:

https://buyepaper.com/products/gdem0097t61

I will look to implement some of your ideas, particularly surrounding partial updates

[peterhinch]

ePaper display drivers are tricky. The manufacturer's drivers often incorporate know-how about the ePaper panel which is not available to us mere mortals. My drivers are ported to MicroPython from the manufacture's drivers (which are typically in C) with modifications for compatibility with the GUIs.

Partial updates are extra tricky because the visual quality varies between display types. Some are prone to "ghosting" where remnants of the old image remain visible after an update.

I wouldn't attempt to write a driver from scratch knowing only the controller chip.

[peterhinch]

On this general topic I have published this driver for the Waveshare Pico 2.13" display.

This supports partial updates and works well with nano-gui, but for reasons explained in the docs I don't recommend it for micro-gui.

[peterhinch]

Waveshare Pico 2.9" now added (same docs reference). This can be used with other hosts via a supplied cable. It also supports partial updates, but they are limited. With repeated use the blacks lose intensity until you issue a full refresh.