Chipset ICN2037 / Driver 5958
Closed this issue · 83 comments
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 :
When I unplugg A, B and C pins, and I touch them with my fingers, the test_pattern appears sometimes. Strange...
Here is a video of unplug A pin : https://photos.app.goo.gl/4xqDg5gXukx6tXMZA
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..
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 !
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...
I think it is a problem of voltage level. I will order 3,3->5v level shifter.
No difference with the level shifter.
Any idea ?
If it works if you touch the wire it sounds like a grounding issue. Make sure that esp32 and panel ground are connected property.
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 !
it does not work
I think the issue is about the mux. Could you explain me in which order the chips are linked : ICN2037 , 74HC245, RT5957. Thank you.
Sorry ... very busy atm ....
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
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.
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...
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.
thanks, i read it. I try adding 1/2 µs, before/after, A and C mux, no way
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.
@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.
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() .
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);
The mario screen : some lines are missing, others are clone :
hello, when I unplug Bmux wire, some new lines appears 3 times :
I try to modify code of mux and latch, no way ! Any idea to modify the code of scan pattern ? thanks
Ok...try to re-assign the B Wire to a differen pin
thank you for your help, same issue with pins 21, 22 or 23
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 ?
expected result (did with another panel model) :
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
I have A new driver chip screen with ICND2038S, but I use driverchip “shift”, it works fine. but there is no detail about the driverchip register info.
ICN2038S_datasheet_CN_2017_V1.3.pdf
Thank you, I compare the two datasheets, the only differnence I seen is OE time = 60ns for ICN 2037 instead of 40ns for ICN2038 . I will try to increase activation time of OE_pin.
Yes @2dom : #117 (comment)
Thank you, I compare the two datasheets, the only differnence I seen is OE time = 60ns for ICN 2037 instead of 40ns for ICN2038 . I will try to increase activation time of OE_pin.
ohmm, i have visited the chip's official website, ICN2038 is a little different with ICN2038S, with suffix "S", have LAT registers, ICN2038 none.
I try another test :
for(int y=0; y<32; y++)
{
i++;
if(i==1) color= RED;
if(i==2) color= GREEN;
if(i==3) color= BLUE;
if(i==4) {color= WHITE; i=0;}
display.drawLine(0,y,y,y, color);
delay(500);
}
the result :
when I unplug Bmux :
when I unplug Amux :
Hello, I found something : the chip RT5957 replace classic 74HC138 chip for multiplexing. This chip use a DATA/CLOCK pin instead of ABC pins. But I have no idea how to modify the code...
I send you an english translation of the chinese datasheet :
RT5957.zh-CN.en.pdf
I have the same issue. And will happily help with testing.
I think A, B and C are actually DATA, CLK and LATCH of an shift register used for muxing.
I guess A is DATA, because leaving it floating actually shifts out random noise activating all lines randomly,
Can you trace A, B, and C to actual chip pins with a multimeter / by inspection?
Hello, you are right :
A,B,C pins are connected to A0,A1,A2 of the 74HC245.
Then B0,B1,B2 pins of 74HC245 are connected to LCK, BK, DIN pins of RT5957.
LCK and BK are connected to one RT5957 chip, and DIN to another RT5957 chip. (there are 4 RT5957 chips)
I send you an english translation of the chinese datasheet :
RT5957.zh-CN.en.pdf
@pyzimmer you may try https://github.com/xsrf/PxMatrix/tree/shift-mux , I've added SHIFTREG as additional mux pattern via xsrf@b91bbd4
Just use this within pattern_test etc:
display.begin(16); // or 32 ...
display.setMuxPattern(SHIFTREG); // must be set after begin()!
Performance is pretty bad, it takes 45µs to shift out 16 bits for the mux...
The RT5957 datasheet didn't mention if data is clocked in / latched on rising or falling edge so I just guessed.
Btw. if this works, rewiring could speed up performance and allow us to use SPI hardware for the muxing too.
Option 1) Joining CLK+A and DATA+C together on the first panel would allow using SPI in parallel for muxing and pixels. We would send out up to 4 Bytes of data via SPI for mux (before or after Pixeldata is sent and latched), then latch B. This would also free up 2 Pins on the ESP (only one needed instead of A,B,C)
Option 2) Connect CLK(OUT) of the last panel to A(IN) on the first panel, DATA(OUT) of the last panel to C(IN) on the first panel and LATCH(OUT) of the last panel to B(IN) on the first panel.
This would require us to send up to 4 Bytes for muxing prepended to the Pixeldata. There MAY be a small issue because the propagation delay of the data from the Input of the first panel to the output of the last panel MAY require a tiny guard delay between latching and enabling LED outputs.
This would however free up all muxing pins on the ESP (A,B,C, ... not needed)
Very good job : https://photos.app.goo.gl/UQMMxsuhDiBzuu8AA
I am going to do more test...
Thx, at least a steady row selection :) But that's only the first mux selection. What happens when all four lines turned white? Is it repeating the same but with all four lines offset by one?
The display clearly is an 1/8 mux btw, so try to use begin(8)... not sure what kind of ZIGZAG pattern this is though.
the result :
Do you need video of complete pattern_test ?
I have to emulate 4 panels for pattern :
display.begin(8);
display.setMuxPattern(SHIFTREG);
display.setScanPattern(LINE);
display.setPanelsWidth(4);
I'll try with 3 panels...
Thanks a lot !!!
I think we can skip the full pattern test :)
If you have some performance measurements let me know... I'll try to implement a faster method.
@pyzimmer I've moved to Hardware SPI now for muxing via xsrf@c34b1b3 , you may try the latest version of https://github.com/xsrf/PxMatrix/tree/shift-mux
Be aware, this one requires rewiring!!
Pin A of the Panel input must be connected to CLK.
Pin B of the Panel input still is connected to the ESP Pin labeled B in the code.
Pin C of the Panel input must be connected to DATA.
Now Muxing and Pixel-Data share the same SPI bus. This frees two pins on the ESP.
Performances are quite the same, I can refresh a complete panel of 192x32 pixels every 100ms :
Thank you , I'll try this tomorrow :
@pyzimmer I've moved to Hardware SPI now for muxing via xsrf@c34b1b3 , you may try the latest version of https://github.com/xsrf/PxMatrix/tree/shift-mux
Be aware, this one requires rewiring!!
Pin A of the Panel input must be connected to CLK.
Pin B of the Panel input still is connected to the ESP Pin labeled B in the code.
Pin C of the Panel input must be connected to DATA.Now Muxing and Pixel-Data share the same SPI bus. This frees two pins on the ESP.
Hello,
It does not work, the video of test_pattern : https://photos.app.goo.gl/zs7azTvtNrFv5QVA7
Furthermore, rewiring is not very convenient when using dupont cable. Or is it possible to bridge 2 output pins on ESP ?
Hmm, the video shows that the mux data actually got clocked into the pixeldata and the mux is not working... not sure why this happened. Have you swapped the latch pins?
Please check the wiring? It should look like this:
DATA+C share the same DATA Output of the ESP
CLK+A share the same CLK Output of the ESP
B is still connected as usual.
I know that connecting dupont cables to two pins is harder, a breadboard might help :)
This is the actual timing measured in regular update mode on my ESP8266:
It should clock in the data for the mux and latch the mux. Then it should clock in all data for the pixels and latch these...
One difference between ShiftOut() and HSPI is that ShiftOut had the data active on rising and falling edge. HSPI only on rising edge:
ShiftOut:
HSPI:
But that should only create a line shift in worst case...
Edit: or it will result in a black screen because no row gets selected at all..
I guess I'll implement both methods anyway to be compatible with existing wiring/boards for those who can accept the lower refresh rate caused by shiftout. But I'd be interested if it actually would work with shared SPI.
Just FYI, here is a comparison between ShiftOut and SPI speed @ 20MHz. It takes more than twice as long to just select the mux, than it takes to shift out RGB Data for 128 Pixels.
In terms of wiring, the sequential muxing approach would actually be easier and more compatible... It would require three additional connections from the output of the last panel to the input of the first panel, as mentioned two days ago:
Actually, both wiring should work with exactly the same code... The only code difference is that PIN_B is not needed in the sequential one 🤷♂️
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
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>
I try with sequetial wiring, I is not better : https://photos.app.goo.gl/5NnexyGFxLynS23W6
I try with 2Mhz SPI, no change.
Sorry
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 :)
Yes It was test_pattern.
Here is "ChroPro!" text :
instead of :
okay, is this parallel or sequential wiring? Are you using fast update or not?
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
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.... :)
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
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.
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.
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);
}
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
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);
}
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)
- 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);
}
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 :
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... 🤔
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.
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.
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.
Good job ! Sometimes we have to take a break and take a step back...
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)?
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...
Hi, just bought panel with same IC and a driverd board from electrodragon for my ESP32. Nothing is displayed on my panel :(