Wled: Ability to define pins

[pauldogg]

Switching to Aircookie because looks powerful, would like to keep existing pin setup (hardwired) by defining pins in UI.

Thanks

[Aircoookie]

Hi! You can change the pin in NpbWrapper.h if you are building from source. What pin do you need?
I can send you a custom binary tomorrow. Changing the pin in UI is something I'd like to support (alongside with multi pin support), but i have yet to figure out how I can do that dynamically at runtime.

[pauldogg]

ah I see it now. I'll give it a whirl.
I'm using APA102's, on an Adafuit Feather huzza 8266; which one is Data and which is Clock in NpbWrapper.h?
I had
data_pin: GPIO12
clock_pin: GPIO15
and GPIO0 for the power supply relay.

Thanks!

[fribse]

Yes please get this defined in software somehow
With Quindor's Diguno you have so far compiled a seperate version, which seems silly.
It would be great to have a setting in the LED prefs that said 'standard pin' / 'quinled' / 'something else' or something in that direction.
That would make the compiling of versions less complicated.
Currently the "pin16" version is working perfectly with the diguno :-)

[thedannymullen]

@Aircoookie I wonder if you change the pin can you write it to flash then force a reboot to read in the new mapping? Only way I could think of changing during run time.

[Aircoookie]

@thedannymullen it should in fact be possible to reconfigure the LED driver without rebooting (I am already doing that for LED counts). The problem is that the driver needs to be pre-compiled (APA102, WS2812 over UART, over DMA, and bitbang, as well as RMT and I2S on ESP32 all require different driver code). I hope it's howev possible though to include all the drivers and dynamically swap between them (or even enable multi-pin output).

[huggy-d1]

With Quindor's Diguno you have so far compiled a seperate version, which seems silly.
Which binary are you talking about? I used the standard build with the GPIO2 jumper on my QuinLED Dig Uno.

[fribse]

Well, you need to use: WLED_0.8.6_1911081_ESP32_ledpin16.bin for quinled dig uno for ESP32.

[jamesmyatt]

Simplest option would be to make the option available only when WLED is compiled with the bitbang driver. Then you can either choose the hardware drivers or the ability to reconfigure the data pin.

[Jchuchla]

I wanted to add an vote to be able to change the data pin. I'd love to run this on an ESPixelStick hardware which is based on the ESP-01 with only limited GPIO available. I'm pretty sure it uses GPIO2.

[datadrian]

I'll add my two cents. really wanting to use tuya convert to upload WLED to my wifi bulbs so I can address them over e131. changing the pin would be amazing!

[scruffynerf]

+1, got a bunch of Wio Links, which don't expose GPIO2, but have tons of other pins (12,13,14, 3, 5, are all correctly placed to match the Grove LED strip as wired without change) but lacking an out of box config and requiring compiling just to change the output pin seems really annoying for such a simple and common problem.

[tablatronix]

What led driver does this use? neopixelbus?

[jamesmyatt]

What led driver does this use? neopixelbus?

Neopixelbus. In particular, it might use any of the drivers provided by neopixelbus.

[MNatzke]

Changing the pin in UI is something I'd like to support (alongside with multi pin support), but i have yet to figure out how I can do that dynamically at runtime.

Maybe I have misunderstood you, but I think it is not necessary to allow dynamic PIN assignment at runtime.

Nobody will have to change their hardware at runtime and assign different PINS accordingly. So it would be sufficient to enter the PINs in AP mode, or to enter them in the configuration and apply them to the actual EEPROM settings at restart. Alternatively, you can get some suggestions from Tasmota, where all PINs are available at runtime and the corresponding functions can be assigned.

[fribse]

That is true, it's a question of setting the pins on installation.

[tablatronix]

I posted this question on a related issue also. Would have to compile wled with all NPB drivers, or at least bitbang to let you use any pin.

https://github.com/Aircoookie/WLED/issues/1206#issuecomment-699684032

[Aircoookie]

@MNatzke @tablatronix Yes of course, setting the pin dynamically means supporting all the possible driver methods for all LED chips and pins. I cannot say for sure yet, but I don't think the overhead will be that large.

For installing WLED once when you know how to compile it, there is indeed no benefit in making the LED type & pin setup at runtime. The problem is when you want to update the board to a newer release, you'll always have to change the pinout and at that point you might not know the pin you used with a given board anymore.

By far the biggest problem arises with binary users though. I often get inquiries for custom compiled binaries for a non-standard pinout. Additionally, the release has many binaries for different LED types and pinouts. Making them takes time and that results in fewer releases, also the sheer number of binaries confuses some newcomers as to which is the one they need.
That will be the main benefit, there will just three binaries, one for ESP8266 (4MB), one for ESP8266 (1MB) and the last for ESP32.

[tablatronix]

I am working on a usermod to use any pin for an indicator, and doing something like

    NeoPixelBrightnessBus<NeoGrbFeature, NeoEsp8266BitBang800KbpsMethod>* neoInd = NULL;
   .....
 neoInd = new NeoPixelBrightnessBus<NeoGrbFeature, NeoEsp8266BitBang800KbpsMethod>(1, _rgbIndPin);

There might be a better way, I am not very familiar with the template system NPB uses