User Boards Config Database or platformio_userboards.ini

[softhack007]

Is your feature request related to a problem? Please describe.

As we now support more MCUs (namely -S2, -S3, -C3), users sometimes want to share their build environments - good!

• https://github.com/Aircoookie/WLED/pull/2951
• https://github.com/Aircoookie/WLED/issues/966#issuecomment-1247956715
• https://github.com/Aircoookie/WLED/issues/2934
• https://github.com/Aircoookie/WLED/issues/1940#issuecomment-1214424062
• https://github.com/Aircoookie/WLED/issues/2735#issuecomment-1250058041 ... and similar contributions that we find only on discord.

We cannot add each newly working board to platformio.ini, as this would make the file unreadable, slow, and also impossible to maintain over several years. Also there is sometimes very little change like just different board= line so I would not create a new official buildenv just for that.

However it would also be sad if all the knowledge about "how I made my xyz board work with WLED" got lost over time.

Describe the solution you'd like To improve the situation, I can imagine these options

1. Add a "user board list" in our WLED knowledge base, and establish a mechanism for users to propose their custom build env: xyz for addition to that list. Downside: manual work for maintaining the list.
2. Create a file like platformio_userboards.ini on github - people would make a PR to this file, if they want to share their successful build envs. This would also require review before merge, and we initially need to clarify what are the "interesting aspects" for new additions - like different partition table, special default pins, default usermods for onboard hardware like displays, buttons, etc). --> Kind of "best practice" or "coding style guide" for adding new build environments.

What do you think?

Describe alternatives you've considered The alternatives would be a/ reject most board envs because they are not having enough "differences" to existing ones, or because they introduce platform versions which are not tested with WLED in general. b/ accept everything, and clutter up platformio.ini until it becomes unreadable.

Additional context It might appear a minor thing, but having a well-tested platform = is really important! Espressif is regularly breaking things with new releases, so we cannot rely on just following their latest versions without intensive testing on our side!

Thank you for your ideas for making WLED better!

[blazoncek]

I thought about it for some time and as much as I want all controller boards like Dig units, Serg's shields and others included as well as generic development boards it would really be a burden to maintain such list.

For controller boards platformio_override.ini should be provided by their respective manufacturer. While for generic development boards option 1. seems more appropriate.

[softhack007]

Another idea could be to enable "discussions", and create a category "boards". This would work with minimal maintenance effort, as users can simply create a topic for their board and summarize how they made it work.

@Aircoookie @blazoncek what do you think?

Would look like this

Of course other standard categories (discussions, announcements, q&a) could be removed because we have discord for "volatile" discussions.

[blazoncek]

Any and all non-default (official) build environments should go into platformio_override.sample.ini. From there any user interested can create their own platformio_override.ini as desired.

IMO WLED should officially provide generic builds not tailored to any particular development or controller boards if possible or feasible.

So far the following are distinguishing components:

• ESP chip used (ESP8266, ESP32, ESP32-C3, ESP32-S2, ESP32-S3)
• onchip/onboard PSRAM support (only relevant for ESP32 rev.1 due to HW bug)
• flash chip size (1MB, 2MB, 4MB, 8MB, 16MB, relevant for partition map)
• flash and/or CPU clock
• Ethernet support (for ESP32, possibly ESP32-S3)
• optional/mandatory features: Alexa, Loxone, Hue, MQTT, ESP-NOW, 2D, etc. (see poll on Discord announcements)
• optional usermods included (most requested: audioreactive, multi-relay, staircase, PIR, temperature, 4LD/rotary)

I talked to @lost-hope about possible changes to web installer, to build flashing environment on the fly.

ESP8266 keeps all data (flash size, CPU clock) within binary and will require binary for every option. ESP32 (classic) needs a special binary if used with PSRAM and the chip is rev. 1. All ESP32 variants require their own bootloader (which may differ for particular board configuration/revision, TBD) Partition map can be shared between different ESP32 variants, depends on flash size (which cannot be determined by web installer, though it technically could). Ethernet should have its own binary as it reserves large number of GPIO.