[DigiKey "Smart Creation, Non-stop Happiness" Creative Competition] Pixel Smart Clock ESP32C3 Version Bug Sharing
[Copy link]
This post was last edited by Old Jerry on 2023-12-27 11:04
[DigiKey "Smart Creation, Non-stop Happiness" Creative Competition] Pixel Smart Clock ESP32C3 Version Bug Sharing
This pixel clock project has been worked on and off for more than a month. Due to the large number of functions to be implemented, bugs are also emerging one after another.
There is still a bug that has not been solved. The deadline for the project is getting closer. I would like to share the bug with you to see if you can help solve it.
For this pixel clock, I chose the most common ws2812 light strip on the market as the display. The ws2812 light strip is a 3-wire light strip.
The driving method is to give pulse signals through the signal line.
This driving method seems easy to understand. To control the pixel matrix screen, you only need to continuously send each frame of data to the signal line of ws2812. In order to develop quickly and not reinvent the wheel, I directly used the fastled library on github.
Writing out the WS2812 data requires some very tight timing, so tight that the FastLED library disables interrupts while writing out the LED data. This means that any interrupts that occur while the LED data is being written out will be delayed until all the LED data is written out. How long will this take? Depends on the number of LEDs. The WS2812 LED data takes 30μs per pixel. My screen has 256 pixels, which means interrupts will be disabled for 7950μs or 8ms.
By default, the fastled library is used. The esp32 chipset allows interrupts. The same code will not cause the matrix flickering bug when running on the esp32-woorm-32, but it will cause the matrix flickering bug on the esp32-c3 chip. After setting the interrupt to disable data transmission, the bug is still not eliminated. I read the wiki of the fastled library but still found no result. I found feedback on the same bug in the issue on GitHub.
Bug demonstration effect
8d14322c1516edc836c596482c47c217
It should be that there was an interruption in the data transmission process, and then the integrity of the data was disrupted. The interruption time was read as an abnormal influence, affecting the display of the overall signal.
This bug only exists on the esp32c3 platform, and the trigger condition is to turn on WiFi! I also tried to use the serial port connection method of the AWTRIX server, but after successfully connecting to the serial port mode and then turning off WiFi, the matrix flickering problem still cannot be fixed.
Alas, I wonder if it is a problem with the esp32c3 chip itself, which will cause a timed interruption of WiFi access after turning on WiFi? Will it affect the data transmission of ws2812?
The confusing part is that I clearly connected to the serial port of the AWTRIX server, and then turned off the wifi, but the abnormal matrix flickering bug still existed. Only when I did not call the wifi during the whole process, the display would not be abnormal.
This is the first time I use fastled library and drive so many ws2812 lamp beads, so I don't have enough experience. Next time I use feerrtos to ensure the real-time data transmission. Since interrupts cannot be used throughout the process, the key detection depends on loop reading, which looks uncomfortable. The same is true for peripheral reading. Next, I'll see if I can debug this bug. If not, I can only switch back to esp32-woorm-32 as the main control. I've thought of other ideas to use esp32c3.
|