Fastled: ESP32 Color Order

[jordanadania]

FastLED.addLeds<WS2812B, 23, GRB>(leds, NUM_LEDS);

FastLED.addLeds<WS2811, 32, RGB>(leds, NUM_LEDS);

With that code, the WS2812B strip runs correctly, but the WS2811 code swaps the Red and Green. Switching the WS2811 to GRB has no effect.

Putting the WS2811 line before the WS2812B gives opposite results. The WS2811 strip will run correctly, but the WS2812B strip would have Red and Green swapped. Switching the WS2812B to RGB has no effect.

[focalintent]

@samguyer I can see the problem - it's this line:

https://github.com/FastLED/FastLED/blob/master/platforms/esp/32/clockless_i2s_esp32.h#L628

            ClocklessController * pController = static_cast<ClocklessController*>(gControllers[i]);

Because you are keeping a single array of clockless controller objects and you're doing a forcible static cast here, it's overriding the RGB_ORDER template parameter - and because CPixelController is _not_ virtual (for optimization reasons) - it's basically throwing away the different RGB ordering for different sets of pixels when using the i2s output.

You're going to need to do some juggling w/virtual methods to make sure that you're getting the correct color ordering for different strips.

Similarly on the rmt side:

https://github.com/FastLED/FastLED/blob/master/platforms/esp/32/clockless_rmt_esp32.h#L484

                // -- Refill the half of the buffer that we just finished,
                //    allowing the other half to proceed.
                ClocklessController * controller = static_cast<ClocklessController*>(gOnChannel[channel]);
                controller->fillHalfRMTBuffer();

that static cast is basically throwing away the RGB_ORDER template information.

[samguyer]

I think it's ok in the RMT controller because the fill method is virtual.
The I2S controller already has the limitation that all strips must be
identical.

On Tue, Jun 25, 2019 at 8:18 PM Daniel Garcia [e-mail]
wrote:

@samguyer https://github.com/samguyer I can see the problem - it's this
line:

https://github.com/FastLED/FastLED/blob/master/platforms/esp/32/clockless_i2s_esp32.h#L628

        ClocklessController * pController = static_cast<ClocklessController*>(gControllers[i]);

Because you are keeping a single array of clockless controller objects and
you're doing a forcible static cast here, it's overriding the RGB_ORDER
template parameter - and because CPixelController is not virtual (for
optimization reasons) - it's basically throwing away the different RGB
ordering for different sets of pixels when using the i2s output.

You're going to need to do some juggling w/virtual methods to make sure
that you're getting the correct color ordering for different strips.

Similarly on the rmt side:

https://github.com/FastLED/FastLED/blob/master/platforms/esp/32/clockless_rmt_esp32.h#L484

            // -- Refill the half of the buffer that we just finished,
            //    allowing the other half to proceed.
            ClocklessController * controller = static_cast<ClocklessController*>(gOnChannel[channel]);
            controller->fillHalfRMTBuffer();

that static cast is basically throwing away the RGB_ORDER template
information.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/FastLED/FastLED/issues/827?email_source=notifications&email_token=AATSHK4HNOEMQI4CK7IDIJ3P4KYWZA5CNFSM4H3MJEN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYR6IQI#issuecomment-505668673,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATSHK33PGY54ANMNLRGDY3P4KYWZANCNFSM4H3MJENQ
.

[jordanadania]

I'm more on the noob side of things, so if the answer has been posted in your language, just let me know in my language so I can begin to _attempt to_ translate.

[focalintent]

The answer is that there’s a bug in FastLED that needs to get fixed :) just a question of time

[samguyer]

@focalintent
Huh. It looks like I did not make those methods virtual, which probably explains why it doesn't work.
I believe the solution is to make fillHalfRMTBuffer and startOnChannel virtual methods. That was my intent, but somehow it didn't make it in there.

[samguyer]

@focalintent You'll appreciate this: I've got two laptops, side by side, one debugging FastLED and the other debugging saf. :-)

[jordanadania]

THANK YOU!!!! You fixed it!!!

[jordanadania]

Apparently, it's not fixed??

[samguyer]

@jordanadania what made you reopen this issue? Was it fixed before and now it's not?

[jordanadania]

I wouldn't trust old me; it's definitely not working right now. I stopped using ESP32 for some reason, but I don't remember what. But I really wanna switch over to the 32s now. I am available to help in anyway. Donations or whatever.

Also, my first 2 pixels on every strip are wrong color order; swapped with RGB and GRB cause blue is correct for everything.

https://github.com/jordanadania/fastled-newFlow

This is the code; it's small. The setup is the only thing relevant anyway.

[jordanadania]

Do you want me to open a brand new ticket?

[samguyer]

Nah, let's just keep this ticket open. When I looked at the code I thought to myself "How could this possibly be fixed?!?!" :-)

[samguyer]

@kriegsman Do you have any thoughts on how to handle this situation? I can explain the problem in more detail if you want.

[jordanadania]

on the 8266, i can set 3 of them to parallel output, and then assign the 4th normally and it works. so, idk if that helps at all.

[samguyer]

@jordanadania Yeah, it's a totally different method of sending the bits. The short version is that the ESP32 driver is called by a periodic interrupt, so we need to pass the color order information through that interrupt interface, which is hard because it's a template parameter, not a runtime value.

[jordanadania]

I think it's ok in the RMT controller because the fill method is virtual. The I2S controller already has the limitation that all strips must be identical.

How do I switch to the RMT controller?

[BradMcc522]

I think I ran into a similar issue. I have multiple strips, all WS2815. 3 of them are GRB and work perfect. The 2 strips that are RGB and despite being set as RGB they have the red and green switched.

[jordanadania]

This is due to clockless. Its why i use nothing but 8266sSent from my T-Mobile 4G LTE Device
-------- Original message --------From: BradMcc522 [e-mail] Date: 8/11/20 1:46 AM (GMT-05:00) To: FastLED/FastLED [e-mail] Cc: Jordan Adania [e-mail], Mention [e-mail] Subject: Re: [FastLED/FastLED] ESP32 Color Order (#827)
I think I ran into a similar issue. I have multiple strips, all WS2815. 3 of them are GRB and work perfect. The 2 strips that are RGB and despite being set as RGB they have the red and green switched.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.