BTNPIN compile time option sets unused buttons to GPIO 0

[robertvb83]

What happened?

Setting 4 buttons works as expected (buttons GPIO are only set but still disabled) -D BTNPIN=0,4,34,35

However if you set less than 4 buttons, the remaining buttons are set to GPIO 0 automatically. Leading to double entries for 0
-D BTNPIN=0,4

To Reproduce Bug

See above

Expected Behavior

Set other buttons to "unused"

Install Method

Self-Compiled

What version of WLED?

WLED 0.15-b3

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

Code of Conduct

• I agree to follow this project's Code of Conduct

[blazoncek]

Just define BTNPIN=0,4,-1,-1
You can also set BTNTYPE if you wish.

[robertvb83]

thank you, that is, what i was looking for.

how is BTNTYPE set? i use 2 push buttons and 1 analog potentiometer, 4th button should be GPIO35 but disabled by default

BTNPIN=0,4,34,35
BTNTYPE = PUSH, PUSH, ANALOG, -1

[blazoncek]

Check const.h for button types.

[robertvb83]

Check const.h for button types.

Thanks for pointing me in that direction. It works exactly as it should

[softhack007]

Hi @blazoncek and @robertvb83 and @PaoloTK
(Sorry if I'm late for this discussion)

https://github.com/Aircoookie/WLED/blob/42decbddd960b9a1c6a459a3ea5f6ad18db1d9a5/wled00/wled.h#L597-L598

However if you set less than 4 buttons, the remaining buttons are set to GPIO 0 automatically. Leading to double entries for 0
-D BTNPIN=0,4

I think the "root cause" is related to how C/C++ handles incomplete array initialization.

According to the C standard, an incomplete initialization like btnPin[4] = {0, 4} is filled with zero's, so its becomes btnPin[4] = {0, 4, 0, 0}.

The problem is that "0" is a valid GPIO pin, however a "not specified" button should default to "-1" not 0.

We may need a better way for treating such "incomplete button lists" in WLED. Maybe by always setting btnPin[i] = -1 when finding int8_t(buttonType[i]) <= BTN_TYPE_NONE (BTN_TYPE_NONE is defined as 0). This could be done before feeding the button pins to the UI in xml.cpp - possibly cfg.cpp, set.cpp or json.cpp would also need the same adjustment. Downside would be that any "Disabled" button will automatically lose its pin number and become "undefined" in the UI.

Another option is doing this correction only once at startup, in WLED::setup().

I'm not really happy with the fix proposed in #4074, because it will break again when user set -D WLED_MAX_BUTTONS=x in their custom build environments.

[blazoncek]

I'm not really happy with the fix proposed in #4074, because it will break again when user set -D WLED_MAX_BUTTONS=x in their custom build environments.

I second that.

[PaoloTK]

I'm not really happy with the fix proposed in #4074, because it will break again when user set -D WLED_MAX_BUTTONS=x in their custom build environments.

I second that.

I am a bit confused by this. I initially was exploring counting the passed pins to set the rest up to WLED_MAX_BUTTONS to -1. However once I saw that this very issue was marked as "won't fix" with the workaround of setting unused pins to -1, I simply replicated that in code.

I agree that it's not the best solution because a custom compile can break it by setting a different WLED_MAX_BUTTONS value, but many things can be broken by improper flag configuration.

[blazoncek]

It just means you need to think harder how to solve the underlying issue. Not just provide a partial "band aid".

[PaoloTK]

It just means you need to think harder how to solve the underlying issue. Not just provide a partial "band aid".

I don't find the solution to be a "band aid" since you need to explicitly break it by configuring a different value for WLED_MAX_BUTTONS.
Nonetheless I agree that a solution that works no matter what is ideal.

@softhack007 I like the button type proposal and will explore it, thank you.