Has anyone used https://github.com/2dom/PxMatrix


Yes another RGBpanel driver I didn’t know about.
It supports ESP8266 which SmartMatrix doesn’t, and also ESP32.
What’s interesting is that it connects output output wires to input wires. It looks like it’s meant to shift bits from one color to the next.
output R0 goes to input R1
output R1 goes to input G0

output B0 goes to input B1
As far as I can tell this allows using a single color output wire to shift bits across all shift registers to the last color half.
This seems quite inefficient and 6 times slower unless I’m missing something.

It does say “we can use the hardware SPI interface to drive it.”. I’m not sure if it allows outputting 6x faster or more as a result to compensate for the longer shifts. Chaining panels will also be a bit of a mess.

According to this, it may support extra panels that SmartMatrix does not support:
“Secondly, you may have to specify a different scanning pattern to the default LINE scanning. This can be achieved by calling display.setScanPattern(x) where x={LINE, ZIGZAG, ZAGGIZ, WZAGZIG, VZAG}. Finally, your panel may not handle BINARY row multiplexing by itself but we need to handle it in the library and select rows STRAIGHT via the A,B,C,D lines. This can be achieved by calling display.setMuxPattern(x) where x={BINARY, STRAIGHT}. So for some very strange displays you may have execute:”

It also support ESP8266, which is a plus.

Other thoughts?


Do not waste your time with that library. To efficiently manage these LED panels it is essential to use DMA in the programming. Something that is not seen anywhere in that library.

Probably if support some extra panels not supported by Smartmatrix, are those based on ICN2038S and FM6126 controller chips that require three extra clock pulses for each Latch.


I haven’t used it but I do know about it. I thought it was a clever way of working around some of the ESP8266’s hardware limitations. My way of working around their limitations was to not use the platform, and wait for the ESP32.


@pinballsp thanks for the quick review. That said, it claims to use SPI, and you can do DMA for SPI, although that driver may not.
@Louis point taken on the “clever way to work on ESP8266”, but obviously it won’t be as far as using parallel driving on ESP32 or teensy, the way it was meant to be driven.
I’m also surprised that it seems to get away with not using level shifters. That probably does not work with all panels due to logic level differences.


I’m not convinced that way to control LED panels. It is much more efficient to control the data signals by DMA, in parallel, with the 6 Data Lines (RGB1, RGB2) + Clock, than having to chain all the data lines with a serial communication. In addition, that requires special wiring, instead of using conventional flat cables.

Also if you do not use DMA, the CPU is constantly busy sending data, that can affect the performance if the circuit has to receive and process data from the outside to show the images or animations.


You don’t have to convince me that DMA is better than bit banging :slight_smile: I was simply wondering if that solution somehow by using SPI, could push data quicker than other pins that might do DMA at a slower speed.
For instance, there is a teensy way to do neopixels using DMA via a serial port, which is actually slow, despite being DMA (but just fast enough for that use).
Ultimately, I am still interested in the fastest way to refresh RGBpanels to get the highest frame rate possible and avoid the unsightly bars that I otherwise get when I take pictures (and solutions that use FPGAs indeed refresh fast enough that it’s not an issue there).
But point has been made that this solution is not it, starting of course by the fact that it has to send 6 times more data on the same wire, and assuming that the way it does it is not more than 6 times faster.