I’m having problems with fastled and some ws2812b leds blocking my i2c communications. Does anyone know if there is a way to have it not block interrupts?
No, there isn’t. The timing requirements of the WS2812b are pretty tight and there aren’t enough clock cycles to even handle the dispatching of an interrupt, much less handling an interrupt.
I would rather have a bad refresh of the lights in this particular project because I’m interfacing to a quadcopter and don’t want to risk a crash lol.
You could remove the interrupt disabling code - where it is specifically depends on what controller you are using (clockless*.h - remove the calls to sei/cli - which set/clear interrupts). Or you could use an offboard controller dedicated to the leds and use a mechanism for communication that doesn’t rely on interrupts.
I will try disabling those calls, wasn’t sure where in the code it was. I am also changing around various other parts of my code to minimize the led refreshes so there is less chance of an overlap, but I need to be sure if it does happen the worst thing I get is a bad led update. BTW I love this library, it is excellent.
please let me know how it turns out, i was planning on using i2c to have a few teensy driving a few hundred leds communicate with each other.
If you’re going to be using teensys to drive leds and want to use interrupts - look into either using OctoWS2811 which, since it’s using DMA to do data transfer to the LEDs, doesn’t have to disable interrupts, or consider using DMA to do the inter-teensy communication.
Don’t use the interrupt function of I2C or just use it to set a flag to let you know you need to read. Then prior to showing leds check the I2C flag or available() function…
Ok everything is working well now. Commented out the parts of fastled that block my interrupts and that resulted in no more I2C errors but the number of corrupted led updates was a little too high in certain modes for me. I found that I2C updates were coming frequently enough that I could eliminate the call to my update function in the main loop and put it at the end of the I2C handler and my various flash delays still work reasonably well.
One needs to take precedence. How much data are you sending via i2c?