Add support for ESP32C6

[Lukaswnd]

This is just the first test code. for me it works quite well. I had to change a few lines of the base files. Maye create a new branch and put it there for a while. One we figured out the main problems we can clean up the code an push it to the main. There is a bunch of code I copied from the esp32s3 and one the p4 will be there these function can be used again, so I might make some changes to reduce duplicate code

[mrcodetastic]

I'm just having a look at the C6, and it seems it has one massive hardware limitation that they mention at: https://github.com/espressif/esp-idf/tree/release/v5.1/examples/peripherals/parlio/simple_rgb_led_matrix

To use this library with the C6 you'd pretty much need to rewrite the library as this library is whole dependant on the DMA engine taking control of looping the HUB75 output, with no CPU intervention or tasks.

⚠️ Because of the hardware limitation in ESP32-C6 and ESP32-H2, the transaction length can't be controlled by DMA, thus we > can't flush the LED screen continuously within a hardware loop. Instead, this example uses a task to split the screen flush into > multiple line transactions. This obviously will increase the CPU load and may also lead to a task watchdog timeout. So this > example disables the task watchdog by default.

Please note that, the example is only for illustrating the usage of parallel IO TX APIs, it's far from ideal for use in a real > product.

[Lukaswnd]

Well, no you don't have to rewrite the while library. One could simply call the show function in the DMA finished callback. This way it needs only a very little cpu time. It's not perfect, but it kinda works. I see a view artifacts and flickering, but this might be resulted by poor wiring and unstable power supply.

Of course technically the interrupt of finished dma could be sceduled with a few microseconds delay and it takes a few us until the dma starts again. I think this just results in a short time where all leds on the panel are off, so a little lower fps. I was kinda surprised aswell, that it works on the slow single core, while using wifi, filesystem and other sruff. If I remember it right there were some delays when using the filesystem. but I think the gfx was delay not the dma. I think there are some comments about this somewhere in the code

[mrcodetastic]

True. However, I'm not keen on advertising / implementing support for a SoC that doesn't support proper DMA. Using an alternative chip, like the $1 ESP-S2 would be a better option and reduce the risk of a flickery mess the minute one needs to use the CPU at the same time for useful stuff like WiFi and gfx routines.