SmartMatrix doesn't support FM6126A driver chips

Hi @Louis and @pinballsp

As a followup to P3-6432-2121-16S-D1.0 panels don't work at all

I was working with a chinese vendor who sent me a batch of returned RGBPanels that people couldn’t get working with arduino solutions

Then I found this comment
“The chips on this board are FM6126A. To drive them from a ESP8266 based Wemos D1 Mini Pro, I had to use the updated PxMatrix library from github (update as-of Jan 29, 2019), and change the code in the setup in my sketch, and a call to display.setDriverChip(FM6126A)”

I had a look in the lib, and found this code that’s different:

Amongst other things, the chip needs to be configured before taking to it, and then the protocol seems slightly different.

Given that the work has been done in PxMatrix, would it be easy enough to add in SmartMatrix?

opened bug

This blog posts seems to have made it those panels work with SmartMatrix on teensy:

I just ported this file so that it works on my rPi, ran it, and then plugged my Teensy with SmartMatrix code (unmodified), and things just worked.
So this confirms that the only problem is indeed the init necessary with those FM6126A chips:

And here is a somewhat working reset script for teensy that I adapted from

I’m working on integrating FM6126A Reset into SmartMatrix Library. I’m operating under the assumption that this reset sequence can be sent at the beginning before matrix.begin() is called (or during matrix.begin()), and doesn’t need to be sent any any point later in the sketch. Do you agree?

I only see two exceptions to this:

  • If there is a power issue that allows the SmartMatrix sketch to keep running, but puts the FM6126A chips back to their default config
  • If someone hot-swaps panels while the sketch is running, or applies power to their panel after powering up their micro controller running SmartMatrix

If I implement the FM6126A reset only at the beginning, the only solution to these exceptions happening is to reset the microcontroller, starting the sketch over at the beginning where the reset sequence is sent. Is that acceptable?

As discussed on the bug, it would be good for the vast majority of cases.
I can see times where it would be helpful to send a reset at runtime though. You said it would be tricky if there is a latch, but for those of us that are using simple direct wiring, no such issue, so maybe supporting it for at least direct wiring would be easy enough?

Yep, should be possible. Easy? Not so sure. Would need to pause DMA, switch the lines over to GPIO, toggle the lines, switch back, enable DMA again, hopefully not noticeably flicker. I’ll implement the easy way first, and keep the runtime option for later.

+1 to easy way, that’s the only one I need.
As for runtime, if there is flicker

  1. who cares :slight_smile:
  2. will there even be flicker given that before applying the reset, the panels will be dark anyway?

Either way, once at startup is all I care about for my usage pattern anyway.

There’s some updates here, describing FM6126A support that’s stable for Teensy, and experimental with ESP32. I’d appreciate feedback on the ESP32 support if you’re trying it yourself as I only have one panel here.

replied on the issue, didn’t work for me with direct wiring on ESP32

@Louis I took apart another project with FM2616 and it’s currently wired into an ESP32 for testing. Do you think you’d have code to test in a day or two at most, or should I put everything back together?
(to be clear, I don’t need this myself anymore, my FM2616 panels are plugged into rPis)

Thanks for going out of your way to test Marc! I’ll reply on the issue with some more things to test if you have time