Using less pico ram, a different approach (not for everyone)...

[AndrewCapon]

Hi Guys,

I have some hacked code here that keeps the frame buffer in PSRAM and reduces the use of the pico ram. Especially useful for 480x480. And only useful (at the moment) for native pixel format.

Basically all it does is use this bit of pico memory as a cache, the PSRAM is copied to the cache vie the end of scanline interrupt and the PIO stuff is then reading from this cache. This seems to work well with no glitching and gets over the problem of the PIO stuff reading from PSRAM while anything else may be updating PSRAM which causes screen corruption (I'm guessing something to do with the DMA not being able to read it quickly enough?)

The only real advantage to it is that is only uses 4 scanlines of memory for the buffer in pico ram that is sent to the display.

It has disadvantages though:

Due to the reduced memory use the normal Update where the display is updated behind the current scanline is no longer used, so if you run with a single back buffer then you will see some flicker. You can run with two back buffers then you do have the speed of the psram to deal with when keeping them in sync.

So it's not for everyone :)

I wondered if it was something you would like a PR for, if so I can do a much tidier version, one of these:

1. Subclass the ST7701 into a new class that works this way
2. Modify the ST7701 code.

Anyone interested?

Cheers

Andy

[MichaelBell]

I had something like this before, but couldn't get it running cleanly with no glitching. For example, when clearing the back buffer there were small glitches on the read out from the front buffer, even with buffering through internal RAM.

It's possible this was because I was running some code on core1 from flash though. If you have it stable even with core0 busy reading/writing to the other buffer in PSRAM this could definitely be interesting.

[AndrewCapon]

I have everything running on core 0 as far as I know.

I just tried here with double buffering in PSRAM and full screen clear using memset and display->clear() and I get a nice clean display. I have attached a video (hopefully).

I also had some issues using a cache of 1 line, which is why I ended up with 4 but I just changed it to 1 line to see if I could replicate the glitches and it worked fine with 1 line! I thought I would paramertise this cache size.

I can test it with both cores though...

IMG_1952.mov

[AndrewCapon]

If I totally hammer the psram from the other core I see a bit of glitching (and a lot of slowdown :) )

Ignore the top line glitch, that is code that is not quite production ready for the first scanlines as at the moment it is a hacky cheat rather than being done properly!

void Core1(void)
{
  volatile uint8_t *p = (volatile uint8_t *)pCore1Psram;
  while(true)
  {
    for(uint i = 0; i < (1024*32); i++)
      p[i] =p[i+1024*32];
  }
}

IMG_1954.mov

If I run that same code using pico ram though no glitching at all.

[AndrewCapon]

I have added a pr: #35

And some example code: https://github.com/AndrewCapon/presto-cached-examples

I went for the subclass way in the end.

[Slion]

Interesting stuff, would be great to get some performance measurement though. Render time, update time and FPS I guess.

[AndrewCapon]

If you look at those examples they log timings. https://github.com/AndrewCapon/presto-cached-examples

[Slion]

I got around trying it out with my LVGL port. Unfortunately it does cause a noticeable flicker of the parts of the screens that have been update. Funny enough I do get a lot more flicker when rendering from core 1.

Here is what I did:

• Don't use SRAM buffer anymore
• Do use PSRAM full frame buffer
• Don't call update

Could have done something wrong though when applying that patch on top of my rotation changes.
In fact for me it worked much like if I was just using PSRAM buffer.

[Slion]

I could use your example code and it works well enough there.

[Slion]

I could get it to work well enough with fast frame time. But when using LVGL with slower render I get some artefacts.

Rendering from Core 0

Though I did not register line drops it seems there is still a noticeable jumping effect and lag when frame time goes up for some reason. Not an issue with the original driver. This happens with or without VSYNC wait, weird right?

Rendering from Core 1

I get line drops, not all 480 lines are transferred every frame so you get that same jumping screen effect that you get when just using a PSRAM front buffer, though not as bad, still not usable however.
That matches what I observed with just a PSRAM front buffer, running on Core 1 gives you more jumping/line drops.
It seems that PSRAM access is slower from Core 1.

So basically I still can't run at native resolution without needing that massive 450KB RAM frame buffer, meaning you can't use Bluetooth or WiFi on whatever little RAM you have left.

[Slion]

Since I could not get this working and will still need more RAM than the modest 48KB left when running with 450KB I've modified the driver so that you can set height resolutions below 480 while keeping the width at 480. I reckon I'll probably run at 480x360. It's also a lot easier on the LVGL renderer. Rendering 480x480 frames is really stretching it for that poor RP2350.

[tgrandgent]

480x480 is a challenge but I've been able to get smooth results doing 2D effects like fade and crossfade (RGB565) from PSRAM to the SRAM framebuffer using a native .mpy module and asm. I hope the existing support for 480x480 will be preserved in default builds. Of course, it would be nice to have more SRAM to play with than the 4KB at SCRATCH_X.

[Slion]

Nobody is taking away 480x480 support. You can indeed get some smooth rendering at this resolution just not with LVGL while scrolling a screen full of anti-aliased labels or rounded corners buttons. My main issue with full resolution is not so much the frame rate but the RAM usage. Very disappointing that we can't use PSRAM as front buffer.