Good to know that about FastLED::NeoMatrix, I will have to give that feature a try.
Maybe it’s the best/cheapest we can do for now, one ESP32 per 128x64 panel.
Do we know of any other microcontroller besides the ESP32 that can refresh a 128x64 panel (with decent color depth and refresh rate)? Do we know of any micro that can refresh a 128x128 panel (or two 128x64 panels)? Raspberry Pi is a Single Board Computer, not a microcontroller, and a much different higher point and larger form factor, and larger complexity.
I think supporting 128x64 is pretty good, and it doesn’t need to be any larger, at least not until a larger panel comes out. Most people aren’t pushing the limits of pixel count like you are
I was able to drive 2 128x64 panels (i.e. 128x128 total) with a teensy 3.6 but the refresh rate was bad, so I agree that 128x64 seems the highest we can reasonably do between those 2 CPUs.
When I’m not travelling, I want to look into running my code on rPi (I’ve already confirmed rPi runs 128x128 without sweating), but having some integrated solution where an ESP32 backpack can be connected to a 128x64 panel and give an APA102 output, would also be an attractive solution.
You can use an NXP RT1020, it is a Cortex M7 at 500Mhz. Much more powerful than an ESP32 (160-240Mhz), it is an ARM processor and you have a free and professional development environment (MCUXpresso).
Discarding the Teensy 4.0 does not mean not being able to use the NXP RT microcontroller series. Only you have to design your own board with the microcontroller, an LQFP144, which is not difficult to weld, or if you order them to manufacture the ready made board (with the microcontroller already soldered), it will be much simpler.
I have my own design based on a MIMXRT1021DAG5A, it is also very cheap compared to ST STM32H7. Since it has no flash memory, you can boot from QSPI, SD card or hyperflash. You can also add an external SDRAM of up to 256Mbit to load and run the program from RAM, which is even faster.
I enclose my scheme with the RT1020, in order to use the Smartmatrix, porting it to MCUXpresso, which seems to me a much better development environment than Arduino.
Some more details from PJRC on how even a larger Teensy 4-series part with more pins brought out may not (or possibly could) support DMA driving GPIO pins:
The GPIO registers in these newer chips do not support 8 or 16 bit access.
However, having 8 or 16 consecutive bits of a FlexIO peripheral might be useful…
I’m not familiar with FlexIO, so I don’t know what that implies. I’m mostly putting this here for anyone that comes across this thread and wants to drive GPIO with DMA from a Teensy 4.x, I don’t have any plans to add Teensy 4.x support to SmartMatrix Library as of now.
What is the preferred way to do that? I think it would be compatible with the existing code for the layer classes but I am not planning to support hardware other than the v4 shield or have the code be compatible with T3.x, so I don’t think it makes sense to merge it into the existing SmartMatrix3.h and SmartMatrix_impl.h source.
One way would be to create an entirely new library for T4 which replicates the Layer class files. Or the new T4 code could be included in the original library but would be new files named something like SmartMatrix_t4.h. Or Louis may prefer that I don’t use the SmartMatrix name.
Great work on this, I’m really impressed with the results you posted!
The “teensylc” branch is set up to allow different hardware types. I think the best thing to do is try to follow what I did to add support for the teensy lc and ESP32 and add a class for the Teensy 4.0 with your code. I’m really limited on time right now but happy to help out where I can.
I’ll have to think about how to handle the hardware definition file. For now, don’t try to edit the existing V4 shield file. Make a new file named V4T4 or something unique to the use case of a modified V4 shield with Teensy 4 in it.
Maybe a reminder to rename the master branch as ‘oldstable’ (git branch) and then integrate teensylc into master after putting a last commit in teensylc with a README pointing out that people should go to master instead?
All in all it should take 10-15mn hopefully?
Teensy 4.0/4.1 support update: @easone is refactoring his code into SmartMatrix Library, and with his help I finalized a shield design that will support both Teensy 4.0/4.1 and I’m ordering prototypes. It’s based off of SmartLED Shield for Teensy 3 V4, and looks identical. We’ll post more updates in this thread.
I got an initial port of the library working. It’s in a new fork of the “teensylc” branch here: GitHub - easone/SmartMatrix: SmartMatrix Library for Teensy 3
There is no support for multi-row panels or FM6126A yet; also, APA driving is not supported.
I was really excited to try @easone’s port this weekend, and so far in my limited testing it’s working great!
The SmartLED Shield for Teensy 4 prototypes are ordered, but realistically it’s going to be a couple months before they’re available for purchase. In the meantime, I just designed an adapter board that takes a Teensy 4.0 or 4.1, and slides into the SmartLED Shield for Teensy 3. The unused signals on the Teensy 4 are brought out to the connectors, though most pins are in different positions as the Teensy 3 and Teensy 4 SmartLED Shields require different pins.
I don’t plan on selling this adapter, but you can order the PCB from OSHPark ($7.45 for three boards shipped!), and consider ordering a Teensy 4.0 at the same for only $18! I just ordered the boards myself, so if you want to be safe you should wait until I get them and test before placing an order.
The adapter plugs into the SmartLED Shield with 2x 14-pin headers, the same type you’d use for a Teensy, but in the outer row of holes instead of the inner row. You attach the Teensy 4 to the adapter directly, or with female headers. For the most low-profile setup, you’ll need to solder the Teensy 4 directly to the adapter, then trim any long pins underneath, which would otherwise contact the pads on the SmartLED Shield, or use headers with a short tail (less than 0.1") under the Teensy. If you want to be able to remove the Teensy 4, then use 2x 14 pin female headers.
I’ll post pictures explaining this more after my boards arrive.
This might be due to all the other things I’m doing too which might be slightly interfering with timing. Is there a way to avoid any critical timing regions?
Some of the pixel flicker issue may be electrical and related to stray capacitance or grounding, so I expect it to improve with a shield that does not require jumper wires…
You can try adjusting FLEXIO_CLOCK_DIVIDER in MatrixHardware_KitV4T4.h to decrease the pixel clock speed. The FlexIO clock speed is not affected by over or under clocking the CPU, and it’s already close to the maximum at 600 MHz CPU before the DMA transfer is not able to keep up. Slower than 600 MHz doesn’t work for me either.
Edit: if your project has other peripherals that use DMA transfers or buffers in DMAMEM (such as SD or Serial) then that may require a slower FlexIO clock to run stably.
Ah ok, that makes sense considering the higher data requirements of a much nicer image. Not an issue really, everything is working fine at the higher clock speed for me, just wanted to see if it was something on my end.
As for the the flicker, there’s a bunch of SPI transfers going on, so that’ll be it. I’ll tweak them to run around the frame timing. Good to know thanks!
