Skip to content

3 PWM RGB and 3 PWM CCT failed #4645

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 task done
lexius opened this issue Apr 16, 2025 · 4 comments
Open
1 task done

3 PWM RGB and 3 PWM CCT failed #4645

lexius opened this issue Apr 16, 2025 · 4 comments
Labels

Comments

@lexius
Copy link

lexius commented Apr 16, 2025

What happened?

ESP32 board.
When I cerate segments like: RGB, CCT, RGB, CCT, RGB, CCT - the last one will be reset on save without visible error. When I create RGB, RGB, RGB, CCT, CCT, CCT - all working fine.

To Reproduce Bug

WLED 0.15.0, 0.15.1 beta 2

Expected Behavior

6 segments must be added

Install Method

Binary from WLED.me

What version of WLED?

0.15.1 beta2

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@lexius lexius added the bug label Apr 16, 2025
@blazoncek
Copy link
Collaborator

Please use debug build and dump serial output while ESP reboots and then dump serial output when saving configuration.

@blazoncek
Copy link
Collaborator

I think I know what's causing this issue and there is not much that can be done (as it is too complicated to implement in UI properly).

@DedeHai & @willmmiles can you take a look? I think it has to do with the fact that CCT channels need to be aligned to even numbers. See pin manager, LEDC allocation.

@DedeHai
Copy link
Collaborator

DedeHai commented Apr 17, 2025

yes, highly likely that it's caused by the timer-alignment required for CCT. To solve it, it would need to be re-ordered with some logic to best consolidate timer use in all possible use cases.

@willmmiles
Copy link
Member

Yup, looks like it's a channel allocation issue. I don't think this is a UI problem so much as a "how to process a config" concern. It's basically the same challenge as parallel I2S: we cannot assume that buses are independent -- there are shared resources and allocation matters. The "right answer" is to have a phase after config parsing but before bus implementation creation where resource mappings can be planned and reordered.

Although I suppose the root UI concern -- demonstrated here, actually! -- is that unresolvable configs don't tell the user what went wrong, it just "silently" drops something. It might be worth thinking about implementing a validation endpoint to make the UI easy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants