Chipset ICN2037 / Driver 5958

[pyzimmer]

Hello, I bought this panel with SMD 2525 : https://fr.aliexpress.com/item/32836331716.html?spm=a2g0s.9042311.0.0.232f6c37cu1lnO

I am able to diplay something (1 line on 2) but unable to diplay test_pattern !

The seller said me to use 5958 decoding, i think it is that : http://www.ti.com/lit/ds/symlink/tlc5958.pdf

I send you picture the chips :

[pyzimmer]

When I unplugg A, B and C pins, and I touch them with my fingers, the test_pattern appears sometimes. Strange...

[pyzimmer]

Here is a video of unplug A pin : https://photos.app.goo.gl/4xqDg5gXukx6tXMZA

[pyzimmer]

I try to connect A, B, C to GND and to VCC, no way... The only way to get the test pattern is touching the wire with my fingers..

[pyzimmer]

Could you help me to understand datasheet of ICN2037 : http://en.chiponeic.com/content/details36_245.html
and state graphs : https://www.mikrocontroller.net/attachment/392914/ICN2037.pdf
For 74HC245 chip : https://assets.nexperia.com/documents/data-sheet/74HC_HCT245.pdf
And RT5957 : http://www.dlfushi.com/uploads/201805/5b03e7bc77f3a.pdf
thank you !

[pyzimmer]

The datasheet of 74HC245 specify that it has 3 states output (High Impedance) . I modify the code like that :

 if (_mux_pattern==BINARY)
  {
    if (value & 0x01){
	  pinMode(_A_PIN, OUTPUT);
      digitalWrite(_A_PIN,LOW);
    }else{
	  pinMode(_A_PIN, INPUT);
	  digitalWrite(_A_PIN, HIGH);
	}
	  
    if (value & 0x02){
	  pinMode(_B_PIN, OUTPUT);
      digitalWrite(_B_PIN,LOW);
    }else{
	  pinMode(_B_PIN, INPUT);
	  digitalWrite(_B_PIN, HIGH);
	}

    if (_row_pattern>=8)
    {
	  if (value & 0x04){
			pinMode(_C_PIN, OUTPUT);
			digitalWrite(_C_PIN,LOW);
		}else{
		  pinMode(_C_PIN, INPUT);
		  digitalWrite(_C_PIN, HIGH);
		}
    }

With this code I can display Test_pattern, but nothing else...

[pyzimmer]

I think it is a problem of voltage level. I will order 3,3->5v level shifter.

[pyzimmer]

No difference with the level shifter.
Any idea ?

[2dom]

If it works if you touch the wire it sounds like a grounding issue. Make sure that esp32 and panel ground are connected property.

[pyzimmer]

Thanks you, I was my first idea, but no way. I grounded, all unused pins and ESP32 to power supply ground, no way ! The only pins that I don't ground are Hub75 outputs... I will try !

[pyzimmer]

it does not work

[pyzimmer]

I think the issue is about the mux. Could you explain me in which order the chips are linked : ICN2037 , 74HC245, RT5957. Thank you.

[2dom]

Sorry ... very busy atm ....

[pyzimmer]

Chip ICN2037 is a 16 bits output register, your library use 8 bits , that's right ?
What should I modify in the code for 16 bits ? thanks

[texynz]

Seems to be related to issue 119 and the ICN 2037 chip although these should be fully compatible according to data sheets and don't require the triple clocking like the fm6126 and icn2038s. I have trying to work through the code and see where it fails. If I look at the comments by Brian in his article the issue relates to pin E required even though 16 scan, but I have set that and still not working. Can happily populate the even numbered rows 0,2,4,6 but not the odd 1,3,5.

[pyzimmer]

Thank you, I set 1/8 scan , because with 1/16 a white pix because 3 pix red, blue, screen. I connect ABC pins, E si grouded and D is usefull...

[pyzimmer]

hello, here is the result of :
display.fillScreen(WHITE);

@texynz : as you say : Can happily populate the even numbered rows 0,2,4,6 but not the odd 1,3,5.

[2dom]

Hi ..maybe this is related to #119 ? You could try adding some delay...

[pyzimmer]

thanks, i read it. I try adding 1/2 µs, before/after, A and C mux, no way

[texynz]

Instead of using the fillscreen function can you try just populating the rows manually in a for loop. As it is a timing issue, the fillscreen maybe adding additional timing.

[pyzimmer]

@texynz thank you, I try :

  for(int i=0; i<32; i++)
  {
  display.drawPixel(0, i, BLANC); 
  delay(500);
  }

strange result for a vertical line populating : https://photos.app.goo.gl/7nxpjen948Jk1UgK8
I try the same with a horizontal line populating and I is OK.

[2dom]

You can try the latest master. I added an option to control the delay in every stage of the multiplexing.

Try adding display.setMuxDelay(0,1,0,0,0); after display.begin() .

[pyzimmer]

Thank you for your work.
I try it, but no way, it has no effect, the same for a vertical line populating : https://photos.app.goo.gl/7nxpjen948Jk1UgK8

I try with :
display.setMuxDelay(1,0,0,0,0);
display.setMuxDelay(0,1,0,0,0);
display.setMuxDelay(0,0,1,0,0);
display.setMuxDelay(1,1,1,0,0);
display.setMuxDelay(0,5,0,0,0);

[pyzimmer]

The mario screen : some lines are missing, others are clone :

[pyzimmer]

hello, when I unplug Bmux wire, some new lines appears 3 times :

[pyzimmer]

I try to modify code of mux and latch, no way ! Any idea to modify the code of scan pattern ? thanks

[2dom]

Ok...try to re-assign the B Wire to a differen pin

[pyzimmer]

thank you for your help, same issue with pins 21, 22 or 23

[pyzimmer]

Hello,

Some new test, with this code :

for(int y=0; y<32; y++)
{
  display.drawLine(0,y,y,y, BLANC);
  delay(500);
}

line 1 should have 1 pixel,
line 2 should have 2 pixels,
...
However, i get this, with pin Bmux connected :

same code with pin Bmux unplug :

any idea ?

[pyzimmer]

expected result (did with another panel model) :

[pyzimmer]

I think the issue don't provide from ICN2037 chip, but from RT5957 like in this post: https://community.pixelmatix.com/t/led-module-p2-128-64-1-32-driver/414/5

[2dom]

Great work @xsrf ... Thanks for looking into this

[pyzimmer]

I check my wiring, It is good.
Maybe it is because :

• I use an ESP32 ?
• I use 3 panels of 3264 for total 32128
• my config is : display.setPanelsWidth(12); (pattern to emulate 4 little panels per panel)

I'll try your sequential wiring this afternoon

[xsrf]

I don't think ESP32 or ESP8266 would make much of a difference.
The latching pulse would be shorter because of the higher cpu frequency, but its length is the same for shiftout and SPI, so if it worked with the shiftout one, it should work with SPI too.
Maybe the shift register that does the muxing isn't as fast as the ones for the pixels. You may try to lower the SPI datarate e.g. to 2MHz just for testing... But with so many panels that may actually cause the watchdog to reset the CPU because it spends too much time with sending data...

#define PxMATRIX_SPI_FREQUENCY 2e6
#include <PxMatrix.h>

[pyzimmer]

I try with sequetial wiring, I is not better : https://photos.app.goo.gl/5NnexyGFxLynS23W6
I try with 2Mhz SPI, no change.
Sorry

[xsrf]

Interesting... I don't get why the mux data ends up in the pixels.
Are you using the pattern_test? Maybe that's the problem.
Have you tried with one of your regular sketches? displayTestPattern does some low level stuff that breaks the mux selection. That would actually explain the pattern :)

[pyzimmer]

Yes It was test_pattern.
Here is "ChroPro!" text :

instead of :

[xsrf]

okay, is this parallel or sequential wiring? Are you using fast update or not?

[pyzimmer]

Picture was sequential, parallel does the same.
Yes I use FastUpdate, without it get this :

I had to increase SPI freq to 16 Mhz, this can explain colored pixels.
Below 16Mhz my ESP crash

[xsrf]

Colored pixels can't be explained by this. This means that pixeldata actually got corrupted, usually because of noise on the data/clock lines. This is also a typical issue if your supply voltage is too high.
The ESP has 3.3V voltage levels. The logic on the panels typically is 5V and to register a logic level as HIGH it must typically be 0.7*Vcc which is 3.5V if you run on 5V. So all logic on the panels is already driven outside the specs...

But I guess you haven't changed anything on your power supply? If you can adjust your 5V supply, try to go lower and make sure your ESP has at least 3.3V. Just to make sure...

I need some time to think about what might cause pictures like this, especially the one with the red ghosting.... :)

[pyzimmer]

Okay,
I try again with parallel wiring : I get no diplay....

I don't have adjustable power suply
My power supply was 5.2v
I try with another of 4.9v -> same result
My ESP have 3.3v

[xsrf]

Hmm.. I've updated the code: https://github.com/xsrf/PxMatrix/tree/4fae26a12178a86949a12da6831dc248ab83eddf

You can now select from three mux patterns, SHIFTREG_ABC, SHIFTREG_SPI_PA and SHIFTREG_SPI_SE.

SHIFTREG_ABC is the one that used shiftout() and requires the regular wiring of A,B,C from the ESP to the display. Hope this one still works ;)

I'll do more investigations on timing. One critical factor actually is the time between latching row/pixel data and enabling outputs. This should be as high as possible...

The sequential wiring with three panels actually introduces a propagation delay for the row mux selection that may cause the row to be selected after LEDs were enabled.

[xsrf]

So, just to be clear here... Parallel/sequential wiring gives you exactly the same result.

fast_update on creates ghosting/bleeding across all 8 muxed rows which is most visible on red channel.

fast_update off creates actually the intended result but with random twinkling colorful pixels?

Can you provide the complete code for the ChroPro example? I'll grad an ESP32 and do some timing measurements there...

Also, despite the fact that it works most of the time, I wouldn't recommend a 5.2V power supply. Everything above 5V is way out of spec. The panel I have already starts twinkling at ~5.05V.

[pyzimmer]

So, just to be clear here... Parallel/sequential wiring gives you exactly the same result.

not exactly, but near

fast_update on creates ghosting/bleeding across all 8 muxed rows which is most visible on red channel.

yes

fast_update off creates actually the intended result but with random twinkling colorful pixels?

yes

Also, despite the fact that it works most of the time, I wouldn't recommend a 5.2V power supply. Everything above 5V is way out of spec. The panel I have already starts twinkling at ~5.05V.

There are 3 chips 74HC245 on every input pin, this chip play as level converter, no ?

Can you provide the complete code for the ChroPro example? I'll grad an ESP32 and do some timing measurements there...

my code :

//#define double_buffer false // = false pourse libraire < 1.5, ligne commentée pour libaririe >= 1.5
#define PxMATRIX_SPI_FREQUENCY 16000000
#define PxMATRIX_MAX_HEIGHT 32
#define PxMATRIX_MAX_WIDTH 192 // obligatoire à partir de la v1.5 pour 192px
#define PxMATRIX_COLOR_DEPTH 1
#include <PxMatrix.h> // https://github.com/2dom/PxMatrix
uint8_t display_draw_time=70; // temps d'affichage (70). Ignoré avec FastUpdate. Diminuer si aucun affichage, mais cela réduit la luminosité
uint16_t temps_rafraichissement=2000; // temps entre 2 rafaichissements (2000 µs) augmenter si aucun affichage, mais cela réduit la luminosité (2600 minimum pour 192*32 avec luminostié de 1800 lux)

#ifdef ESP32
#define P_LAT 4 // 22 // STB
#define P_A 19
#define P_B 23
#define P_C 18 // seulement pour scan 1/8, 1/16, 1/32
#define P_D 5 // seulement pour scan 1/16, 1/32
#define P_E 15 // seulement pour scan 1/32
#define P_OE 2 // STB
// CLOCK = SH = 14
// DATA = R1 = 13
#define SPI_BUS_MISO 21
#define SPI_BUS_CLK 22
hw_timer_t * timer = NULL;
portMUX_TYPE timerMux = portMUX_INITIALIZER_UNLOCKED;
#endif

// Pins for LED MATRIX
PxMATRIX display(192,32,P_LAT, P_OE,P_A,P_B,P_C);

uint16_t NOIR = display.color565(0, 0, 0);
uint16_t BLANC = display.color565(255, 255, 255);

#ifdef ESP32
void IRAM_ATTR display_updater(){
// Increment the counter and set the time of ISR
portENTER_CRITICAL_ISR(&timerMux);
//display.displayTestPattern(display_draw_time);
//display.displayTestPixel(display_draw_time);
display.display(display_draw_time); // temps d'affichage (70) diminuer si aucun affichage
portEXIT_CRITICAL_ISR(&timerMux);
}
#endif

void setup() {
display.begin(8); //{4,8,16,32}
display.setMuxPattern(SHIFTREG); // {BINARY, STRAIGHT, SHIFTREG}
//display.setScanPattern(VZAG); // {LINE, ZIGZAG, ZAGGIZ, WZAGZIG, VZAG}
display.setPanelsWidth(12);
//display.setFastUpdate(true); // aligne correctement les pixels sur la matrice OBLIGATOIRE pour 192*32

#ifdef ESP32
timer = timerBegin(0, 80, true);
timerAttachInterrupt(timer, &display_updater, true);
timerAlarmWrite(timer, temps_rafraichissement, true); //temps entre 2 rafaichissements (2000 µs)
timerAlarmEnable(timer);
#endif

display.setTextColor(BLANC, NOIR);
display.setTextSize(4);
display.setTextWrap(false); // ne pas sauter de ligne
afficherFond(". ");
delay(1000);
afficherFond("ChroPro!");
delay(1000);

}

void loop()
{
}

// Afficher sur fond noir (SUPER sur ESP32 même avec rafraichissement 0,1s / clignote sur ESP8266)
void afficherFond(String message)
{
display.setTextColor(BLANC, NOIR);
display.setCursor(1,1);
display.print(message);
}

[xsrf]

There are 3 chips 74HC245 on every input pin, this chip play as level converter, no ?

No, they are buffers - or in this case bidirectional bus transceivers. They make sure the input signal is strong enough for the following circuit and also all following panels. This is also why all digital outputs of the first panel are actually 5V.

However: The buffer is not a level converter. If you look in the datasheet of the 74HC245 you'll see that V_IH is 0.7 * V_cc. Examples in the datasheet list 3.15V for 4.5V Vcc and 4.2V for 6V Vcc.

Sure, at 5V Vcc they convert 4.5V logic levels to 5V levels...

A 3.3V to 5V logic level converter would have a V_IH of about 2.0V...

Thx for the code

[xsrf]

Okay, so here is the timing for the code (attached below) with SHIFTREG_SPI_PA:

And with SHIFTREG_ABC:

@pyzimmer Can you confirm the first one still has issues, while the second one does not?
Only differences are:

• MUX_CLK/DATA Speed 16MHz vs. 2.6MHz
• MUX_DATA available on rising edge vs. rising+falling edge
• Double load on SPI CLK/DATA on the ESP in SHIFTREG_SPI_PA

The only critical timing I see is the time between latching pixel data and enabling the output, which in both cases is ~125ns, but that has never changed.

Code

#include <Arduino.h> // Needed in PlatformIO
//#define double_buffer false // = false pourse libraire < 1.5, ligne commentée pour libaririe >= 1.5
#define PxMATRIX_SPI_FREQUENCY 16000000
#define PxMATRIX_MAX_HEIGHT 32
#define PxMATRIX_MAX_WIDTH 192 // obligatoire à partir de la v1.5 pour 192px
#define PxMATRIX_COLOR_DEPTH 1
#include <PxMatrix.h> // https://github.com/xsrf/PxMatrix/blob/4fae26a12178a86949a12da6831dc248ab83eddf/PxMatrix.h
uint8_t display_draw_time=70; // temps d'affichage (70). Ignoré avec FastUpdate. Diminuer si aucun affichage, mais cela réduit la luminosité
uint16_t temps_rafraichissement=2000; // temps entre 2 rafaichissements (2000 µs) augmenter si aucun affichage, mais cela réduit la luminosité (2600 minimum pour 192*32 avec luminostié de 1800 lux)

#define P_LAT 4 // 22 // STB
#define P_A 19
#define P_B 23
#define P_C 18 // seulement pour scan 1/8, 1/16, 1/32
#define P_D 5 // seulement pour scan 1/16, 1/32
#define P_E 15 // seulement pour scan 1/32
#define P_OE 2 // STB
// CLOCK = SH = 14
// DATA = R1 = 13
#define SPI_BUS_MISO 21
#define SPI_BUS_CLK 22
hw_timer_t * timer = NULL;
portMUX_TYPE timerMux = portMUX_INITIALIZER_UNLOCKED;

// Pins for LED MATRIX
PxMATRIX display(192,32,P_LAT, P_OE,P_A,P_B,P_C);

uint16_t NOIR = display.color565(0, 0, 0);
uint16_t BLANC = display.color565(255, 255, 255);

void afficherFond(String message);

void IRAM_ATTR display_updater(){
  portENTER_CRITICAL_ISR(&timerMux);
  display.display(display_draw_time); // temps d'affichage (70) diminuer si aucun affichage
  portEXIT_CRITICAL_ISR(&timerMux);
}

void setup() {
  display.begin(8); //{4,8,16,32}
  display.setMuxPattern(SHIFTREG_SPI_PA); // {BINARY, STRAIGHT, SHIFTREG}
  //display.setScanPattern(VZAG); // {LINE, ZIGZAG, ZAGGIZ, WZAGZIG, VZAG}
  display.setPanelsWidth(12);
  //display.setFastUpdate(true); // aligne correctement les pixels sur la matrice OBLIGATOIRE pour 192*32

  timer = timerBegin(0, 80, true);
  timerAttachInterrupt(timer, &display_updater, true);
  timerAlarmWrite(timer, temps_rafraichissement, true); //temps entre 2 rafaichissements (2000 µs)
  timerAlarmEnable(timer);

  display.setTextColor(BLANC, NOIR);
  display.setTextSize(4);
  display.setTextWrap(false); // ne pas sauter de ligne
  afficherFond(". ");
  delay(1000);
  afficherFond("ChroPro!");
  delay(1000);

}

void loop()
{
}

// Afficher sur fond noir (SUPER sur ESP32 même avec rafraichissement 0,1s / clignote sur ESP8266)
void afficherFond(String message)
{
  display.setTextColor(BLANC, NOIR);
  display.setCursor(1,1);
  display.print(message);
}

[pyzimmer]

Wahoo, pretty timing graphs !

I test your last version of library :

• SHIFTREG_ABC : works fine, even in fastUpdate mode
• SHIFTREG_SPI_PA or SHIFTREG_SPI_SE did the same not ?
  • with Parallel wiring : no way , unable to display something
  • with Sequential wiring : fastUpdate make ghosting. I found settings that works :

display.setFastUpdate(false);
#define PxMATRIX_SPI_FREQUENCY 13000000
timerAlarmWrite(timer, 2600, true);

But with 2600µs I loses a lot of brightness...
When I increase SPI frequency to 16 Mhz colored pixels appears again, so SPI frequency affect colored pixels (there are fixed pixels, always at the same place)

[xsrf]

• SHIFTREG_ABC : works fine, even in fastUpdate mode

good to know I haven't messed that up ;)

• SHIFTREG_SPI_PA or SHIFTREG_SPI_SE did the same not ?

Yeah almost... SHIFTREG_SPI_SE won't set PIN_B as output since it is not needed, but otherwise it is the same as SHIFTREG_SPI_PA for now.
However, in SHIFTREG_SPI_PA there could actually be set a different (lower) SPI frequency just for the row selection, which would not be possible (as easy) in SHIFTREG_SPI_SE. But I'm not sure if that would help...

• with Parallel wiring : no way , unable to display something

So worse than yesterday? 🤔

Did you actually change the wiring between SE and PA settings or did you leave it the same because yesterday I said it wouldn't make a difference regarding code? While this is still the case, electrically it makes small timing differences.
Edit: correction, SHIFTREG_SPI_SE in code won't work with parallel wiring at all, since the row selection would never be latched

• with Sequential wiring : fastUpdate make ghosting. I found settings that works :

display.setFastUpdate(false);
#define PxMATRIX_SPI_FREQUENCY 13000000
timerAlarmWrite(timer, 2600, true);

I'll look into that, thx.

But with 2600µs I loses a lot of brightness...

Yeah. Keep in mind that with your three panels, 8 mux rows and without fast_update display.display(70) already needs 1850µs to execute with SPI @ 16MHz on the ESP32. If you lower the SPI frequency just a bit, execution exceeds 2000µs and thus cannot be executed every 2000µs.

When I increase SPI frequency to 16 Mhz colored pixels appears again, so SPI frequency affect colored pixels (there are fixed pixels, always at the same place)

Interesting... so no random noise...

Can you try again, but this time with display.display() inside loop instead of using the timer?
This will prevent issues with the Timer ISR actually running too long and will just run the display at the maximum rate possible.
Then you should be able to test lower SPI speeds without crashes. I know the display may loose brightness or flicker, but these are other issues ;)

adapted code

#include <Arduino.h> // Needed in PlatformIO
//#define double_buffer false // = false pourse libraire < 1.5, ligne commentée pour libaririe >= 1.5
#define PxMATRIX_SPI_FREQUENCY 8e6
#define PxMATRIX_MAX_HEIGHT 32
#define PxMATRIX_MAX_WIDTH 192 // obligatoire à partir de la v1.5 pour 192px
#define PxMATRIX_COLOR_DEPTH 1
#include <PxMatrix.h> // https://github.com/xsrf/PxMatrix/blob/4fae26a12178a86949a12da6831dc248ab83eddf/PxMatrix.h
uint8_t display_draw_time=70; // temps d'affichage (70). Ignoré avec FastUpdate. Diminuer si aucun affichage, mais cela réduit la luminosité

#define P_LAT 4 // STB
#define P_A 19
#define P_B 23
#define P_C 18 // seulement pour scan 1/8, 1/16, 1/32
#define P_D 5 // seulement pour scan 1/16, 1/32
#define P_E 15 // seulement pour scan 1/32
#define P_OE 2 // STB
// CLOCK = SH = 14
// DATA = R1 = 13

// Pins for LED MATRIX
PxMATRIX display(192,32,P_LAT, P_OE,P_A,P_B,P_C);

uint16_t NOIR = display.color565(0, 0, 0);
uint16_t BLANC = display.color565(255, 255, 255);

void afficherFond(String message);

void setup() {
  display.begin(8); //{4,8,16,32}
  display.setMuxPattern(SHIFTREG_SPI_PA); // {BINARY, STRAIGHT, SHIFTREG}
  display.setPanelsWidth(12);
  //display.setFastUpdate(true); // aligne correctement les pixels sur la matrice OBLIGATOIRE pour 192*32

  display.setTextColor(BLANC, NOIR);
  display.setTextSize(4);
  display.setTextWrap(false); // ne pas sauter de ligne
  afficherFond(". ");
  delay(1000);
  afficherFond("ChroPro!");
  delay(1000);

}

void loop()
{
  display.display(display_draw_time); // temps d'affichage (70) diminuer si aucun affichage
}

// Afficher sur fond noir (SUPER sur ESP32 même avec rafraichissement 0,1s / clignote sur ESP8266)
void afficherFond(String message)
{
  display.setTextColor(BLANC, NOIR);
  display.setCursor(1,1);
  display.print(message);
}

[pyzimmer]

Hello,
Same result :

• OK for Sequetial wiring
• no display for Parallel... but I noticed that in total darkness (photo with dark mode), I can perceive that :

[xsrf]

I'm really not sure what happens here... Since the LEDs only glow red, which I also noticed on the brighter image above, something must run into a current limit causing the voltage applied to the LEDs to break down. Only the red one light up because they have the lowest forward voltage.
The limit seems to be constant per row, causing rows with less colums lit (like the top right section of the 3rd panel) to light up brighter.
Also, all 8 rows of the mux show exactly the same pattern, which suggests that all row drivers are actually (kind of) enabled all the time, not only one at a time... 🤔

[xsrf]

I've just read through the code at #179 which suggests that the Latch I assumed was connected to Pin B may not exist. This would explain why parallel wiring would not work at all, because in PA wiring the last bytes of the picture buffer would end up in the register for the row mux. Sequential however still should work without a separate latch if you are not using fast_update. In fast_update data is pushed to the SPI bus while the LEDs are lit. This would cause all rows to be selected randomly (depending on the picture buffer) for most of the time the LEDs are lit but finally settling in the right row selection. This actually would explain your picture from April 20.

[xsrf]

Okay, I've just read the datasheet of the RT5957 again. As you said, B is connected to BK and the Datasheet says: BK: Current output enable signal terminal
Okay 🤦‍♂️ My fault, I missed that when I read the datasheet last time.
The chip actually has no latch...
Guess I'll have to trash the idea of parallel wiring and maybe sequential wiring too.

[xsrf]

Also, this means the code could me optimized... Instead of shifting out 16 bits for a 1/16 display every time, shifting out one bit (1 if row is 0, 0 otherwise) would be enough. This should work as long as the rows are selected incrementally - which is the case for the regular display() call. Only the test patterns may have to be adapted.

[pyzimmer]

Good job ! Sometimes we have to take a break and take a step back...

[xsrf]

I've pushed an update to https://github.com/xsrf/PxMatrix/tree/shift-mux which contains the optimization for SHIFTREG_ABC.

Not optimized code (allows random row access):

Here it takes a huge amount of time to select the row.

Optimized code (only works with incremental row access, which is fine in normal operation):

Here, selecting the row is as fast/faster as with STRAIGHT/BINARY.

You don't have to do anything for using the optimized code. Can you try SHIFTREG_ABC again if it still works (faster)?

[pyzimmer]

Very good job, It works fine.
Performances are quite the same : I can't increase SPI over 13e6 otherwise I get some colored pixels.
Lot of thanks from France where I have to stay at home...

[thecodingfrog]

Hi, just bought panel with same IC and a driverd board from electrodragon for my ESP32. Nothing is displayed on my panel :(

[arnasdev]

Hiya folks - I have the same Chipset ICN2037B. I know this issue is marked as closed but looks like the changes made in #192 are no longer applicable? Is there a way to get these to work?