There are many RGB LED matrices available. This drivers is built specifically for HUB75 driven matrices which are usually found in sizes ranging from 16x16 to 64x64 and ranging in horizontal/vertical spacing form 2mm (P2) to 8mm (P8) between individual LEDs. The version i'm developing with is actually a P3 64x32 Matrix which I originally bought from Amazon.
These panels are receive serial data, a clock signal indicating when to latch the data bits, a latch signal indicating that a whole rows of data should be sent to the LEDs a set of address lines (A, B, C, and D) idenitfying which row should be displayed and an output-enable signal causing an addressed row LEDs to be driven.
While the 64x32 Matrices all appear to be similar the manufacturing of them has been rapid and varied. For us this means that a HUB75 panel can have very different Integrated Circuits (ICs) on the panel driving the LEDs. With these IC changes comes the need alter the signals sent to the panels so that the ICs your panel uses understands the input signals.
In general i'm finding so far that there are 3 or 4 commmon choices for ICs used on the panels. One GitHub user Piotr Esden-Tempski offers doc's for some of the panels esden/led-panel-docs showing images of the panels, schematics and datasheets for the ICs used on the panel. (I'm planning on contributing my schematic and various finds to his repo as a Pull request before this project is completed.) There are many more that he does not have but this is a good reference.
Pages: README | Hardware Turn-on | Driver Details | Change Log
The panels I'm using are marked with P3-6432-121-16s-D1.0 Which tell us that it is 64w x 32h (6432) and 16 addressed lines (16s). This board uses FM6126A driver chips and TC7258EN chips for line address decoding. Lastly is uses 74HC245s to buffer the incoming signals and forward them to the output conector. The FM6126A requires that we latch the data very differently in that instead of latching after the stream of bits for a line, we set the latch during the last 3 bits of each line. (per the Datasheet) Additionally, the FM6126A requires initialization of two registers before it runs as a normal panel. This was quite the discovery as the Chinese Datasheet says the two registers exist but doesn't provide detail. Finding details and implementing the initialization was an effort of blending what I saw in posts which showed various forms of coce and other posts describing their reverse engineering of the same effort. But, it's all working, so I'm past this!
Here we see my P2 Eval board with flying leads going to a splitter board I hand made so I can feed the panel and watch the signals with a Logic Analyzer.
Overall: Let's see what performance we can achieve by driving from the Propeller 2 directly!
But let's be more specific:
| Goal | Sub-goal | Description |
|---|---|---|
| Video Frame Rates | - | Better than 30fps of gamma corrected 24bit color frames for at least 2x2 64x32 LED panels |
| Understand system demand | - | Study overall system performance so we know how this will behave with various peripherals and panel configurations |
| - | Use P2 internal ram resources | Study driver use of COG Registers, LUT RAM, and HUB RAM |
| - | w/P2 Eval HyperRAM | Will we need, can we benefit from using HyperRAM / External RAM? |
| - | w/uSD Storage | What is our performace displaying images / video directly from the P2 uSD card? |
| - | w/Receiving image data from RPi | Is the RPi SPI interface sufficient to keep our panels streaming video? |
| Reusable Driver | - | Ensure driver can be configured for (1) single panel size, (2) organization of multi-panel chains, and (3) the various panel chip-sets which require different clocking styles (within practical limits: all panels must use the same chip-set) |
| long-term | - | Can we drive multiple panel chains - we have 64 GPIO pins on the P2... we should easily be able to connect 3 HUB75 adapters. Can we drive them all at video frame rates? What is our limitation here? |
NOTE: Initial turn-on of the pasm2 driver code (1st draft reasonably performant code, not the fastest possible) shows that I'm getting a 400fps rate with 3 bit color. So far this means that before tuning we might be able to get 50fps of 24bit color for single panel. For a 4x4 panel this means we might get 12.5fps to 33fps depending upon our color depth.
Remember, this is without yet tuning the driver for best performance based on what the chip can do. Based on the limits of the panel chipset, for the panels on this project, I should be able to drive the panel itself around 1.7x faster than I am in the 1st draft code. So, there's room to get better here.
If you find this kind of written explanation useful, helpful I would be honored by your helping me out for a couple of ☕'s or 🍕 slices -or- you can support my efforts by contributing at my Patreon site!
Since the project goals are going to be speed related, I'm going to need a better than flying leads to get to my higher speeds... so I'm building this Eval Adapter board:
On this board you see 3.3v to 5v level shifters. I found that at higher speeds the clock, latch and OEb signals were falling below the signal threshold. This was a great exercise in Logic Analyzer use as I had originally set my input thresholds for 3.3v signals and of course they looked perfectly timed. When I couldn't get reliable shifting and latching a had the thought that I'm dealing with 5v logic on the panels. Silly me, I had the LA configured for the output logic form, not the panel form of signal. So I switched to 5v threshold and then immediately saw that I was not at all clocking cleanly. quickly interposed the level shifer pcb that I had laying around and all the signals snapped to, as I really needed to see! I was back in the land of the code I write now drives the signals I expect... whew!
The boards arrived from JLCPCB! After determing that mechanically they fit Figure (1) below, then I built one up - Figure 2 and then after some power and ground double checks, I connected the new adapter PCB - Figure (3), lastly I connected up the Logic Analyzer flying leads so that I can verify all of the control/data signals to the panel - Figure (4).
It turned on completely. It also scared me at first (you'll notice that it's on a different connector than my original flying leads test setup.) This caused my driver to have a few hickups as I was straightening out what the new pins were!
But, I can't complain. After the driver issues were "sorted" this 1st run of boards turned out to be 100% functional. It's a good feeling!
One of the projects the P2 community is working on is a 6-sided cube of 64x64 panels. I'm certifying the driver for use on this P2 Cube project.
The P2 Forum Thread is found here: P2 P2 Cube
And the repository for design and physical objects is found here Repository: P2 P2 Cube
This is the back of my 6 x 64x64 panel driven with a 5V 60A power supply so we can test full display Brightness.
This is a snapshot of the 6 x 64x64 panel showing the driver configured for a single panel display - the pic is a shot of an animation taking place. The 1/6th panel to the right contains the correct display the remaing 5 panels to the left are receiving the same data... just one for offset for each further panel to the left.
The next panel configuration i'm planning on playting with is daisy-chaining 4 of these panels so I can play with larger images. Here you see three more panels waiting for the fourth to be moved from the bench to join them.
- I was encouraged by published work by Rayman (found on the Parallax Forums) where he wrote initial propeller v1 spin/pasm code to demonstrate how to drive his matrix panel. I found the article linked to from the AdaFruit website.
Licensed under the MIT License.
Follow these links for more information: