Add 5th output to QuinLED Dig-Quad (and ethernet variant)

[henrygab]

The QuinLed Dig-Quad is advertised as supporting four outputs.

In Quindor's video on the v3 board, he shares a secret: Q1R (the relay output) has exactly the same components (level shifting and protection) as the LED outputs. Therefore, GPIO15 (Q1R) could potentially be used as a fifth LED output. Of course, it could also be used as a GPIO to drive a relay.

It appears RMT_LAST defines a hard upper limit on number of RMT-driven outputs for the platform

It's possible I don't fully grok this. Here's what I base this statement upon:

• RMT_LAST is an identifier defined in the platform-specific header
• enum e_OutputChannelIds { ..., OutputChannelId_RMT_LAST = RMT_LAST, ...} -- thus it defines an enum value (a compiler constant)
• The OM_IS_RMT macro ensures CurrentOutputChannelDriver.DriverId is less than or equal to this value.
• The OM_IS_RMT macro wraps all attempts to create an output channel using an RMT channel for output.

Therefore, if a platform defines RMT_LAST as 2, it seems this will be compiled to a hard-coded limit to only allowing two of the RMT channels to be used for that platform.

Based on the above, should the QUINLED_QUAD and QUINLED_QUAD_ETH have RMT_LAST set to 5 (rather than 4), so that it could be setup to drive a fifth string of pixels? Presuming yes, and given that the fifth channel should not default to being enabled (as it might be setup to control a relay)?

For example, rather than:

#define RMT_LAST                OutputChannelId_RMT_4

Should these headers have:

#define DEFAULT_RMT_4_GPIO      gpio_num_t::GPIO_NUM_NC
#define RMT_LAST                OutputChannelId_RMT_5

I ask because I've not seen anywhere else in the current code base use gpio_num_t::GPIO_NUM_NC, and thus I wanted to check that suddenly using this wouldn't unexpectedly break stuff.

[MartinMueller2003]

You were good until you got to "GPIO_NUM_NC". Give it a real GPIO value that is correct for the QuinLED boards. These are the defaults per output port independent of how the port is being used.

It seems you are misunderstanding the default state for any given output port. While a unique GPIO must be assigned to a port, the default protocol for all output ports is the "disabled" protocol. When a port is dynamically bound to a protocol and that protocol is the "disabled" protocol, the GPIO becomes unbound / input.

If you let me know which port is the 5th output port I can add it to the definition.

Based on this discussion, it would seem that the "Relay" protocol is also a viable option for the QuinLED boards.

[henrygab]

Hi Martin,

Thanks for the explanation. I've provided a PR that, if I understand this correctly, will enable the 5th output and enable the relay "protocol" on that output.