PSRAM support for ESP32-S3 now works, potential to chain 20+ panels.... but is it pointless?

[mrcodetastic]

Thanks to a tip from Sprite_TM I've got PSRAM support for the graphic buffer now working in the master branch.

However, I am not sure this will be of much use as I have noticed that the maximum DMA output when reading from PSRAM is about 10Mhz max that can be achieved (using internal memory you can drive the panels with a data rate of upwards of 20Mhz).

What does this mean?

Well, now the problem isn't the number of panels you wish to chain (I have just tested running code with a chain of 24+ panels and it worked), but the refresh rate was super low and flickery if the colour depth wasn't dropped. Can't fight physics.

[    88][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:324] begin(): [begin()] Using GPIO 4 for R1_PIN
[    88][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:325] begin(): [begin()] Using GPIO 5 for G1_PIN
[    93][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:326] begin(): [begin()] Using GPIO 6 for B1_PIN
[   101][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:327] begin(): [begin()] Using GPIO 7 for R2_PIN
[   110][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:328] begin(): [begin()] Using GPIO 15 for G2_PIN
[   118][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:329] begin(): [begin()] Using GPIO 16 for B2_PIN
[   126][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:330] begin(): [begin()] Using GPIO 18 for A_PIN
[   135][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:331] begin(): [begin()] Using GPIO 8 for B_PIN
[   143][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:332] begin(): [begin()] Using GPIO 3 for C_PIN
[   151][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:333] begin(): [begin()] Using GPIO 42 for D_PIN
[   159][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:334] begin(): [begin()] Using GPIO -1 for E_PIN
[   167][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:335] begin(): [begin()] Using GPIO 40 for LAT_PIN
[   176][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:336] begin(): [begin()] Using GPIO 2 for OE_PIN
[   184][I][ESP32-HUB75-MatrixPanel-I2S-DMA.h:337] begin(): [begin()] Using GPIO 41 for CLK_PIN
[   193][I][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:58] allocateDMAmemory(): [MatrixPanel] Free heap: 373860
[   202][I][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:59] allocateDMAmemory(): [MatrixPanel] Free SPIRAM: 8386179
[   211][I][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:85] allocateDMAmemory(): [MatrixPanel] Allocating 393216 bytes memory for DMA BCM framebuffer(s). <--------- WOW!!!!!!!!!!!!
[   224][W][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:105] allocateDMAmemory(): [MatrixPanel] lsbMsbTransitionBit of 0 gives 1 Hz refresh rate.
[   236][W][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:105] allocateDMAmemory(): [MatrixPanel] lsbMsbTransitionBit of 1 gives 3 Hz refresh rate.
[   248][W][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:105] allocateDMAmemory(): [MatrixPanel] lsbMsbTransitionBit of 2 gives 6 Hz refresh rate.
[   260][W][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:105] allocateDMAmemory(): [MatrixPanel] lsbMsbTransitionBit of 3 gives 11 Hz refresh rate.
[   272][W][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:105] allocateDMAmemory(): [MatrixPanel] lsbMsbTransitionBit of 4 gives 21 Hz refresh rate.
[   284][W][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:105] allocateDMAmemory(): [MatrixPanel] lsbMsbTransitionBit of 5 gives 33 Hz refresh rate.
[   297][W][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:105] allocateDMAmemory(): [MatrixPanel] lsbMsbTransitionBit of 6 gives 45 Hz refresh rate.
[   309][W][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:105] allocateDMAmemory(): [MatrixPanel] lsbMsbTransitionBit of 7 gives 50 Hz refresh rate.
[   321][I][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:127] allocateDMAmemory(): [MatrixPanel] Recalculated number of DMA descriptors per row: 1
[   333][W][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:134] allocateDMAmemory(): [MatrixPanel] rowColorDepthStruct struct is too large, split DMA payload required. Adding 7 DMA descriptors

[   349][D][gdma_lcd_parallel16.cpp:316] allocate_dma_desc_memory(): [gdma_lcd_parallel16] Allocating 1536 bytes memory for DMA descriptors.
[   416][I][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:231] configureDMA(): [MatrixPanel] 128 DMA descriptors linked to buffer data.
[   416][I][gdma_lcd_parallel16.cpp:83] init(): [gdma_lcd_parallel16] Cpu frequecny is 240
[   424][I][gdma_lcd_parallel16.cpp:114] init(): [gdma_lcd_parallel16] Clock divider is 4
[   432][I][ESP32-HUB75-MatrixPanel-I2S-DMA.cpp:271] configureDMA(): [MatrixPanel] DMA setup completed

[board707]

I have just tested running code with a chain of 24+ panels and it worked), but the refresh rate was super low

What is the panel size (32x16, 64x32...) and what is the refresh rate and color depth?

[mrcodetastic]

The debug output above should provide a clue.

If not, you can check the value of this variable after start up.
https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-DMA/blob/master/src/ESP32-HUB75-MatrixPanel-I2S-DMA.h#L518

[board707]

lsbMsbTransitionBit of 7 gives 50 Hz refresh rate.

On 24 64x32 panels with (8-lsbMsbTransitionBit) = 1bit colordepth you reached 50 Hz refresh rate, isn't it?
Or am I wrong... it seems to me that this is lower than your previous results

[mrcodetastic]

It would be better if the PSRAM throughput allowed > 10mhz output speed. Seems pointless as it is without all sorts of hardware hacks.

[board707]

Allocating 393216 bytes memory for DMA BCM framebuffer(s)

I am wondering why do you need so much memory.
The library used 16 bit write for each clock, right? Each write is set RGB bits for 2 pixels at once.
So you need 1 byte per 1 pixel per bpp.Therefore 24 panels of 64x32 with 1 bpp should needs only 48 Kbytes buffer.
Why do you need almost 10 times more memory? DMA shouldn't be the reason for this.
Maybe you need to think about optimization... Working with HUB75 matrices on STM32 I am using DMA too, but it needs only 1/2 (a half) a byte for each pixel, so for 24 panels would be enough buffer size 24 Kbytes.

[mrcodetastic]

The library used 16 bit write for each clock, right? Each write is set RGB bits for 2 pixels at once.
So you need 1 byte per 1 pixel per bpp.Therefore 24 panels of 64x32 with 1 bpp should needs only 48 Kbytes buffer.
Why do you need almost 10 times more memory? DMA shouldn't be the reason for this.

I can't comment on your implementation, but looking at how the code works in this library, 2 bytes are indeed shifted each time for two pixels in parallel, however the library always allocates 8 (8x16bits), unless you change the hard coded value of the colour depth parameter.

So 64×32×24×8 = 393216 (for a chain of 64x32 panels)

The lsbmsb thing is used to extract the real colour depth from the bitstream. Essentially it looks like 3 bit colour is possible with a chain of 24 panels. I will try and see if there's a way to make this better explained in the debug output.

I use this library for a single panel projects so seeing how many panels a $3 chip from China can support is an curiosity tbh. I'll leave it for people that make money off this library to optimise it if required.

[board707]

the library always allocates 8 (8x16bits), unless you change the hard coded value of the colour depth parameter.

It seems to me illogical. If you reduce the colour depth, then it would be more correct to reduce the buffer as well, right?
I don't think you need to drastically rewrite the code for this.

[mrcodetastic]

All the memory allocated is used, it's just the required refresh rate reduces the visual colour depth due to the DMA loop increasing ^2 for each step closer to the lsb

But I hear you, should be able to do something smarter here.

[tsctrl]

hi @mrfaptastic,

i was using 10MHz for my application and changing to 20Mhz does not seems to have noticeable different. is the speed you mentioned above is the one we can configuration during the startup? than 10Mhz should be sufficient for my case.

if 10Mhz was the limit, then let it as the spec or limitation to be accepted for the s3 moving forward. It might has usable benefit for others. the point is to have the right match that work ideally and efficiently on the 10Mhz speed.

[mrcodetastic]

If you were using PSRAM (well, enabled the use of it with this library) I've hard coded @ 10mhz regardless.