Implement Serial2 option for serial control of WLED while allowing GPIO1 & GPIO3 to be used for LED output

[michaelbaisch]

Is your feature request related to a problem? Please describe. I wish to use a QuinLED-Dig-Uno to drive LEDs while taking advantage of all the incredible features WLED offers. Additionally, I aim to control the LEDs using the Serial Feature. However, as stated in the documentation and code, Serial functionality becomes unavailable when GPIO3 and GPIO1 are in use. These are precisely the pins that the QuinLED-Dig-Uno Board utilizes for LED output. Given this configuration, it seems I cannot simultaneously use QuinLED, WLED, and the Serial Feature.

Describe the solution you'd like I would appreciate a solution that enables the use of QuinLED, WLED, and Serial in tandem. Ideally, this solution would involve designating two pins that are exposed on the QuinLED Board for serial communication. Although my suggestion is theoretical at this point (as I don't have the setup operational yet), it appears that one can manually define hardwareRX and hardwareTX using RX and TX. These definitions can then be employed in the Serial.begin() statements to specify custom serial pins. It would be even more awesome if this functionality could be accessed directly through the UI.

Serial.begin(rate, SERIAL_8N1, hardwareRX, hardwareTX);

If this approach is implemented universally, the serial debug feature would also be transmitted through those pins, which could be beneficial in some situations.

[blazoncek]

When you have a solution ready, make a PR if you want as this is not something a regular user would require. As for Dig* units, talk to @intermittech for possible HW changes or enhancements.

[intermittech]

I agree it's currently unfortunate that these pins are in use. This is a legacy hold-over from when the Dig boards were compatible with the ESP8266 on which you needed to use those specific pins, this remained while now being ESP32 only. I currently do not plan on changing the pins for these boards since it would bring a lot of confusion which pins to use on the boards. The Dig-Octa is the first board that breaks from using those set of pins so maybe that is an option? :) (It still uses those pins but since you have up to 8 LED outputs available, they can be easily avoided).

[michaelbaisch]

@intermittech, I am actually now considering the QuinLED-Dig-Quad. With this, I would have two LED channels alongside the two serial lines on the outputs. I can leave the TX ESP32 -> RX Arduino connection as it is with the uni-directional level shifter. For the other direction, I could use an external voltage divider and bridge the level shifter. Or is there a major error in my thought process here?

[blazoncek]

@michaelbaisch @softhack007 maybe we could consider adding compile time override for hardware Serial.

Disclaimer: I am not saying I'll do it. In fact, I will most likely not, but if someone is willing ...

[michaelbaisch]

I've found a workaround for the issue: I purchased the QuinLED-ESP32-AE+, which adds three additional outputs. This setup allows me to use LED1/GPIO16 on the main board and one of the three outputs on the extension board. Initially, I was pleased to see that the silkscreen indicated the other output on the main board, LED2/GPIO_3, as "TX", allowing me to use the existing voltage converter for a 5V output. However, it turns out the silkscreen on the QuinLED-Dig-Uno is incorrect, it is actually "RX." And the actual TX pin, 1, is not readily accessible. I modified the board by cutting the trace to the LED2 level converter and soldering the TX pin 1 to it. This modification allowed me to still use the LED1 output as a level-converted TX output in the end. Access to RX/GPIO_3 is possible by soldering a wire to the pins on the extension board. Using a simple 1K/2K voltage divider, the 5V Arduino Uno can communicate with it. It's not the most elegant solution, but it works.

Another aspect that's functional, though not ideal, is adjusting the serial baud rate to below 115200 in the WebUI, which is necessary for communication with SoftwareSerial on the Arduino Uno. In the web inspector, one can modify a select line to <option value="576">57600</option> and choose it, which works. I'm able to set other baud rates (also through cfg.json), but perhaps offering a few lower options directly in the UI could benefit others as well?