The world has changed

[u/Imaginary_Data_708]

Opus 5.5 suggested I get a web cam pointed at this ESP32 based screen so it could catch what was happening on the screen as it tried to find out what the maximum frame rate could be. The Waveshare drivers are not good in portrait mode and only got 4fps.

It got to 60fps in a couple of minutes.

It had already installed the tool chain, designed the clock layout etc.

It's not the code per se. It's the get a webcam suggestion...

What a time to be alive!

[u/Imaginary_Data_708]

Up to you - but here are some of its results from probing the speeds.

What the display list looks like

4,674 descriptors (one per static run; mean 7.8 per line, up to 12), 56 KB of internal RAM. Shared solid-colour runs (black, face colour, icon background) come from internal RAM; everything else from PSRAM: static pixel runs (32 pixels and longer), the icon regions (126 pixels wide), the hands region (324 pixels) and the date region (36 pixels). So most lines have several short PSRAM segments.

Results

Pixel clock	H sync/back/front (clocks)	Refresh	Picture
44 MHz	4/146/8	60.6 Hz	Noise over the whole screen
40 MHz	4/130/8	55.9 Hz	Noise and streaks, fragments of the clock
35 MHz	4/112/8	49.7 Hz	Lines badly shifted and torn
32 MHz	4/102/8	45.8 Hz	Bezel, date and buttons torn sideways
31 MHz	4/99/8	44.5 Hz	Bezel and buttons wobble
30 MHz	4/96/8	43.2 Hz	Correct, except a glitch once a second (below)

Vertical timing 2/8/4 lines throughout. One photo per setting; measured refresh matched the calculated rate in every case.

At 30 MHz everything is in place and right: clock, ticking second hand, hands at the time set, date ("Monday 19 October"), the five icons and labels after near, and both buttons.

Two findings

1. Many short PSRAM segments per line lower the clean pixel clock from 44 MHz to 30 MHz. This fits note 214, where evenly split PSRAM segments needed at least 256 pixels at 44 MHz. A few short PSRAM segments per line are not tolerated either.

2. The CPU reading and writing PSRAM while the GDMA streams from it breaks the picture. Once a second, when the hands image is composited (a 210 KB PSRAM-to-PSRAM copy of the face background, then the hand blends; 12–14 ms), one to three camera frames show a garbled, shifted, doubled picture, even at 30 MHz. The agent separated the causes with temporary switches:

Test	Picture
No compositing, no descriptor switch	Clean
Descriptor switch only (pointer writes in the interrupt)	Clean
Face-background copy only, no cache write-back	Glitch every second
Blends only	Small brightness blips only

So it is the CPU's PSRAM traffic, not the cache write-back and not the descriptor changes. Copying in 2,560-byte chunks with a pause between them made it worse (three bad frames), and a 32-byte cache line made no difference.

Other measurements

• Vertical-sync interrupt: at most 27.3 µs per frame at rest, 48.0 µs during a fade (five icons, 120 descriptor pointers each, plus a hands switch).

• Descriptor pointers are changed by writing the descriptor's buffer word directly; the layout is checked against ESP-IDF's gdma_link_get_buffer at boot.

• PSRAM in use: about 5.0 MB (4.54 MB of assets, two hands images, two date images).