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 ***@***.***> 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 <#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 <notifications@github.com> Date: 8/11/20 1:46 AM (GMT-05:00) To: FastLED/FastLED <FastLED@noreply.github.com> Cc: Jordan Adania <jordan.adania@gmail.com>, Mention <mention@noreply.github.com> 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.

[agrath]

I have been watching this issue for a while as I have a project that has two strips connected, one using BGR and another RGB on an ESP32 (arduino)
The second strip was not working well for our project so we disabled it as it was for debugging mostly anyway.
We additionally observed that the first two pixels on the second strip were also the wrong colour.

I have just retested using fastled 3.4 and can't reproduce the issue anymore, both strips are working with their correct colour spaces.

[jordanadania]

Maybe it is time to switch back to esp32!

I will close this until I can recreate the problem.

[talkncloud]

tested today, esp32 on 3.4, not fixed, it is most definitely GRB as someone else commented on.

[jordanadania]

Thanks for saving me the trouble.Sent from my T-Mobile 4G LTE Device -------- Original message --------From: Mick ***@***.***> Date: 9/5/21 1:05 AM (GMT-05:00) To: FastLED/FastLED ***@***.***> Cc: Jordan Adania ***@***.***>, State change ***@***.***> Subject: Re: [FastLED/FastLED] ESP32 Color Order (#827) tested today, esp32 on 3.4, not fixed, it is most definitely GRB as someone else commented on. —You are receiving this because you modified the open/close state.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.