Hereās an update to the T4.0 driver along with some test results for bigger resolutions (up to 256x256):
I would like to get this working with the SmartMatrix library soon.
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 see that t 4.1 is out now. Looking forward to the new shield.
By the way, I wanted to give a shout out to @lemuroid (Mark Estes), the code wizard behind the most arduino 2D demos Iāve found:
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.
For anyone who wants to try this before the new shield is released, there are details of the wiring modifications for the SmartLED Shield (for Teensy 3.x) V4 here: LED Matrix driver for T4.0 using FlexIO parallel out, FlexPWM, DMA, & SmartLED shield - Page 2
Hi Mark, Iām looking forward to seeing what patterns you can do with the power of a Teensy 4!
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.
The easiest way to order from OSH Park is by using this link to the shared project on OSH Park
Hey easone,
I just tried this at different CPU speeds and it currently seems to only work at 600MHz. Can you confirm the same?
Edit: also Iām noticing a bit of random pixel flicker on two 64x64 (128x64 total) displays at 600MHz. Overclocking things to 720MHz sorts this out.
I was running these panels with the rudimentary libraries I wrote/modified before at 150MHz (mind you it was 16bits total for colour and whatever random refresh rate it felt like doing) with no issues - GitHub - bleckers/RGB-Matrix-Panel-Teensy-4.0: Arduino RGB LED Matrix library with Teensy 4.0 support
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!
Hereās a PDF schematic of the adapter for anyone that needs it and doesnāt have EAGLE installed
I tested the OSHPark adapter and it appears to work perfectly on both T4.0 and T4.1! Electrical performance looks better now that Louis eliminated the jumper wires.
I committed some changes to my fork to support the adapter. It requires a special header (āMatrixHardware_T4Adapter.hā) to be included before the library.
https://github.com/easone/SmartMatrix
Added FM6126A support and made performance improvements too.
I received my adapter yesterday, and used it with a Teensy 4.0 and 4.1, and it seems to be working well.
The pins used for refreshing the panel conflict with the built in SPI pins (at least the ones accessible on the edges in the Teensy 4.0, so driving APA102 LEDs with the SmartLED Shield V4 APA102 buffers and cable isnāt very practical as is. @easone told me about KurtEās FlexIO_t4 library, which can implement an SPI peripheral using DMA and FlexIO on alternate pins. I adapted the SMARTMATRIX_APA class to work on the Teensy 4 using FlexIOSPI, and itās mostly working well. Use of the DMA or FlexIO for driving SPI seems to be conflicting with the SmartMatrix HUB75 DMA FlexIO and extending out the time it takes to shift out the pixels.
Normal refresh, where the clocks to drive the HUB75 panel fit between latch pulses
Slow refresh, where the clocks extend past the latch pulses
I just added a larger overhead to PANEL_32_PIXELDATA_TRANSFER_MAXIMUM_NS which seems to solve that problem:
#define PANEL_32_PIXELDATA_TRANSFER_MAXIMUM_NS ((32*FLEXIO_CLOCK_DIVIDER*1000/480) + 50 + 650)
With larger APA102 pixel counts, the APA102 code seems to conflict with HUB75, and thereās corrupted lines seen on the screen. Iām pretty sure this is because the APA102 code calculates all pixels in a frame at once - which can take a long time - and it runs in low priority interrupt context, keeping the HUB75 calculation code from running. I need to break up the APA102 calculation code to do a row (or a few) at a time, instead of a frame at a time.
You can find the Teensy4 APA102 code here, and the FastLED_Panel_Plus_APA example is included: GitHub - pixelmatix/SmartMatrix at teensy4
Louis and I are now collaborating in the new āteensy4ā branch in the pixelmatix repo. The fork I started is deprecated - I wonāt be keeping it updated. For the latest code, go here:
I just committed an improvement that should cut DMA usage down quite a bit. This should help with the conflict with the APA class as well as potential other DMA usage (e.g. SD card).
The driver can now be configured to use from 1 to 4 FlexIO shifters using the RGBDATA_SHIFTERS constant in SmartMatrixRefreshT4.h. Previously it was hardcoded to use 2 shifters. Going to 4 shifters doubles the DMA minor loop size to fill up the shifters, so the number of DMA triggers per row is cut in half. Although the number of bytes transferred is the same, there are a lot of overhead cycles associated with each DMA trigger (for the DMA arbitration process, offset calculation etc.). So the total usage of the DMA engine is lower.
Overclocking the CPU to 816 MHz will help too, since that speeds up the DMA engine without increasing the matrix panel clock speed.
If you need to slow down the HUB75 driver to get APA102 working well, Iād recommend decreasing the pixel clock (by increasing FLEXIO_CLOCK_DIVIDER) rather than adding overhead time to PANEL_32_PIXELDATA_TRANSFER_MAXIMUM_NS. Both ways extend the time between latch pulses. The effect should be the same in terms of total DMA usage, but changing the clock speed will space out the DMA transfers evenly across the row update time.
Hello easone
Do you know if there are two SPI ports available for user applications?
In my designs I need one and two SPI ports to receive data with the images to be displayed. Both working with DMA.
Regards.