Anybody here ever had issues with reading Serial data while running animations on a large set (2000+) of LED’s using FastLED? After some tests it seems as if the Serial data is interrupting the timing of FastLED creating some unwanted flickering. When I stop the serial output the flickering stops immediately.
what about using good old RTS/CTS or XON/XOFF to receive the data in a pause between each frame of WS28xx data
Yeah my current idea was to actively request the data when the teensy can handle it and have the other side respond only then, but it feels like there should be a better solution to handle the interrupts in an other way…
What platform and what leds are you using? If you’re using WS2812’s, they keep interrupts disabled while writing out the led data - this can cause incoming serial data to become corrupted, if you’re relying on reading data while writing out led data. If you are using one of the arm platforms (teensy 3/3.1, due, rfduino) they allow running with interrupts enabled, however if the interrupts take too long to handle then it will stop the writing out of the current frame of leds, which will cause leds at the end of your strips to not update properly. There is some threshold of interrupt length, however, where a handler can be short enough to not be caught by my “did your interrupt handler run too long” catch, but long enough to mess with your led writing. In which case, you can re-enable complete interrupt blocking as described here - https://github.com/FastLED/FastLED/wiki/Platform-limitations
The best way, however, to handle the interrupts is to switch to a four wire led chipset (e.g. the APA102), which doesn’t require disabling interrupts.
Thanks, thought this would be the case. We’re using the WS2811’s so my best bet is probably going to be to change the way the leds are being controlled and disable the interrupts all together. I’m not really in a position where I can change the kind of LED’s we’re using as there’s a lot of hardware already set up.
After some quick testing just asking the computer controlling the animations for data in the update loop of the teensy seems to work pretty well without much overhead, so that’ll be my safest bet to get all the flickering out of the setup while still allowing me to control everything from outside the teensy.
How about using an OctoWS2811 if you are using a Teensy 3.1. You don’t have to use all the channels and the data output is controlled by DMA. I think @Daniel_Garcia will confirm that interrupts are left untouched by default.