WLED allows more buttons than physical pins

[softhack007]

WLED/wled00/const.h

Line 113 in 439d4a0

#define WLED_MAX_BUTTONS 32

C3 has at most 22 possible pins, similar for the upcoming -C5 (max 29 gpio) and -C6 (max 29 gpio).
Some of these are not available because they are reserved for RAM, PSRAM, or Not connected (NC).
Classic esp32 has 39 possible gpio, but 11 of them are not usable => max 28 buttons if you don't connect any LEDs.

Is it intended to allow more buttons than physically possible on the board?

MAX_NUM_PINS is passed to the UI directly, meaning that more buttons can be defined than physicially availeable?

WLED/wled00/xml.cpp

Lines 326 to 338 in 439d4a0

	settingsScript.printf_P(PSTR("bLimits(%d,%d,%d,%d,%d,%d,%d,%d,%d,%d);"),
	WLED_PLATFORM_ID, // TODO: replace with a info json lookup
	MAX_LEDS_PER_BUS,
	MAX_LED_MEMORY,
	MAX_LEDS,
	WLED_MAX_COLOR_ORDER_MAPPINGS,
	WLED_MAX_DIGITAL_CHANNELS,
	WLED_MAX_RMT_CHANNELS,
	WLED_MAX_I2S_CHANNELS,
	WLED_MAX_ANALOG_CHANNELS,
	WLED_MAX_BUTTONS
	);

Edit: Normally i would expect that the max number of buttons is limited by the number of pins allowed as input, or maybe i'm missing something?

   int max_buttons=0;
   for (int bb=0; bb < WLED_NUM_PINS; bb++) 
       if (PinManager::isPinOk(bb, false)) max_buttons++;

[DedeHai]

pin restrictions should take care of that, i.e. you can't add buttons if there are no more selectable pins (will be much clearer with planned added dropdowns)

[softhack007]

Looks like it was added with #4757

In retrospective, I should have reviewed that PR ... is WLED going to be a keyboard driver 🤔 ? who needs so many buttons? Will the WLED pocket calculator usermod 😉 come soon?

will be much clearer with planned added dropdowns

You're right, we'll need that feature :-)

[softhack007]

btw, now that the box is open, maybe we'll soon need a new concept for "button inputs".

How can we handle

• I2C touch sensors - 12 or more keys - just 2 shared pins for I2C, but some registers to be configured at startup
• Keypads with serial output - serial UART
• "Matrix" style keypads, where 8 pins are needed to scan 16 keys (4x4 layout), or 12 pins for 64 keys (4x4x4)
• Keypads where several keys are encoded via resistors (analog reading on 1 pin only)
• Port expanders (I2C based, can handle a huge number of keys via shift register) - just 2 shared pins for I2C
• USB keyboards - on boards with USB support
• TM1638 "Leds & Keys" type boards (uses a special serial protocol, typically 8 or 16 buttons) - 3 pins
• IR remotes are basically just "keys" that don't need de-bouncing (same for esp-now remotes)

For me it seems that we need an abstraction layer that separates "key registration", "key reading" and "key processing".

Key reading might come from physical pins with knobs, potentiometer or sliders (analog pins), or any of the "keypads" i've listed above (extended usermod API?) - maybe even more. Processing could be common: de-bouncing, activating presets based on de-bounced "key reading".

[DedeHai]

who needs so many buttons?

all the people that use wled as a "button to color converter" ;)

[DedeHai]

For me it seems that we need an abstraction layer that separates "key registration", "key reading" and "key processing".

that sounds like a good thing to have, but I am not sure how it can be done without breaking backwards compatibility. For example, remotes go through remote.json and that needs to be preserved.

[netmindz]

btw, now that the box is open, maybe we'll soon need a new concept for "button inputs".

How can we handle

• I2C touch sensors - 12 or more keys - just 2 shared pins for I2C, but some registers to be configured at startup
• Keypads with serial output - serial UART
• "Matrix" style keypads, where 8 pins are needed to scan 16 keys (4x4 layout), or 12 pins for 64 keys (4x4x4)
• Keypads where several keys are encoded via resistors (analog reading on 1 pin only)
• Port expanders (I2C based, can handle a huge number of keys via shift register) - just 2 shared pins for I2C
• USB keyboards - on boards with USB support
• TM1638 "Leds & Keys" type boards (uses a special serial protocol, typically 8 or 16 buttons) - 3 pins
• IR remotes are basically just "keys" that don't need de-bouncing (same for esp-now remotes)

For me it seems that we need an abstraction layer that separates "key registration", "key reading" and "key processing".

Key reading might come from physical pins with knobs, potentiometer or sliders (analog pins), or any of the "keypads" i've listed above (extended usermod API?) - maybe even more. Processing could be common: de-bouncing, activating presets based on de-bounced "key reading".

Interesting idea, but think we have much higher priority issues

[softhack007]

Interesting idea, but think we have much higher priority issues

I agree - backlog.