I've got a project receiving UART data on UART0 (Serial1) whilst driving a string of WS2812b's, using FastLED, on a Teensy 3.2.
The UART runs at 460800 bps, I'm driving 15 LEDs.
My understanding of the default timing of FastLED and WS2812b's is as follows:
1) Disable interrupts
2) Output data for first LED (~30uS)
3) Enable Interrupts for 5 uS, then disable again.
4) Output data for next LED
5) ...
In my case, I have serial data coming in at 460800 bps, therefore a new byte is available approximately every 21uS. Uart 0 has an 8-byte receive FIFO, so in theory, we need to service it (at least) every ~168uS, to shift the data out of the FIFO and into the soft circular buffer.
It appears, initially, that my LED data is being occasionally corrupted - this would suggest that FastLED is correctly enabling interrupts, but there is an interrupt running in that period which is longer than 5uS. Sure enough, defining FASTLED_ALLOW_INTERRUPTS to 0 (and thus disabling the interrupts between LED data writes), prevents the LED corruption (but of course, prevents the FIFO being serviced and thus serial data is lost).
Anyone got any ideas on this one? How long does it take to run that UART 0 status ISR? Are there other interrupt routines that could be running in there I should be aware of ? (I'm also using the audio library, but this issue occurs even when it isn't playing anything).
Unfortunately the design is committed to hardware, so leveraging Octows2812, or changing to clockable LEDs is not an option.
Thanks in advance,
Iestyn
The UART runs at 460800 bps, I'm driving 15 LEDs.
My understanding of the default timing of FastLED and WS2812b's is as follows:
1) Disable interrupts
2) Output data for first LED (~30uS)
3) Enable Interrupts for 5 uS, then disable again.
4) Output data for next LED
5) ...
In my case, I have serial data coming in at 460800 bps, therefore a new byte is available approximately every 21uS. Uart 0 has an 8-byte receive FIFO, so in theory, we need to service it (at least) every ~168uS, to shift the data out of the FIFO and into the soft circular buffer.
It appears, initially, that my LED data is being occasionally corrupted - this would suggest that FastLED is correctly enabling interrupts, but there is an interrupt running in that period which is longer than 5uS. Sure enough, defining FASTLED_ALLOW_INTERRUPTS to 0 (and thus disabling the interrupts between LED data writes), prevents the LED corruption (but of course, prevents the FIFO being serviced and thus serial data is lost).
Anyone got any ideas on this one? How long does it take to run that UART 0 status ISR? Are there other interrupt routines that could be running in there I should be aware of ? (I'm also using the audio library, but this issue occurs even when it isn't playing anything).
Unfortunately the design is committed to hardware, so leveraging Octows2812, or changing to clockable LEDs is not an option.
Thanks in advance,
Iestyn