128x64 1/32 ICN2037BP panel: strange (non)use of the E line

[rigorka]

I have a strange 128x64 1/32 ICN2037BP panel which works fine with the native Huidu WF2 firmware, but when it is used with this library the 0..15 and 32..47 rows are displaying the correct image but the 16..31 and 48..63 rows of the panel are always black.

Furthermore, if we call fillScreen() with any color to fill the entire DMA buffer with the same values we'll still see two 16-pixels-high illuminated strips on the panel, interlaced with two 16-pixels-high black strips.

I've tried both direct use of the MatrixPanel_I2S_DMA and the use of VirtualMatrixPanel in a single panel mode with the FOUR_SCAN_64PX_HIGH scan mode (I've tried others too, and this one produced the best results). The direct use of MatrixPanel_I2S_DMA understandably results in x coordinates mix-up, while VirtualMatrixPanel sorts x coords out and I see a perfect image, just with two 16-pixels-high strips missing from it.

ESP32S3 pins are assigned as follows:

#define R1 46
#define G1 38 
#define BL1 4
#define R2 16
#define G2 15
#define BL2 39
#define CH_A 18
#define CH_B 8
#define CH_C 45
#define CH_D 21
#define CH_E 17 
#define CLK 41
#define LAT 48
#define OE 2

and the panel configuration is

#define PANEL_RES_X 128
#define PANEL_RES_Y 64
  
#define NUM_ROWS 1
#define NUM_COLS 1

Whatever I do, I can not get rows 16..31 and 48..63 to illuminate. However, if I manually bring the E pin of the panel HIGH, then the situation changes to the opposite: the rows 16..31 and 48..63 are now illuminated but the rows 0..15 and 32..47 are black.

When I try to check the signal timings on the A,B,C,D,E lines coming from ESP32S3, I observe the following:
line A:

line D:

line E:

The above observations making me think that this panel can be controlled successfully with this lib, as we have control over the E data line and we clearly can use this line to illuminate the dark areas of the panel. So that has to do something with the way the pixel data is prepared in the DMA buffers. Any suggestions as to how to proceed from this point will be much appreciated.

[board707]

Hi
As you understand, 64 pixels high panel needs the 5 multiplexing lines - A B C D E. However, if you switch it to "four scan" mode, it doesn't need a E line.
Therefore, the mode FOUR_SCAN_64PX_HIGH can't used with this panel, I think, because "four scan" means that you don't use a E pin for this panel.

[rigorka]

Hi @board707, thanks for your input, but looking at the code gets me confused: scan modes are defined in VirtualMatrixPanel which is only responsible for the coordinate transformations and can not affect the core MatrixPanel_I2S_DMA operation. Hence whatever scan mode I choose, the DMA buffers config and the usage of pins should not be affected.

My problem with this panel (two 16-pixels-high black strips) is perfectly reproducible when I'm trying to use the MatrixPanel_I2S_DMA alone with no VirtualMatrixPanel and hence without any mentioning of the the "four_scan".

I believe to disable the E pin in DMA one has to set CH_E to -1 which I did not do.

Furthermore, the signal diagrams above show some usage of E pin, just the timing seems very strange (short). When I disable the E pin completely by setting CH_E to -1, the spikes on the last diagram disappear completely too.

[rigorka]

Okay, solved it. I was barking up the wrong tree, sorry. The problem was in this piece of code left over from four-scan panel:

  HUB75_I2S_CFG mxconfig(
              PANEL_RES_X*2,              // DO NOT CHANGE THIS
              PANEL_RES_Y/2,              // DO NOT CHANGE THIS
              NUM_ROWS*NUM_COLS           // DO NOT CHANGE THIS
                ,_pins
  );

This indeed makes the use of the E multiplexing line impossible, at the row count in MatrixPanel_I2S_DMA for 64-rows-high will never go over 15. Fixing the above to a regular two-scan config:

  HUB75_I2S_CFG mxconfig(
              PANEL_RES_X,
              PANEL_RES_Y,
              NUM_ROWS*NUM_COLS
                ,_pins
  );

solved the matter.