[shultays]

Be aware that those 3 color screens are very slow to update, 15-20 seconds. So not super useful for most kind of projects

Unfortunately the fast color displays (we can buy) are not there yet. Only black & white (and grayscale) ones are fast enough to be used as somewhat generic screen you can interact with

[Nursie]

> Be aware that those 3 color screens are very slow to update, 15-20 seconds.

I just did a project with one. You are right, the three (or more) colour screens do indeed have very slow update cycles, and they usually don't support partial refresh either (just updating part of the screen)

BUT there are some tricks you can do. You can start most of them in two-colour mode, which does support partial updates, and you can define and upload a custom set of waveforms that govern how the screen performs its refresh and update cycles. I wrote an email to the company I purchased from (good-display) and they were very responsive and sent me some waveforms to try. These allow a much faster update (~1s) at the cost of some slight greyness, which gets worse over time, needing a full refresh after a while.

The resulting code I wrote now does something like -

  - start device (colour)
  - draw background in colour (15 seconds)
  - every minute, restart device (B/W) and draw 'active' areas (1 second)
  - every 15 minutes redraw background (full screen update, 15s)
  - every 24 hours run a screen refresh routine(1 minute plus)

It's not ideal, but it does allow you to do something like a static background image in color, then a clock and a few gauges that update more frequently.

(my screen refresh routine cycles each pixel through each of the colour transitions, black->white, black->red, white->red, and the reverse)

[shultays]

I wasn't aware that you could only update BW like that in a faster way, I don't remember such API on waveshare ones. Maybe they don't have that, or maybe it is not something officially supported and part of public API

[Nursie]

So yeah, the good-display screen and the waveshare ones I think are the exact same hardware, not really sure 100% on that. I wasn't really using an API, I just used the SPI interface directly and implemented my own API on top (in fact I made a simple TLV protocol over USB to drive the RP2040 zero, which then performs the right SPI magic to drive the chip in the display which then.... the number of processors in this setup seems excessive)

Effectively I had to piece together some clues. There was the manual for the screen which gave the definition of the SPI protocol in use, and the commands you could send, what they did, screen startup sequence etc. They mentioned waveforms and modes a bit but it was frustratingly incomplete and it looked like there were gaps in the commands described. Then there was a youtube video of a guy showing how he'd implemented fast refresh on some other model of screen by uploading custom waveforms, who mentioned looking for waveforms in sample code and for chip specifications. This lead me to the original docs for the driver chip on my display (an ultrachip UC8179) which had the missing commands specified. Using these along with the waveform (LUT) definitions supplied by the vendor when I asked them for some, allowed me to make the fast mode.

I presume some commands were missed out of the vendor document as a lot of them were non-essential, and possibly could cause harm(?). Certainly the wrong waveforms could lead to poor performance or no performance. Also the chip spec document didn't give some of the higher level "Here is the startup sequence for your screen" flow chart niceties of the vendor doc.

(The waveforms are literally describing how the screen should apply voltages to transition a pixel from one colour to another. The default ones that the screen ships with are good for a 'full' refresh of the pixel, but you can get away with a lot fewer, faster voltage switches for B/W, at the cost of quality declining over time, which you reset with a periodic 'full' refresh)

[sircastor]

Yeah. They take a while, but as long as your project is only dealing with static images/data, you can update it at inconspicuous times. I recall seeing a calendar project that used a display like this. The red was used to highlight important things, and it only has to updated when something changes.

The full-color (7 or 8 colors to mix) take forever to update, but if you’re just displaying a photograph, update it at 2am and no one knows the difference.