LN882H WS2811 Driver

[jasperro]

This PR is related to https://www.elektroda.com/rtvforum/topic4083817.html

It implements WS2811 support for the LN882H platform.

I will still be adding some documentation and the ability to change the data pin using a pin role, after which I will unmark this as draft.

[jasperro]

I think this one is about ready. Before merging, it is needed that openshwprojects/OpenLN882H#19 is merged. The .gitmodules file and modules can then point to the main OpenLN882H repo again.

Small note: it seems there is a small issue in the Makefile introduced/which got influenced by the ESP-IDF changes, which made it impossible to build locally using the docker image. Locally, I changed the line under the .PHONY submodule from git submodule update --init --recursive --remote to git submodule update --init --recursive, after which I could build again.

[openshwprojects]

Nice, WS2811 on LN88H, altough it would be better to have it togeter with current SPI LED for Beken, instead as separate driver. Btw, I don't think you can add pin enumeration inside enum without breaking people configs... also , why pins header change?

[jasperro]

Nice, WS2811 on LN88H, altough it would be better to have it togeter with current SPI LED for Beken, instead as separate driver. Btw, I don't think you can add pin enumeration inside enum without breaking people configs... also , why pins header change?

The pin header change was because LN882H pins are weird. They have a base and then the pin. By splitting out the pin definitions into a separate header file, I could use this to call LN882H hal functions in drv_ws2811.c (which require base and pin) with OpenBK7231T_App pin index.
I'm not sure if this is the best way, but it is the one I could make work.

The reason it does not work like the BK SPIDMA/SPILED is because LN882H has direct HAL for WS2811 in the SDK. This way, I could just easily use the already existing code. I think the LN882H has some built-in WS2811 circuitry that doesn't use SPI at all, only DMA. So it would not make sense to use SPI if this is actually not supposed to be used.

Now I have made a drv_SM16703P.h, that is implemented by drv_SM16703P_LN882H.c and drv_SM16703P_BK7231N.c for both platforms. It is working quite nicely (with DDP working and PixelAnim working except for ShootingStar, I still need to implement some more stuff). Not sure what to do with the docs, one of the two driver files needs to be chosen as the single source of truth? Or maybe the command registration should be done in drv_SM16703P.c.

The old version can still be found here: https://github.com/jasperro/OpenBK7231T_App/tree/jasperroLN882H-WS2811-old

Also, with "Btw, I don't think you can add pin enumeration inside enum without breaking people configs...", do you mean you store the enum backing int in the config instead of the string? So if I add it in the middle it does not work for existing configs? (but in the end shouldn't break it), now with the new SM16703P-only driver should not be a problem of course.

It would be very nice to get this merged eventually.