These are chat archives for Makuna/NeoPixelBus

31st
Dec 2015
Michael Miller
@Makuna
Dec 31 2015 19:16
@alltheblinkythings if you want to discuss more about IRQ issues and sending data, lets use gitter rather than the issue.
Michael Miller
@Makuna
Dec 31 2015 19:23
@alltheblinkythings the thing I have discovered is that there is a level 14 IRQ that is not documented that is used by the wifi core for servicing (I suspect for hardware) that causes the issue. If you don't mask it, it messes up bitbanging. If you do mask it, then you are in unsupported territory. If you have it masked long enough for this IRQ to trigger twice, the chip resets. Once is ok. How long is too long? Don't know and the devs won't say. They just say its unsupported and that use another method.
If the Uart can't maintain consistency without masking this interrupt, then it will never be reliable.
There is another method using i2C features, but my understanding is that this is software, but the devs have stated that it will be supported and timing accurate without the need to mask the low level WiFi irq. Since they own both pieces and don't expose the details, we have to trust them, I guess ;-/
Michael Miller
@Makuna
Dec 31 2015 22:48
Another update, fixed the latching time between sends where it would allow a quicker send than is supported (could cause flashing).
Also, uses more of the uart buffer so less waiting. This should be more resilient to IRQs interrupting the code.
Also, exposed an experimental flag NEO_IRQLOCK in case problems are still being seen to find out if this could fix issues.