SmartMatrix doesn't support FM6126A driver chips

marcmerlin · April 17, 2019, 4:05am

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

I was working with a chinese vendor who sent me a batch of returned RGBPanels that people couldn’t get working with arduino solutions
http://amazon.com/panels-digital-module-display-P3-19296mm/

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:

github.com

2dom/PxMatrix/blob/master/PxMatrix.h#L84


      
          #endif
          
          

          

          
#ifdef ESP8266
            #define GPIO_REG_SET(val) GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS,val)
            #define GPIO_REG_CLEAR(val) GPIO_REG_WRITE(GPIO_OUT_W1TC_ADDRESS,val)
          #endif
          #ifdef ESP32
            #define GPIO_REG_SET(val) GPIO.out_w1ts = val
            #define GPIO_REG_CLEAR(val) GPIO.out_w1tc = val
          #endif
          #ifdef __AVR__
            #define GPIO_REG_SET(val) (val < 8) ? PORTD |= _BV(val) : PORTB |= _BV(val-8)
            #define GPIO_REG_CLEAR(val) (val < 8) ? PORTD &= ~_BV(val) : PORTB &= ~_BV(val-8)
          #endif
          
          
#ifdef ESP32
          
          
  #include "soc/spi_struct.h"
            #include "esp32-hal-gpio.h"

github.com

2dom/PxMatrix/blob/master/PxMatrix.h#L313


      
            // Holds the scan pattern
            scan_patterns _scan_pattern;
          
          
  // Holds the block pattern
            block_patterns _block_pattern;
          
          
  // Holds the used driver chip
            driver_chips _driver_chip;
          
          
  // Used for test pattern
            uint16_t _test_pixel_counter;
            uint16_t _test_line_counter;
            unsigned long _test_last_call;
          
          
  // Generic function that draw one pixel
          inline void fillMatrixBuffer(int16_t x, int16_t y, uint8_t r, uint8_t g,uint8_t b, bool selected_buffer);
          
          
  // Init code common to both constructors
          inline void init(uint16_t width, uint16_t height ,uint8_t LATCH, uint8_t OE, uint8_t A,uint8_t B);
          
          
  // Light up LEDs and hold for show_time microseconds

github.com

2dom/PxMatrix/blob/master/PxMatrix.h#L372


      
          
          
_color_R_offset=0;
          _color_G_offset=0;
          _color_B_offset=0;
          
          
_test_last_call=0;
          _test_pixel_counter=0;
          _test_line_counter=0;
          _rotate=0;
          _flip=0;
          _fast_update=0;
          
          
_row_pattern=0;
          _scan_pattern=LINE;
          _block_pattern=ABCD;
          _driver_chip=SHIFT;
          
          
_mux_delay_A=0;
          _mux_delay_B=0;
          _mux_delay_C=0;
          _mux_delay_D=0;

github.com

2dom/PxMatrix/blob/master/PxMatrix.h#L884


      
                total_offset_r--;   
            }
          
          
  // Byte split pattern (lower part)
            if (_scan_pattern==ZZAGG)
                if (bit_select>3) total_offset_r--;
          }
          else
          {
          
          
  if (_scan_pattern==ZIGZAG)
              total_offset_r--;
          
          
     // Byte split pattern - like ZAGZIG but after every 4 bit (starts on upper part)  
            if (_scan_pattern == ZZIAGG )
            {
          
          
    if (bit_select>3)
              {
                total_offset_r--;
                bit_select -=4;

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?

marcmerlin · April 17, 2019, 4:44am

opened bug FM6126A chip support · Issue #78 · pixelmatix/SmartMatrix · GitHub

marcmerlin · April 20, 2019, 10:37pm

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

marcmerlin · April 20, 2019, 10:55pm

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:
https://github.com/hzeller/rpi-rgb-led-matrix/files/3100669/resetmatrix_adafruit.py.txt

marcmerlin · April 20, 2019, 11:50pm

And here is a somewhat working reset script for teensy that I adapted from
http://bobdavis321.blogspot.com/2019/03/teensy-31-and-smartmatrix-sd-running.html:
https://github.com/marcmerlin/SmartMatrix/blob/FM6126A/examples/FM6126A_reset/FM6126A_reset.ino

Louis · October 31, 2019, 2:01pm

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?

marcmerlin · November 3, 2019, 5:59pm

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?

Louis · November 4, 2019, 11:17pm

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.

marcmerlin · November 4, 2019, 11:36pm

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

who cares
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.

Louis · May 15, 2020, 4:53pm

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.

marcmerlin · May 17, 2020, 11:40pm

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

marcmerlin · May 18, 2020, 7:26pm

@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)

Louis · May 18, 2020, 8:25pm

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