Support for BGR Led Panels

[DoomHammer]

It seems I have a bunch of panels that have R and B channels swapped. Is there a convenient way to use such panels with this library?

[board707]

Just swap R and B pins?

[DoomHammer]

Tried that but it gives an output I didn't anticipate (basically looks like the scanning patterns are mixed somehow).

[board707]

Your have to swap R and B for both pairs - R0 vs B0, and R1 vs B1

[DoomHammer]

Yup. Did just that. In custom pins declaration, right?

[board707]

Correct

wrong, see below

[DoomHammer]

I'll upload some examples and the results later on

[board707]

In custom pins declaration, right?

No, on the real HUB75 connector. Connect the wire, labeled in the code as Red, to Blue pin and vice versa

[DoomHammer]

This could work except I have a soldered on connector :/

[board707]

You could swap the wires on the STM32 side

[DoomHammer]

I'm using RP2040, but the thing is both sides are rather permanent (PCB). I can try with a bare Pico, though, albeit I find it a bit dirty to workaround in hardware a problem in software. Usually it's the other way round 😅

[board707]

In general, I agree with you :) However, in both stm32f4 and rp2040 color pins are not processed individually, but only as a set. Therefore, to exchange colors within the code, you cannot simply exchange the values of a pair of variables; you must encode the bits of the output buffer in a different order. I'll probably add the ability to change the order of colors in the future, but it's unlikely to be a matter of one or two days.

[DoomHammer]

This is just a single cursed set of 5 panels with this weird behavior, so I guess I'd do as you said: prepare a custom HW workaround for them.

I also have a different cursed set of 3 panels with some very weird display pattern that plan to decode one day and post a PR. But this would require the so-called "spare time" ;)

[board707]

panels with some very weird display pattern that plan to decode one day

I would help you with it if you make some tests - run the code that fulfill the panel pixel by pixel and show the video of fulfilling process.

[DoomHammer]

I don't have a video, but here is an example of pattern test with custom pattern function returning 0, 1, 2, 3, 4, 5:

2 mux pins, 2 scan lines

[board707]

I think it would be better to open a new issue. Please show the more information about the panel -is it have a label something like "32x16-s4-v2.76"? Do you know the number of scans? Do you able to read the idnumbers of the chips on the rear side? The clear photo of the rear side also can help.

[DoomHammer]

Cool, I'll open an issue once I film the pattern test

[board707]

Hi Returning to BGR panels issue... I came up with an idea on how not to solve, but to get around this problem.

How do you set the color for the pixel in your project? Do you use a standard Color333(), Color444() and Color888() functions? If so, you can define your own versions , say ColorBGR888(), which will just swap the red and blue colors and then call the standard function:

uint16_t ColorBGR888(uint8_t r, uint8_t g, uint8_t b) {
    return dmd.Color888(b,g,r);
}

[DoomHammer]

That's an approach that could work, yes!

[board707]

The only method incompatible with this workaround is drawRGBBitmap() function, because it uses colors from the file.

[board707]

Hi Returning to the issue title... Today I have added a setColorOrder() method to the library. The using is trivial - add it in setup() somewhere after dmd.init() :

dmd.setColorOrder(DMD_Color_order :: BRG);

All possible color orders are supported: RGB (default), RBG, BRG, BGR, GRB, GBR.

I will welcome your feedback with interest.

[DoomHammer]

Beautiful!

I don't know when I'll be able to test them again but it will definitely come in hand then!