The above is 192x168 with 3 ABCDE RGBPanels running in parallel on an rPi3 at about 300Hz refresh rate.
It is running the same unmodified triple API arduino code (FastLED::Neomatrix, Adafruit::GFX, and LEDMatrix) using a modified
ArduinoOnPc with a custom glue driver I made that renders the Framebuffer::GFX into rpi-rgb-led-matrix’s RGBPanel driver.
@Louis: random question. I think I’ve read that AB/AC panels allow better refresh rates than ABCDE panels. Is that true/does that make sense? (to me, it’s pushing more pixels on fewer address lines, or fewer pixels on more address lines, which outside of overheads, should be about the same).
If I had enough panels, I should be able to do 256x256 or bigger, but it would only be about 100Hz with my current setup (3 channels active board) and terrible if it were with a single channel.
@louis are you sure you don’t want to consider an rPi 0 for your RGBPanel hardware driver? It would cost almost the same, not be much bigger, and run at least 128x128 without sweating (256x256 on a single chain would likely be too slow, but then again maybe not and it can be tried with rpi-rgb-led-matrix from the command line by blindly sending the data without having to own the hardware).
says 64K pixels at 90hz on an rPi3 with 2 channels in parallel and using 24MB of RAM out of 1GB
An rPi0 with a single channel would run 256x256 on a single channel at 40Hz (–led-pwm-bits=7) and 120Hz (–led-pwm-bits=3)
Ah, yes, it’d be nice if those panels could finally self refresh a little.
Just curious, what did you find didn’t work with rPi for you? They’re just so much more capable for such a task…
(speaking of which, one of my 2 talks at linux.conf.au this week, is about how annoying the memory situation on ESP32, is. I can post slides in a little bit, I’m almost done writing them)
I just don’t use RPis or Linux at all. The furthest I ever got was loading Fadecandy server on a fresh RPi install and streaming to it over WiFi. That’s one reason.
Second, the goal for my project is to make any microcontroller (or SBC for that matter) that can drive SPI/APA102 strips to be able to drive a HUB75 panel. That means the controller has to be able to receive SPI at a high rate as a slave, and AFAIK the RPi can’t do that.
Third, I want to sell this as an all-in-one solution, which I couldn’t do with a RPi based design. I’d only be able to sell a shield, which assumes the user has to setup an RPi, solder pins to it, etc. If I included the RPi as part of a kit, it would have to be marked up, which it seems RPi retailers are not doing (I assume because they can make it up with high margin accessories), so the RPi solution would be way more expensive than the ESP32 solution, or I wouldn’t make any money and the project wouldn’t be sustainable.
thanks for the details. You are correct that rPi has SPI slave hardware but no one got it to work, so it’s useless to you.
BTW, I don’t use rPi myself either, but I made an exception there since it supports more RGBPanels than SmartMatrix (AB and AC plus some other weird ones), at a higher rate on each channel, and it can run 3 busses in parallel, meaning that it can refresh RGBPanels altogether probably 6 to 9 times faster than the arduino microcontrollers we use.
Otherwise, yes, your kit would have included an rPi0, which is less than $10 retail and potentially an active-3 board to run 3 channels in parallel. I was able to get that board for just a few dollars from china and there are free schematics on how to make your own.
That said, the lack of SPI slave seems like a clear showstopper.
