Pico2 slows down display pack

[peardox]

Yeah, I couldn't believe it either...

Soldered up 2x Pico 2 and 1x Pimoroni Pico Plus 2 to try them out on diplsy packs

On my Pico Ws the display_pack_2_demo runs at 30fps (I added frame timing)

On all Pico 2 devices the FPS drops tro 24fps - tried all three devices I have to hand

Tested on a display pack 2.8 - I have the others as well but doubt there'll be much change (apart from the smallest as it has a smaller screen), the 2 + 2.8 are just a bigger LCD, exact same pixel counts

[Gadgetoid]

I am wholly unsurprised! Though I don't have a good inkling for why it might be the case.

One possible candidate might be the 125MHz clock that MicroPython has been setting for the RP2 port until recently. Though I would expect this to make the Pico 2 not faster rather than slower (regardless of the improvements to processing time of the image, it would limit the data throughput which might be enough to slow things down.)

I would have implicated PSRAM, but since the Pico 2 doesn't have any that wouldn't make much sense...

Benchmarks clearly show the Pico 2 as being faster, though, so my best guess is that we're not correctly configuring the clock.

Do you have a minimal repro that shows the framerate difference without much extra cruft?

[peardox]

Ahh - just spotted #985

@Gadgetoid I'll stick my code on Github in a little while and add a note here

[peardox]

Here you go - https://github.com/peardox/display_pack_28

The repo is all-in-one. As long as you have a 2.8" pack and a pico 2 it'll run without changes

Oh and my Pico 2's have never been assulted by MicroPython :)

[peardox]

And adding the patch from #985 makes the framerate zoom up to 45fps

Tada (might need a different value for stability) - this fix has not been pushed - just edit drivers/st7789.hpp as suggested to try it out

[Gadgetoid]

I'm happy if you want to make a pull-request of it and claim the glory 😆

I had assumed you were using MicroPython, so I was waaaaaay off.

[peardox]

I was already thinking of doing a PR with the modifications just for the display_pack_28 definitions but also adding the FPS demo will be nicer

I wanna check out the SPI rate as (150/133) * 62,500,000 |= 75,000,000 (actual value is a funny number so wanna experiment first)

[Slion]

For best frame rate also make sure you use the proper pixel format.

For Pico Display Pack 2 RGB565 is the native color depth and the fastest to update at 24ms but take up 150KB out of 246KR RAM. RGB332 is slower to update at 32ms but takes up only 75KB out of 264KB of RAM.

[peardox]

And yet changing it to...

//PicoGraphics_PenRGB332 graphics(st7789.width, st7789.height, nullptr);
PicoGraphics_PenRGB565 graphics(st7789.width, st7789.height, nullptr);

Dropped the frame rate from 45.x to 43.5-ish

Wonder what 888 does...

[peardox]

Oops 888 crashes - mem requirements are 240k for that res but I am on a Pico2 so plenty to spare

Looks like a different bug...

Hmm Pimironi Pico 2 Plus tho - might try a Pi Pico 2

[Slion]

Dropped the frame rate from 45.x to 43.5-ish

That's weird, maybe there is something else at play. You better look at the frame time or even just the update time when trying to optimise your display performance. Though FPS is still interesting.

[peardox]

Tried Pen4, Pen8, Pen332, and Pen565 which all work

Pens other than 565 all run thru a frame conversion function

Only Pen888 dies horribly (Pen4 just looks horrible)

[Slion]

Pens other than 565 all run thru a frame conversion function

Yup

[peardox]

Now things get even weirder - switched to a PicoW and 332 is 30fps while 565 is 33fps (i.e. faster as you imagined it would)

The opposite rate change the pico2

I also added a method to return the actual SPI rate. The Pico1 won't go above 62,5Mhz and the Pico2 75Mhz

I'll have to switch back to a Pico2 to see what waas reported from a 62.5Mhz request - which according to #985 should be 37.5