New P2, 1/32 Scan, 64*64, Led panel with different IC chip controller

pinballsp · June 1, 2018, 5:03pm

Hi. Louis.

The Chinese have release a new LED panel P2, 64*64, 1/32 Scan, with a new driver chip, the ICN2038S, apparently the panel looks identical, but when connected to Smartmatrix, the screen is completely black.

The Chinese do not provide any information, data sheet, schemes, support is null. So I must apply some reverse engineering to know what happens.

I have ordered a complete set of LINSN boards to test the panels with a PC computer, Led Studio software and the RCG file that defines how to control the Led panel. So I can start it and when the image comes out, capture the signals with a Logic Analyzer to see what the differences are.

In any case, I have looked at the data sheets of both chips, ICN2038 and ICNM2038S, and I think I already know what is different.

The Latch signal (LE) can be used to send commands in addition to operating as Latch to transfer the input data to the outputs of the shift register. In ICN2038, the LE signal works as Latch when it is at a high logic level for ONE clock pulse, but in the new ICN2038S the LE signal will work as Latch when the signal is at a high logic level for THREE clock pulses.

So, I think this is the difference between these two chips, how many clock pulses LE is at high level.

According to the Chinese, the ICN2038 chip has stopped being manufactured and has been replaced by the ICN2038S. So, if the sources are not modified, will not be able to work with the P2 panels of 64x64, 1/32 Scan. I do not know if this will affect other dot pitch Led panels 64x64. Now I have here 1000 USD in P2 Led panels that fail with Smartmatrix, black screen, all with ICN2038S controller chip.

My question is, where can I modify in the source files how many clock pulses the Latch (LE) signal is at high level ?

I attach captures of the datasheet of both chips, ICN2038 and ICN2038S, both the information in text and in graphic mode with timelines.

ICN2038_001

ICN2038S_001

pinballsp · June 3, 2018, 1:11pm

Yesterday I was doing a lot of tests to know how these new Led P2 panels work, which fail with Smartmatrix. I made a small program for Teensy 3.5, and after many modifications I got the panel to work, it was quite complicated to discover the correct way to send signals to this panel.

As I thought, according to the ICN2038S chip data sheet, after sending the data to the chip’s shift register buffer, the Latch signal must be set high, but unlike other chips, the ICN2038S requires three clock pulses while the Latch signal is at a high level.

At first I thought it was enough to send these clock pulses only once at the beginning of the program, to activate the Latch signal, in which case I would not need to modify the Smartmatrix sources, it would only include the sequence of instructions in my program. But the truth is that this is not the case, as long as the Latch signal is set to a high logical level, it is necessary to send three clock pulses, so that the data of the buffer of the shift register goes to the chip output and turn on the LED.

In my test program, after loading the shift register buffer, I do the Latch with these instructions to execute three clock pulses, and it works fine.

digitalWriteFast(LATCH, 1);
for (int p = 0; p < 3; p++)
{
digitalWriteFast(CLK, 1);
for (int zz = 0; zz < 7; zz++) asm volatile(“nop\n”);
digitalWriteFast(CLK, 0);
}
digitalWriteFast(LATCH, 0);

Now the issue is where to add it to the Smartmatrix sources, I think it is in some interruption routine, it may be linked to DMA. I suspect that it is in the SmartMatrix_Impl.h source code, but it is quite complex, and I still do not know where is the routine that runs when Latch rising edge.

Louis · June 4, 2018, 11:20am

With the Teensy, it’s not going to be easy to add exactly three clocks while the latch is high. The latch signal is controlled by a timer, and the latch rising edge triggers the start of the DMA transfer. There’s a variable amount of time between the trigger and the start of DMA, so if you have a fixed width latch pulse and DMA is generating continuous clocks, you’ll get a variable number of CLK pulses while latch is high. You’ll likely need to add your three clock pulses at the beginning of the (next row’s) DMA transfer, then add some padding where CLK is low to account for the variable latency from latch rising edge to the DMA transfer starting.

There’s likely still a problem even if you make all the code changes, as the OE signal is enabled right when latch goes high, and you’ll likely be displaying the previous data briefly if OE is enabled before the latch cycle’s three clocks are sent out.

I’ve done significant refactoring of the Teensy code in the “teensylc” branch, and I’d suggest using that code going forward as it will be easier to make your changes. However, there might be some problems lurking in that branch as it hasn’t been tested as much as the other code. The next major SmartMatrix Library release will be merging the teensylc branch.

You can change the width of the latch pulse here (use a scope with persistence turned on and figure out the min and max latency so you can set the width appropriately):

github.com

pixelmatix/SmartMatrix/blob/teensylc/src/MatrixHardware_KitV4.h#L36


      
          #ifndef MATRIX_HARDWARE_H
          #define MATRIX_HARDWARE_H
          
          
#define DMA_UPDATES_PER_CLOCK           2
          #define ADDX_UPDATE_ON_DATA_PINS
          #define ADDX_UPDATE_BEFORE_LATCH_BYTES  1
          
          
/* an advanced user may need to tweak these values */
          
          
// size of latch pulse - can be short for V4 which doesn't need to update ADDX lines during latch pulse
          #define LATCH_TIMER_PULSE_WIDTH_NS  100
          
          
// max delay from rising edge of latch pulse to falling edge of clock
          // increase this value if DMA use is delaying clock
          // using largest delay seen at slowest supported clock speed (48MHz) 1400ns, saw 916ns at 96MHz
          #define LATCH_TO_CLK_DELAY_NS       1400
          
          
// measured <3400ns to transfer 32 pixels at 96MHz, <6600ns to transfer 32 pixels at 48MHz
          // for now, until DMA sharing complications (brought to light by Teensy 3.6 SDIO) can be worked out, enable DMA Bandwidth Control, which approximately doubles this estimated time
          #define PANEL_32_PIXELDATA_TRANSFER_MAXIMUM_NS  (uint32_t)((2 * 3400 * 96000000.0) / F_CPU)

Are you using the old SmartMatrix Shield V3 pinout without an external latch? If so you’ll need to increase the size of the data array member in this struct, increase the number of bytes that are shifted out using DMA, and change the matrix calculation code to load data with an offset to leave room for your latch clocks and padding.

github.com

pixelmatix/SmartMatrix/blob/teensylc/src/SmartMatrixMultiplexedRefreshTeensy.h#L48


      
                  uint16_t bits_to_set;
              };
          
          
    // gpiopair is 2x uint32_t to match size and spacing of values it is updating: GPIOx_PSOR and GPIOx_PCOR are 32-bit and adjacent to each other
              struct gpiopair {
                  uint32_t  gpio_psor;
                  uint32_t  gpio_pcor;
              };
          #endif
          
          
    struct rowBitStruct {
                  uint8_t data[PIXELS_PER_LATCH * DMA_UPDATES_PER_CLOCK];
                  uint8_t rowAddress; // must be directly after data - DMA transfers data[] + rowAddress continuous
                  timerpair timerValues;
          #ifndef ADDX_UPDATE_ON_DATA_PINS
                  addresspair addressValues;
          #endif
              };
          
          
    struct rowDataStruct {
                  rowBitStruct rowbits[refreshDepth/COLOR_CHANNELS_PER_PIXEL];

Calculation code that writes to the data array is here (keep in mind there’s a nearly duplicate function that needs to be modified if you need 24-bit color support):

github.com

pixelmatix/SmartMatrix/blob/teensylc/src/SmartMatrixMultiplexedCalcTeensy_Impl.h#L342


      
          template <int refreshDepth, int matrixWidth, int matrixHeight, unsigned char panelType, unsigned char optionFlags>
          int SmartMatrix3<refreshDepth, matrixWidth, matrixHeight, panelType, optionFlags>::getMultiRowRefreshNumPixelsToMap(void) {        
              static const PanelMappingEntry * map = getMultiRowRefreshPanelMap(panelType);
          
          
    return map[multiRowRefresh_mapIndex_CurrentPixelGroup].numPixels;    
          }
          
          
template <int refreshDepth, int matrixWidth, int matrixHeight, unsigned char panelType, unsigned char optionFlags>
          int SmartMatrix3<refreshDepth, matrixWidth, matrixHeight, panelType, optionFlags>::getMultiRowRefreshPixelGroupOffset(void) {        
              static const PanelMappingEntry * map = getMultiRowRefreshPanelMap(panelType);
          
          
    return map[multiRowRefresh_mapIndex_CurrentPixelGroup].bufferOffset + multiRowRefresh_PixelOffsetFromPanelsAlreadyMapped;
          }
          
          
template <int refreshDepth, int matrixWidth, int matrixHeight, unsigned char panelType, unsigned char optionFlags>
          INLINE void SmartMatrix3<refreshDepth, matrixWidth, matrixHeight, panelType, optionFlags>::loadMatrixBuffers48(rowDataStruct * currentRowDataPtr, unsigned char currentRow) {
              int i;
              int multiRowRefreshRowOffset = 0;
              const int numPixelsPerTempRow = PIXELS_PER_LATCH/PHYSICAL_ROWS_PER_REFRESH_ROW;
          
          
    // static to avoid putting large buffer on the stack

This isn’t going to be an easy task. If you can just use panels with the (working?) ICN2038 chips instead of ICN2038S, I think that’s a better way to go. If you do intend to start on this, I suggest initially just replacing the first handful of bytes in the data array with the code to just pulse clock three times with padding, and see if that works. Your panel will be refreshed with less than the width you wanted as some of the CLKs were removed. Later you can expand the data array and add the offset.

If you’re using the SmartLED Shield V4 pinout or plan to in the future, I’m not sure how well these panels will work. V4 uses a flip flop to capture the ADDX signals on the rising edge of the latch signal, and I’m not sure how adding a few clock cycles while latch is high will affect things. On the ESP32 an external latch is used instead of flip flop, and that captures on the falling edge. If you can still output the ADDX values over the RGB lines while latch is high and the three CLKs are sent it might work OK.

pinballsp · June 4, 2018, 8:19pm

Ok, thank you Louis, for your support.

The source code in the “teensylc” branch is compatible with Teensy 3.6 and SmartMatrix Shield V3 ?, My hardware is based on Shield V3 without external latch.

About the use of LED panels with ICN2038, it would be ideal, but according to the Chinese distributors, the manufacturer CHIPONE has stopped making the chip ICN2038, replaced by the new ICN2038S. Some providers still offer LED panels based on ICN2038 and ICN2028BP, but as soon as they are out of stock, they will have to use the ICN2038S.

One of my suppliers, currently only offers LED panels P2 and P2.5 with ICN2038S, so I can not order any LED panel to this provider. I have a second provider, this still offers P2 with ICN2038 and P2.5 with ICN2028BP, both work well with Smartmatrix. But I guess as soon as they are out of stock, they will also install ICN2038S on all the LED panels, and there will be no way for the product to work using Smartmatrix.

Therefore, I want to solve this problem as soon as possible, to be able to use LED panels with chip ICN2038S and Smartmatrix. I know that this affects at least panels P2 and P2.5, I do not know if also other sizes of panels.

I will try all your suggestions, thanks.

My only questions are the following:
1.- Is the branch “teensylc” fully compatible with Teensy 3.6 and Shield V3 without external latch ?.
2.- Can I replace my current Smartmatrix library with the “teensylc” branch ? If this affects my software by the configuration parameters.
3.-The “teensylc” branch supports Led Panels 1/32 Scan 64*64 with Shield V3 ?

Sincerely

Louis · June 4, 2018, 9:04pm

the manufacturer CHIPONE has stopped making the chip ICN2038, replaced by the new ICN2038S

That’s unfortunate, I hope it doesn’t cause problems for many SmartMatrix users

1.- Is the branch “teensylc” fully compatible with Teensy 3.6 and Shield V3 without external latch ?.
2.- Can I replace my current Smartmatrix library with the “teensylc” branch ? If this affects my software by the configuration parameters.

Yes to both, it should work identical to the main branch and latest release

3.-The “teensylc” branch supports Led Panels 1/32 Scan 64*64 with Shield V3 ?

No, you’ll have to make some changes yourself. It does support 1/32 scan support with SmartLED Shield V4, so some of the work is done, but you still need to drive an additional address pin and load the value.

pinballsp · June 5, 2018, 3:37am

Ok, thanks Louis. I will try all your suggestions.

About the driver chips, I do not know exactly how many there are. In my LED panels P2 and P2.5, I see ICN2038, ICN2038S and ICN2028BP, but I think there are more. I also have the data sheet of the MBI5038, compatible with the ICN2038.

The manufacturers of LED panels, they do it mainly to assemble large screens, for sporting events, political rallies, musical concerts, billboards. There are several commercial systems to use these panels, with PC computers and Led Studio software, I know Nova and Linsn, they provide RCG files to configure any LED panel with this software. I recently bought a set of Linsn plates (quite cheap in Chinese vendors.) to check LED panels and apply reverse engineer if it is necessary to know how the new chip controllers work.

The problem is to create your own hardware / software system, as in this case with Smartmatrix, because manufacturers of LED panels or chip controllers such as CHIPONE, do not provide any kind of technical information, there is no data sheet (some are found by Google), diagrams or even a simple pinout. Also, they do not respect the HUB75 standard, so you can find panels that are RGB, BGR, RBG, BRG, etc., this feature can be configured by software, to get the correct colors, the problem is if they also change the format of the control signals, as in this new chip that requires 3 clock pulses for each latch.

I am also looking forward with interest, the new RT1020 microcontroller from NXP that is already on sale on the 26th of this month. I think it is the one that will use the new Teensy 4.0, and it would be very interesting to make a Smartmatrix to this microcontroller, because it is extremely powerful and cheap, it is a Cortex M7 at 500Mhz. If it is not officially done, I will try to do it, I just have to learn to configure and use the DMA well and I could try it.

If I get the panels working with the ICN2038S chip, modifying Smarmatrix, I will publish the modifications of the source code, so that anyone can use it, also if I decide to port the sources to the RT1020.

Greetings

pinballsp · June 5, 2018, 9:06am

I have start to modify source code to add my modifications for 1/32 Scan led panels. But I found some differences in sources, some no more available.

1.- MatrixHardware_KitV1.h, this seem same, I add following:

#define ADDX_PIN_4 10
#define ADDX_PIN_MASK ((1 << ADDX_PIN_0) | (1 << ADDX_PIN_1) | (1 << ADDX_PIN_2) | (1 << ADDX_PIN_3) | (1 << ADDX_PIN_4))

#define ADDX_TEENSY_PIN_4 37

2.- Some defines like SMARTMATRIX_HUB75_64ROW_MOD32SCAN are not in SmartMatrix.h, but in SmartMatrixMultiplexedCommon.h

This is correct for Shield V3 without external Latch ??.
At any rate, I see that this source already include “defines” for 1/32 Scan led panels.

3.- SmartMatrix_Impl.h source not available. I have look for ADDX_PIN to add my modifications, and seem now are in the source file SmartMatrixMultiplexedRefreshTeensy_Impl.h

Difference, is that now all ADDX_TEENSY_PIN_ are with #ifdef
I do not know if need some special consideration to add my modifications.

I simply add following to source code:

#ifdef ADDX_TEENSY_PIN_4
pinMode(ADDX_TEENSY_PIN_4, OUTPUT);
#endif

#ifdef ADDX_PIN_4
if (i & 0x10) addressLUT[i].bits_to_set |= (1 << ADDX_PIN_4);
#endif

Louis · June 5, 2018, 9:37am

You can use the “preformatted text” tool to make your code easier to read. It looks like </> in the toolbar.

Your modifications look good.

The major difference between V4 and V3 board support is the V4 header has this definition: ADDX_UPDATE_ON_DATA_PINS. You’ll see #ifdef/#ifndef ADDX_UPDATE_ON_DATA_PINS a lot in the code, otherwise they use the same files.

Louis · June 5, 2018, 9:44am

When you get it working, please do a pull request or send me a link to your github files, or just let me know the changes you made. I can put the changes into the teensylc branch, as now that I added the #ifdef ADDX_TEENSY_PIN_X and #ifdef ADDX_PIN_X macros, I can include support for /32 scan with SmartMatrix Shield V3 in the source files and people like you that need it can just easily modify the hardware header file to add definitions for pin 4.

pinballsp · June 5, 2018, 10:09pm

Ok, Louis.
What I need configure in Teensylc branch and in my software to do it work with Shield V3 ?
In my current software, I add these includes for Smartmatrix compatible Shield V3.

#include <SmartMatrix3.h>
#include <MatrixHardware_RGB_DMD.h>

The second is a customized version of MatrixHardware_KitV1.h

I must to learn yet how to manage Github to do a pull request, and what is it exactly. I hope that now that Microsoft has bought Github, this will continue to work for free, or at least I’m thinking about migrating to Gitlab

Louis · June 5, 2018, 10:24pm

As long as you don’t include <SmartLEDShieldV4.h>, you’re set for SmartMatrix Shield V3 compatibility.

Does that order of #includes normally work for you (e.g. with the previous version of the SmartMatrix Library you were using)? I’m not sure if that will work as MatrixHardware_KitV1.h will be included from <SmartMatrix3.h>.

I agree with you on GitLab in light of recent news. I don’t think Microsoft will get rid of the free repos, but I think they’ll ruin it somehow (like they did with Skype). It’s on my list to check out GitLab (though pretty low on the list).

pinballsp · June 6, 2018, 5:08am

Yes, in my software there are only those two includes and it works well.

The only inside my SmartMatrix3.h source is following:

#ifndef SmartMatrix3_h
#define SmartMatrix3_h

#include <Arduino.h>
#include "SmartMatrix.h"

Ok, so I keep everything the same in my software to compile with the new Smarmatrix Teensylc.

Do you know if there is any option in Arduino, to have both versions of Smartmatrix libraries and to be able to select which of the two compiles my program?

Louis · June 6, 2018, 3:48pm

You can copy the “SmartMatrix3.h” header file and give it a unique name, then replace #include <SmartMatrix3.h> with #include <SmartMatrix3Unique.h> in your sketch and Arduino should be able to figure out which library you mean to include. I’m not sure how #include <MatrixHardware_RGB_DMD.h> will affect things, you may need to give that a unique name as well to avoid confusing the Arduino IDE, and having it include the wrong SmartMatrix Library version if that filename is in two different libraries.

pinballsp · June 6, 2018, 4:20pm

ok, I’ll try it, thanks.

pinballsp · June 6, 2018, 11:32pm

Today I checked some more panels, P2.5 64*64 that I have here for a new project and a sample P3 that a supplier sent me.

I see there are some more driver chips, but all these work well with Smartmatrix. Datasheet available by Google.

P3, 64 * 32, installs ICN2028BP, the same one that install most of P2.5 64*32.
P2, 64 * 64, supplier 1, installs FM6124
P2, 64 * 64, supplier 2, install DP5220X
P2, 64 * 64, supplier 3, install ICN2028AP.

marcmerlin · April 17, 2019, 4:12am

It’s possible that PxMatrix may support AB panels according to this big of code:

github.com

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


      
          uint16_t _width;
          uint16_t _height;
          uint8_t _panels_width;
          uint8_t _rows_per_buffer;
          uint8_t _row_sets_per_buffer;
          uint8_t _panel_width_bytes;
          
          
// Color offset
          uint8_t _color_R_offset;
          uint8_t _color_G_offset;
          uint8_t _color_B_offset;
          
          
// Panel Brightness
          uint8_t _brightness;
          
          
// Color pattern that is pushed to the display
          uint8_t _display_color;
          
          
// Holds some pre-computed values for faster pixel drawing
          uint32_t *_row_offset;

Are you interested in trying it out and reporting back?

Louis · April 25, 2019, 2:39pm

@pinballsp I saw your post in this forum where you said you were able to modify SmartMatrix Library and get FM6126 support. I didn’t realize you actually got it to work, do you have any code to share, that maybe could be integrated into SmartMatrix Library in the future?

Also do you have a reliable source for a panel with FM6126 IC, or does it just depend on the batch when you order?

Christian2012 · September 2, 2019, 3:23pm

Hi, I am trying to use STM32 to drive the 64x64 RGB LED matrix using FM6124 chips, but I failed to turn on a “stable” pixel using GPIO simulation. I follow the procedure below:

All row selection lines (A,B,C,D,E) are low, OE high, LAT low, CLOCK low;
Select Row 1 and Row 32 by setting A=1, B=C=D=E=0;
Shift 64 bits (0xFFFFFFFFFFFFFFFF) out via R1 and R2 pin with clock;
LAT high and turn it into low after a few cycles;
OE low (Enable output).

Theoretically speaking, the procedure discribed above should turn on Row 1 and Row 32 with RED color stably, but these two lines just give me a quick “flash”.

What’s more, if the number of row I select is larger than 8, these two lines will be flicking…

Sorry to disturb you, hope can get some help here. Thanks.

pinballsp · September 3, 2019, 7:29am

Hello Louis.
Sorry for the delay in answering you, I had not logged in for a while and I didn’t see your question.

I was doing the tests, but outside the library, I was going to port it to Smartmatrix, but finally I decided to work on the development of code for the RT1020 microcontroller using MCUXpresso.

As for the order of LED panels, currently I only order for them with FM6124 controller chip, so I avoid compatibility problems.

pinballsp · September 3, 2019, 8:01am

May be you need add some delay between Clock high/low, or between Latch high/low.

Try adding a loop like this with “nop”, so you can control the delay in the nanosecond level with enough accuracy, modify the value of zz until the flicker stops:

for (int zz = 0; zz < 7; zz++) {asm volatile("nop\n");} // Retardo con nop

If you post the source code, we can see better what the problem is, but for the symptoms it seems a matter of lack of delays between Clock, Latch or OE signals.