Has anyone succeeded in setting up a framebuffer on psram?
Never used external ram before, it would be a good start to use the PSRAM supplied in the PicoCalc!
The chip used is the ESP-PSRAM64H (https://cdn-shop.adafruit.com/product-files/4677/4677_esp-psram64_esp-psram64h_datasheet_en.pdf).
I found a lib for the RP2040 and RP2350. But probably need some adjustment to work with the hardware configuration of the PicoCalc.
Also sparkfun do a lib implement malloc/free/etc. functions to support 2350 SRAM and PSRAM. It uses a tlsf implementation from Espressif.
Iāve read somewhere (and confirmed by the RP2350 architecture) that the PSRAM and external Flash share the same QSPI bus. Depending on the software implementation, this can lead to slowdowns or even a crash.
Iād like to try writing the framebuffer with the CPU (or 2nd core) in PSRAM. And let the DMA/PIO do the PSRAM<=>LCDSPI transfer.
1 Like
There has been discussion on https://www.thebackshed.com/forum/ViewForum.php?FID=16 and (my understanding is that) the PicoMite maintainer has said that the PSRAM is too slow to be used as a PicoMite framebuffer.
YMMV,
Tom
1 Like
Yeah, the helloworld example in the PicoCalc repo has a benchmark of the PSRAM and its top performance with the pico1 is 900KB/s, which is way too low for what is necessary for 320x320x3 at 60fps (18 MB/s). Even rgb565 at 30fps is 6 MB/s.
Maybe PSRAM can be used as backbuffer with a selective update of small regions.
3 Likes
Milk-v duo (SG2002). 64Mb to 256Mb ddr ram
Luckfox Lyra (RK3506G2). 128Mb dd3 ram.
If only we could install Picomite/MMBasic on the Luckfoxā¦ maybe the Milk-v ??
There is another forum post about the Lyra. I have one but I have not been able to make it work yet.
PSRAM with rp2040 seem to be useless indeedā¦
But I saw some peoples got ~25/20 MB/s on 32-bit uncached R/W with non-overclocked rp2350, 38/26 MB/s after overclocking and some tuning!
1 Like
After a deep reading of the screen datasheet, the max framerate reachable in theory is about 12 Hz.
That in the case you want to push the entire 320x320x16 framebuffer of course.
The PSRAM shoulnāt be the bottleneck, neither on rp2040, nor on rp2350ā¦
Maybe we can do some ātile-ingā of the screen areas, pushing only the updated ones. We can double the framerate just by updating the half of the pixels!
1 Like
I think youāre missing one point: the speeds you mention here apply to cases where PSRAM is connected via QSPI.
However, the QSPI lines of the RP2350 MCU chip are not exposed through the 40-pin header on the Pi Pico 2/2W boards. So, whatever is available on the PicoCalc mainboard definitely canāt be connected to that QSPI interface.
As of now, I believe only the Pimoroni Pico Plus 2/2W boards have a PSRAM chip on the board, and itās connected through QSPI.
1 Like
@1more And yes indeed, the PSRAM on the picocalc is only connected on standard GPIOā¦ (no doubt because it was designed for rp2040).
This invalid the speed values I said at the beginning.
At this point, rather than remaking the picocalc PCB, Iām thinking of making a āyet another pico custom boardā. In order to connect the screen in parallel mode (through a direct flex interface).
But first, letās receive it and do some tests!
Just to make sure weāre on the same page:
the fact that PSRAM on PicoCalc is connected to the Picoās GPIO instead of QSPI isnāt a limitation of PicoCalc itself, but rather a limitation of Pico-compatible modules. As of now, there are no mass-produced 40-pin modules based on the RP2040 or RP2350 that expose the QSPI lines on the 40-pin header.
This is because these modules are typically designed to be pin-compatible with the Raspberry Pi Pico 1/2, which didnāt expose the QSPI lines in the first place.
And if you find or create a module that does expose the QSPI lines on 40-pin header, it will, by definition, no longer be pin-compatible with the rest of the Pico-based boards.
I can see that itās a question of keeping pins-compatible as possible, which is valid for picocalc main board side.
I can embbed the PSRAM like the Pimoroni Pico Plus 2 does, this keep the pins-out compatible but makes the picocalcās PSRAM useless (and adds electricity consumption). A ādedicatedā pico-card may sacrifice compatibility (only for the custom pico-board) for efficiency, and avoid doing a remake of the picocalc mainboard (too much rework just for testing).
However, other cards like Luckyfox or Milk-V, cannot exceed 20-25 MHz of SPI either given the screen specsā¦ The QSPI PSRAM of the Pimoroni Pico Plus 2 or others will not be useful (for framebuffer) as long as the TFT-SPI bandwidth is not increased.
I just found that āraylibā have implemented an OpenGL 1.1 software renderer in their latest commits.
It aim to be used on limited hardware which lack GPU or others accelerators. Ideal for pico in others words!
Apart from OpenGL management (windowInit, draw, etc.), the only thing left to manage would be the framebuffer switch and sending it to the screen.
doing a framebuffer on PSRAM is not too difficult: initial PSRAM framebuffer Ā· Lana-chan/picocalc_lua@03839ca Ā· GitHub
the main issue with my implementation is how rp2040-psram has a 20 byte transfer limit due to how the PIO is set up (i tried modifying it without much success, still need to learn how to work with the PIO) and so writes to it are quite fast (drawing 1000 circles directly to the screen is 5x slower than drawing 1000 circles to PSRAM and then blitting PSRAM to screen) but the bottleneck is in copying the entire PSRAM to the screen. itās possible you could write a PIO program to do this without having to use the Pico RAM as intermediate at all to speed it up further
I see this code use the 2nd core to transfer framebuffer to the screen, and what about using a combination of DMA+PIO instead? I suppose this can avoid using the internal RAM.
CPU => PIO/FB => DMA => SPI
I donāt know if itās feasible or if the DMA would not be too slow.
thatās essentially what i mention at the end of my post :] i just havenāt gotten that to work. all attempts i did caused a hang and that was before i had my picocalc modded for debugging
It was for confirmation by repeating 
I should try it too, I probably lack sufficient motivation. Having the second core and DMA running in sync seem powerful but complex and long to implement.
I havenāt succeeded in using DMA+PIO for the LCD. Maybe we need someone with more expertise to look at it.