-
Notifications
You must be signed in to change notification settings - Fork 41
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
Glitching issues with patterns #20
Comments
I am also having these issues. The leading pixels are ghosting 'ahead' by a semi-random number. I need WiFi for my application, and disabling just bluetooth on its own doesn't have an effect. Since there is additional code running along side the FastLED animation, is there something that I should do to help isolate it from the rest? Can I do anything to provide more details for the issue? Thanks for any advice! |
@ntwallace You can't set the FLAG_LEVEL to 4 or greater because the ESP-IDF framework doesn't allow C programs to run at those levels. This is documented https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/hlinterrupts.html .
Giving me the minimum code that shows your problem - or any code - is what will help me resolve.
I don't have a lot of energy myself in fixing potential I2S jitter problems because I don't have them, but you can work with Yves, and I'll be happy to re-port his code fixes or yours. In order to improve I2S with jitter, it'll be necessary to determine if the problem is Wifi or Bluetooth (I know you say Wifi only), to see if there's a way to increase the buffering of the I2S code (like we did with RMT), whether the core you run on matters (espressif has suggested this), whether detecting the jitter and "bailing" is enough of a fix (Sam has suggested it will because I2S always sends on LED boundries so you'll lose a little output but the glitch will not be seen), and if so add the "bail" code, whether you can lower the priority of wifi and/or bluetooth, and finally whether there's a section of code that can be changed to ASM in order to allow higher level interrupt access. Maybe there are other areas to explore but that makes sense to me. |
@BorisKourt . I don't know what you could mean by "ghosting ahead". Ghosting is when you turn something (like a pixel) off, and it stays lit for a while, and then goes off ( like a ghost ). As I've written above, there is a bug in the I2S driver where it will send a little extra data, randomly, and set the pixel which is later than the size configured. This is the only bug I've been able to verify and have talked to Yves about. If you think you have a jitter problem, I believe the readme.md suggests that you switch from I2S to RMT, and then you turn on the "SHOWPIXELS" print so you can see if there are any "bailed" messages. It also allows you to see the number of microseconds between interrupts, and the amount of jitter, thus allowing you to raise the RMT buffer sizes to overcome. The only code issue I know about right now which I can work on is the issue with I2S generating the wrong patterns - simply wrong. I have written some test code which doesn't show this, and I have some complex test code that might show the pattern, and one submission from a user that they claim does show the I2S pattern incorrect problem. If you can submit (simple) code that shows an I2S incorrect pattern ( which works fine on RMT ) that would be a great help. |
Hey, void app_main() { // I have a 2A power supply, although it's 12v // change the task below to one of the functions above to try different patterns staticColor(); } |
For anyone having glitching issues while using wifi: Try changing the core affinity: I configured "Main task core affinity (CPU1)" and all other stuff i could find to CPU0. I only have a app_main() and i'm not creating any tasks. No glitching while streaming data via wifi and spamming serial. :) |
First off, thanks for this port--this was the push I needed to migrate my big LED projects from Arduino to IDF with Arduino as a component. Let me know if I can be of help with the hardware SPI driver at all.
I'm testing out running WS2812FX patterns on WS2812B LEDs and noticing a few different glitching and ghosting issues:
The last pixel always glitches white when I run a pattern. This happens on all patterns and with both the RMT and I2S driver. Disabling WiFi and Bluetooth doesn't make a difference. Here's an example running a color wipe on a 256 pixel matrix, same thing happens on standard strips: GIF link
I think there may be a data overflow with the I2S driver while running patterns. When using the I2S driver, I get a bunch of extra glitching pixels on past the amount I have defined for the controller. I don't have this issue with the RMT driver. This is the same setup as above (256 LEDs on one output), when I attach additional LEDs I get all this extra glitchy stuff: GIF link
I see some ghosting on the leading pixels of animations when WiFi or Bluetooth is enabled. It's hard to capture with my phone camera, but in the above two GIFs there's also an issue where the leading few pixels of the animation don't clear/animate smoothly sometimes. Disabling both WiFi and Bluetooth fixes the issue, so I assume this is due to jitter. I noticed in the I2S driver you put fillBuffer in IRAM, but I don't think the 0 flag for the esp_inter_alloc call adds
ESP_INTR_FLAG_IRAM
, does it? I can explicitly callESP_INTR_FLAG_LEVEL
as 1, 2, or 3, but if I add| ESP_INTR_FLAG_IRAM
I no longer get any output. SettingESP_INTR_FLAG_LEVEL
to 4 or greater also results in no output. Any thoughts on how to set the priority higher to avoid jitter issues?Thanks again!
The text was updated successfully, but these errors were encountered: