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.