need runtime_options.gpio_slowdown to go up to 8 with ABC panels and dietpi 64bit

[marcmerlin]

--- a/lib/led-matrix.cc
+++ b/lib/led-matrix.cc
@@ -660,7 +660,7 @@ RGBMatrix *RGBMatrix::CreateFromOptions(const RGBMatrix::Options &options,
   // For the Pi4, we might need 2, maybe up to 4. Let's open up to 5.
   // on supproted architectures, -1 will emit memory barier (DSB ST) after GPIO write
   if (runtime_options.gpio_slowdown < (LED_MATRIX_ALLOW_BARRIER_DELAY ? -1 : 0)
-      || runtime_options.gpio_slowdown > 5) {
+      || runtime_options.gpio_slowdown > 10) {
     fprintf(stderr, "--led-slowdown-gpio=%d is outside usable range\n",
             runtime_options.gpio_slowdown);
     return NULL;

@hzeller this is both an FYI and also kind of asking for help.
I got some ABC flexible panels, if I connect just 3 of them on a Pi02wl, one per chain, they work with a slowdown of 5, for 5 is already terrible for a pi02w (probably wouldn't work at all with a Pi4).
Now the super weird thing is if I plug in 2 panels per channel, then I start getting all kinds of noise, and I have to increase the slowdown to 8 :(
My ribbon cables are not that long, the noise is on all 3 channels, I have triple redundant grounds and double redundant power.

The exact same thing worked with ABCDE panels and a slowdown of 2, but obviously those different chips do not like the (I assume) bad waveform that comes out of a Pi.

Questions

1. am I correct that basically I have no way around this? if I have noise with short enough ribbon cables, I'm forced to increase slowdown, even past 5?

2. are ABC /32 panels (128x64) inherently worse than ABCDE, or did I just get unlucky with the chips on these specific panels?

[marcmerlin]

While we're at it, I'm going to add some timing info.
It's hard to believe but my Rpi0 2w with dietpi 64bit is actually faster than my rpi3a with an older raspbian 32bit. Good, because I need all the speed I can get, or maybe not? (more speed means I need more slowdown because bad waveform?)

The refresh rates are pretty terrible for a single 128x64 panel per chain. Am I doing something wrong outside of the slowdown-gpio? I already took PWM way down, dither on, LSB nanoseconds if I take it lower, it's just too dim.

RPi02w
root@rpi02w3:~/NeoMatrix-FastLED-IR# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-slowdown-gpio=8 --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=6 --led-pwm-lsb-nanoseconds=100 --led-pwm-dither-bits=1 -D0 
Size: 128x192. Hardware gpio mapping: regular

slowdown: 8, dither: 1, pwm: 6, add-type:0 (ABCDE)
 173.7Hz (lowest: 56.8Hz))

root@rpi02w3:~/NeoMatrix-FastLED-IR# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-slowdown-gpio=8 --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=3 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=6 --led-pwm-lsb-nanoseconds=100 --led-pwm-dither-bits=1 -D0 
Size: 128x192. Hardware gpio mapping: regular
slowdown: 8, dither: 1, pwm: 6, add-type:3 (ABC) => oh no, why is ABC so much slower than ABCDE?
 135.4Hz (lowest: 47.4Hz))

root@rpi02w3:~/NeoMatrix-FastLED-IR# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-slowdown-gpio=5 --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=3 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=6 --led-pwm-lsb-nanoseconds=100 --led-pwm-dither-bits=1 -D0 
slowdown: 5, dither: 1, pwm: 6, add-type:3 (ABC) => a bit faster but display is garbled
Size: 128x192. Hardware gpio mapping: regular
 163.3Hz (lowest: 58.8Hz))

--------------------------------------------------------------------------------

RPI3a
root@rPi3a2:~/rpi-rgb-led-matrix/examples-api-use/demo --led-slowdown-gpio=8 --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=6 --led-pwm-lsb-nanoseconds=100 --led-pwm-dither-bits=1 -D0 
Size: 128x192. Hardware gpio mapping: regular
slowdown: 8, dither: 1, pwm: 6, add-type:0 (ABCDE), damn 120 Hz is not fast even for ABCDE. Am I missing something?
 119.7Hz3Hz

~/rpi-rgb-led-matrix/examples-api-use/demo --led-slowdown-gpio=8 --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=3 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=6 --led-pwm-lsb-nanoseconds=100 --led-pwm-dither-bits=1 -D0 
Size: 128x192. Hardware gpio mapping: regular
slowdown: 8, dither: 1, pwm: 6, add-type:3 (ABC) => 88hz only???
88.0Hz


~/rpi-rgb-led-matrix/examples-api-use/demo --led-slowdown-gpio=5 --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=3 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=6 --led-pwm-lsb-nanoseconds=100 --led-pwm-dither-bits=1 -D0
Size: 128x192. Hardware gpio mapping: regular
slowdown: 5, dither: 1, pwm: 6, add-type:3 (ABC) => even then it's bad
117.6Hz0Hz

[marcmerlin]

But wait, it gets more weird, the ABC panels do work with slowdown 5, until I plug a 2nd set of panels on their output and simply use the output passively to feed the next panels. I do not change any code or any parameter.
Without the 2nd set of panels plugged in

(the 2nd panels get random noise and the first panels work fine)

Once I re-plug the 2nd panels in, that messes up the first ones :(

and now I need to change the slowdown all the way to 8 to undo the damage.
How does that even?

[marcmerlin]

@hzeller nicely pointed out that I was using a passive adapter board and maybe that could be the problem. I was super hopefully he'd be right, so I replaced the board with an active-3 board, and I still get damaged output all the way to --led-slowdown-gpio=6 (picture below). I actually need 7 for a stable output

root@rpi02w3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=3 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=6 --led-pwm-lsb-nanoseconds=100 --led-pwm-dither-bits=1 --led-slowdown-gpio=7 -D0 

and the worst part is the first panel (the one connected to the Pi has more damaged output than the 2nd one, maybe indeed because the 2nd panel is receiving "fixed" signals from the level shifters of the first panels

[marcmerlin]

Now that I confirmed it's not a problem with the output board, let's try rpi3a vs rpi0 2w.
rpi0 2w 6.1.21-v8+ dietpi 64bit needs slowdown 7 :(

root@rpi02w3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=3 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=6 --led-pwm-lsb-nanoseconds=100 --led-pwm-dither-bits=1 --led-slowdown-gpio=7 -D0 
Size: 128x192. Hardware gpio mapping: regular
Press <CTRL-C> to exit and reset LEDs
 145.4Hz (lowest: 47.8Hz))

rpi3a 4.14.98-v7+ raspbian 32bit can do down to slowdown 4! (still bad, but not as bad)

root@rPi3a5:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=3 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=6 --led-pwm-lsb-nanoseconds=100 --led-pwm-dither-bits=1 --led-slowdown-gpio=4 -D0 
Size: 128x192. Hardware gpio mapping: regular
Press <CTRL-C> to exit and reset LEDs
 167.4Hz (lowest: 44.5Hz))

ok, let's continue. I put the 64bit dietpi sdcard in the rpi3a and ran the same test and now it needs slowdown 7 again. however the "good" news is that it's somewhat faster than the rpi0 2w (169hz instead of 145hz)

root@rpi02w3:~#  ~/rpi-rgb-led-matrix/examples-api-use/demo --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=3 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=6 --led-pwm-lsb-nanoseconds=100 --led-pwm-dither-bits=1 --led-slowdown-gpio=7 -D0 
Size: 128x192. Hardware gpio mapping: regular
Press <CTRL-C> to exit and reset LEDs
 169.5Hz (lowest: 50.0Hz))

[marcmerlin]

Ok, more interesting testing, on the ABC panels, if I use ABCDE addressing (--led-row-addr-type=0) I can lower the slowdown to --led-slowdown-gpio=3 and the output is stable. It's wrong, but it's stable and I get a nice 260Hz.
The moment I switch back to --led-row-addr-type=3, I get flickering garbage.
So, it looks like the --led-row-addr-type=3 code is not giving a stable output at speed, at least not one that these panels are happy with. That does narrow things a bit, and may have found an issue in the ABC addressing code that got added in #823
Ok, now I have enough to split this into a new bug to track the ABC speed issues: #1774

[marcmerlin]

Ok, I submitted the simple change to allow bigger slowdowns. It's obviously not a real fix and higher slowdowns only paper over other problems, but at least the panel lights up correctly, which is better than not at all
I think I can close this bug as a result and the rest will continue in #1774