Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for ESP32C6 #640

Merged
merged 4 commits into from
Jul 4, 2024
Merged

Conversation

Lukaswnd
Copy link
Contributor

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 mrcodetastic merged commit e8d92c3 into mrcodetastic:master Jul 4, 2024
5 of 6 checks passed
@mrcodetastic
Copy link
Owner

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
Copy link
Contributor Author

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants