ESP32-HUB75-MatrixPanel-DMA
ESP32-HUB75-MatrixPanel-DMA copied to clipboard
mrcodetastic
ESP32-S3 Support
On the new S3 parts, it appears that I2S is now strictly a serial audio interface, with the LCD driver split off to its own distinct peripheral. Totally different register set, so this doesn’t currently compile there.
If adding ESP32-S3 support is of interest, let me know if some hardware would be helpful, I can get at least a Feather board for this.
We have similar goals…I’m currently maintaining Adafruit_Protomatter, which takes a more brute-force approach (but compiles across a bunch of chips)…so anything either of us learns with regard to S3 might be helpful to the other.
Thanks!
S3 is the same MCU as the S2 which I built support for a few months back.
Have you tried using/compiling this library on a S3?
I’ve tried, yes. Does not compile. CPU core is the same, but some peripherals have changed. LCD driver is now a distinct thing, not part of I2S. I’ve made some headway with this and might have a proof-of-concept working tomorrow.
FYI, I thought I was smart months back and started coding HUB75 DMA support of the ESP32-C3, until I realised it doesn't support LCD / Parallel output at all. 😂
Quickly looking at the S3 technical reference manual however, seems to indicate it uses this new GDMA hardware silicon... which the C3 seems to have as well.
So here is some old code I did write, but was never able to test, to try and 'turn on' the GDMA hardware. Not sure if it's of use to you:
https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/blob/dd05550cc5467f864f6ec23fe899bc8a69632052/esp32_i2s_parallel_dma_cxxx.txt
Hi mrfaptastic,
fyi It seems the S3 has a DMA capable PSRAM interface. Would this allow to drive (much) bigger matrixes?
(see also [https://www.esp32.com/viewtopic.php?t=24096])
Thanks!
I don't know as I don't have one of these, but theoretically if PSRAM reliably supports 160mb/sec continuous read rate and the DMA engine supports this as well, then I don't see why not.
FYI, I thought I was smart months back and started coding HUB75 DMA support of the ESP32-C3, until I realised it doesn't support LCD / Parallel output at all. 😂
Quickly looking at the S3 technical reference manual however, seems to indicate it uses this new GDMA hardware silicon... which the C3 seems to have as well.
Hi mrfaptastic, We also got a lot of errors here compiling with an ESP32-S3. Does this mean the S3 is not really supported? Will it ever be? And, because it doesn't support LCD / Parallel output, as well as the C3, it will never be supported?
We are now using the old ESP32 and based on the information that S3 is supported, I bought 3 development boards in order to try it. Bad luck, I guess :)) I could give you one of this boards if you are willing to do some testing / implementation. Thanks.
More than happy to be on the receiving end of one of these devices. No guarantees that I'll get it to work, but I can't see why it works for the S2 and wouldn't work for the S3.
I was hoping to have more spare time to work on this but haven't got very far with this yet. So no S3 support so far, perhaps by end of year.
I have just finished experimental S3 support. It's not complete. Thanks to @juniorradu for an ESP32-S3 in order to be able to test this.
https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/tree/3.0.0-beta
Credit to Adafruit for providing most of the DMA setup code to make this work: https://blog.adafruit.com/2022/06/21/esp32uesday-more-s3-lcd-peripheral-hacking-with-code/
I have also implemented PSRAM support, but it doesn't work (produces garbled output). Perhaps somebody with better knowledge can help on this matter.
Fantastic, thanks for getting started on that! I'll give it a try when I get some time in a few weeks.
I'll probably need to modify it all the same, my displays use MBI5153 / LYD6168 drivers, which seem to lack a bit of support in general.
Good luck with the MBI5153 / LYD6168 drivers, I had some modules with those in and sent them back for a refund. They are not a simple thing to work with... But support would be great!
Equally S3 support is most welcome, good to be able to move with the times and use the latest tech.
Double buffering isn't working yet on S3 - need to figure out why.
PSRAM - Probably due to some byte-alignment issue. Not sure if anybody has a clue as it seems to be a common data corruption issue when people use PSRAM for a framebuffer with an LCD panel. Need to do some byte alignment stuff when using PSRAM for the pixel / bit buffer, a bit over my head.
We have similar goals…I’m currently maintaining Adafruit_Protomatter, which takes a more brute-force approach (but compiles across a bunch of chips)…so anything either of us learns with regard to S3 might be helpful to the other.
Amazing work by the way with what you have created. We literally are building the same thing. Glad I held off a bit so I could leverage your good work.
"I used protomatter in the Genesis matrix." - David Marcus, Star Trek III
Code for driving HUB75-style RGB LED matrices, targeted at 32-bit MCUs using brute-force GPIO (that is, not relying on DMA or other specialized peripherals beyond a timer interrupt, goal being portability).
The thing is, for the S3 you're literally like 1 line away from being a full DMA implememntation. You're using DMA for the S3 currently but triggering manually with a timer? So if you simply loop the last DMA descriptor back to the first one, you'll have the same as this library (which is all I changed with your code really) - whereby the DMA engine just keeps looping around forever with no CPU involvement.
https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-DMA/blob/30f0014b0cee9c16c88a2beda31e7d636f90b4b8/src/platforms/esp32s3/gdma_lcd_parallel16.cpp#L335
Sorry for the delay here. I tested the new code on my LYD6168 panel and custom ESP32-S3 board, it works! Fine for my needs, but I don't think that, when used in this way, this driver IC is being fully utilised. They are PWM embedded and can fit a whole frame of scan lines inside. I think this means you'd be able to reduce the frame data overhead, especially when infrequently updating the panel (e.g. clock display) - handy for slower microcontrollers. There's a good article here for those interested.
Good luck with the MBI5153 / LYD6168 drivers, I had some modules with those in and sent them back for a refund. They are not a simple thing to work with... But support would be great!
I was certainly expecting to bash my head against this problem for a while before seeing any success. Using the HUB75_I2S_CFG::MBI5124; driver seems to work. I haven't thoroughly tested it but worth exploring, for those with similar panels.
Thanks for your hard work @mrfaptastic and @PaintYourDragon!