I’ve been exploring controller options and I can’t seem to find what I’m looking for. I want to offload the work of driving my 128x64 matrix from the main cpu/mcu by dumping frame buffers via UART or SPI to a controller and let that controller refresh the matrix. I’ve seen it done with FPGA’s a few times (such a A FPGA controlled RGB LED MATRIX for Incredible Effects - the Hardware - Open Electronics - Open Electronics). SmartMatrix and shields look like a good starting point but I want it much cheaper for mass production.
Has anyone already done this?
What would be the most effective MCU for hosting this setup? Teensy (a bit expensive), esp32 (can it handle the work?)
You have excellent timing, I’m working on this now and finalizing the hardware design for V1. It’s based on the ESP32 single core chip, receiving data via APA102 formatted SPI. It will support up to 128x64. Right now I get up to about 30fps update rate (matrix refresh is decoupled from update rate and is at a minimum 120fps to reduce flicker) receiving 64x64 frames from a Teensy 4.0. I haven’t optimized the updates yet so there’s a lot of room for improvement. I’ll post more to this forum after I finalize the hardware. I’m designing it as a product to be sold, but it will be open source hardware.
I was thinking the same - an open source product on crowdsupply.com. We (Mystic Pants) need it for a product we are working on. If it saves me allocating the resources to build it in-house I would be happy to support it commercially.
A public update on this, as @blindman2k and I have been communicating directly: I finished a prototype THT and ESP32 dev board based hardware design for the controller and placed an order with OSH Park. I hope to get boards in a couples weeks and verify the circuit is working before starting on the actual SMT production version.
Thanks so much for all the work you’ve done on this! I’m loving SmartMatrix on the teensy4 and am really excited to try out the sound reactive WLED port on the ESP32.
I tried uploading the BRD file for the SMT version to OSHPark and got the error “Invalid or corrupt brd file”
Also when importing the BRD file into KiCAD 5.1.9, it gives the error ‘not well-formed (invalid token)’ at line 70.
Again, not sure what files you’re referring to, but this is the latest evolution of the project, in case you’re ordering some older design (which still might be useful too, not sure):
Here’s WLED driving Pixelvation Engine with 4096 pixels:
There’s still a lot more room for improvement on making WLED more efficient for driving large high quality displays, but it’s going pretty well so far! I’m discussing my work here:
The files I was referring to are the ones from your SmartMatrix project on github. Located in SmartMatrix/extras/hardware/ESP32. Specifically the SMT one.
Got it, that board should be able to run the Pixelvation Engine HUB75 firmware, receiving APA102 data from another ESP32 running WLED. There won’t be any level conversion, so you’ll have to use 3.3V signals between the two, which isn’t as great as stepping up to 5V and back down to 3.3V, but should be fine for a short distance. I don’t have any plans on integrating HUB75 driving directly into WLED.
I have some leftover level shifters so it’s not a big deal to wire up another one on a little PCB. Knowing it could be a problem, it always made the most sense to just add it IMO.
There’s not a configuration for the SmartLED Shield already, you’ll want to create one. I just pushed a change to SmartMatrix Library that will help you, so grab the latest.
You can change GPIO_I2S_IN_PIN_CLK and GPIO_I2S_IN_PIN_D0 to different pins if you want. They’re only used for input so I personally would put them on some of the ESP32s Input-only pins. Remember that the ESP32’s pins aren’t 5V tolerant.
I’ve made some improvements to the Pixelvation Engine firmware that I haven’t pushed to GitHub yet. Let me know when you have the board running SmartMatrix Library and Pixelvation Engine firmware and I’ll try to find some time to polish up and push the changes
I found (years ago and I don’t recall the details) that there’s Chinese parts with similar footprints, so maybe you can find an alternate part if that digikey part isn’t convenient to order
You may need to compile WLED SR from the /dev branch. I think WLED v0.11 has a 1500 limit, but v0.12 (only available in a beta version) relaxes that limit. You still may need to make some changes to drive 4096 pixels.
I had to change these two #defines in WLED to drive 9216 pixels: