This is going to take a while (1m^2).

@Sam_Guyer if you can recommend a basic example that uses 8 line parallel output with your code to see if it fixes some of the issues I’m seeing with Yves’ code, that will help me narrow down if the issue is with the code or whether it’s electrical problems.

+Marc MERLIN hello
could you replace your “clockless_block_esp32.h” by the content of that https://gist.github.com/hpwit/a20c6612d06ec2ca9c89b87ba0a5df8e the file is in Fastled->platform->esp->32
of course save the old version of the file :slight_smile:

@Yves_BAZIN sure. what is it supposed to change?

@Yves_BAZIN also did you want me to use your WS2811 or WS2812B codepath?

@Yves_BAZIN ok, I tried your new file and it seems a bit worse, more pixels in the wrong color, and a few in the wrong place.
I also tried WS2812B instead of WS2811 and WS2812B does not seem better. It may be a bit worse, I’m not certain yet.

Humm strange it works better on my panel

@Yves_BAZIN I have enough display issues that it’s hard to say what is to blame yet. I’m going to try non parallel output with the standard branch to validate things are ok (and I also already took an neopixel tester and lit up all the strings at the same time with it, and they look fine).
On your side, you can probably get this up and running in 15 to 20mn on your panel: FastLED_NeoMatrix/examples/MatrixGFXDemo64 at master · marcmerlin/FastLED_NeoMatrix · GitHub
It should display a bunch of test patterns that trigger display or wiring bugs easily for me.

  1. install the adafruit GFX library if somehow you don’t have it and then
  2. follow the P64BY64 define and change the values for your panel
  3. undefine SERIAL_OUTPUT which I’m now using until parallel works
  4. If you want to try without full power, also adjust #define BRIGHTNESS 255 to 64 or 32

@Yves_BAZIN Ok, the good news for me is that I was able to check that my panel works ok, I changed my code to use serialized output and everything looks fine.
Well, actually with your branch, serialized output is at least 4x (maybe 8x indeed) slower than with @Sam_Guyer 's branch, also it outputs random garbage pixels like you can see in this video while Sam’s branch does not.
https://photos.app.goo.gl/y6PtEUWAB79ex2t48
The diff to my code, is:

Obviously I don’t need serial output to work with your branch :slight_smile: but maybe it helps find the bug (the slowness and random garbage pixels happen with the new ./platforms/esp/32/clockless_block_esp32.h you gave me, and with the old one)

@Marc_MERLIN I will try the library in 64x64 16 output to see what is going on. The timing is sometime quite tough :wink: I will let you know

@Marc_MERLIN what do you mean serialized outputs. With Sam branch it is parallel output by default now.
I will look at your code and see what could be the reason

@Yves_BAZIN thanks for offering to have a look.
With my diff, I did fastled.show() on serial output, not the special FastLEDshowESP32 which I did use for parallel.
You can check https://github.com/marcmerlin/FastLED_NeoMatrix/commit/06cdd316d45c654b81ba9905aada145ddb4bf02d and see if somehow Sam’s library still gives me parallel output anyway when I’m trying to use serial.
Either way, his lib does work flawlessly, but that’s with 8 outputs. Once I reach 16, I expect that I’ll start running into trouble with his lib.

@Marc_MERLIN indeed Sam has modified his library to have parallel by default ;). Il will try to look to improve the 16 outputs

@Yves_BAZIN aah, that explains why it just works without me doing anything special with his lib, and why it’s so much faster than yours in serial mode.
I’m assuming it’s also using RMT and it will stop working once I add more outputs given that RMT only does 8 max.
Thanks for offering your time to help look at this, I truly appreciate it.

@Marc_MERLIN you are welcome. That is a good exercice to improve my code too. I did not touch the serial part of the library;)

@Yves_BAZIN if it’s helpful for me to send you a video of the demo code I just sent you, running on my 32x64 array with your code (to show the different kinds of glitches and problems), let me know. However I’m pretty confident that the same code will reproduce the same problems on your hardware, making debugging easier :slight_smile:

@Marc_MERLIN yes send me I would like to see the issues

@Yves_BAZIN sure thing, there you go. The code I sent you by the way, I wrote to debug my own directmatrix scan driver I wrote a long time ago :slight_smile:

  1. the lines are the beginning are supposed to be the same all the across and they’re not supposed to change when you add new lines
  2. the set of colored 8x8 patterns that all look the same but not quite are supposed to all look the same and be aligned
  3. the smiley faces are supposed to all be the same and never change
  4. the top is supposed to show 64x32 but that’s damaged
  5. the bottom is supposed to write RGB
  6. hello world is one color for each word, currently colors change after 4 lines right now (different pin) when they should not
  7. the huge rotate changes colors and if you freeze frame you’ll see that the 8 pixel wide blocks at the top are misaligned

@Marc_MERLIN to which pin is plugged the top line ? If pin’0’ try to use pins 2,4 5,12,13,14,15,16 and let me know

@Yves_BAZIN here is my init:
FastLED.addLeds<WS2811_PORTA,NUM_STRIPS,((1<<16) + (1<<2) + (1<<4) + (1<<5) + (1<<12) + (1<<13) + (1<<14) + (1<<15))>(leds, NUM_LEDS_PER_STRIP);
I just changed 1<<0 into 1<<16. I didn’t rewrite everything because that’s a pain, but I ran 7 pins out of 8. This is why the top 4 lines look wrong in the pictures below.
.
It looks a bit better without pin0, a few artifacts are gone, but there are still plenty left, although it looks like all colors being messed up now, not issues of the the pixels being offset by one or two. So that’s an improvement.

The part that displays 64x32 in text at the top left now looks good.
The 2 rows of smiley faces below are still damaged, they’re not offset, but the colors are still wrong, on a 4 line boundary.
So yeah, depending on which pin is driving the color, the colors are wrong, and scrolling text does sometimes cause a pixel in a given position to change color from the color it’s supposed to be.
I also still see some flickering during the initial scan that displays lines, but that’s more minor in the big scheme.

no pixel damage, good, colors broken on some pins. Looks like at least pin12 if I counted right, is also broken for colors (but not always)
missing/deleted image from Google+