Replies: 1 comment
-
Note that most users will use the i2s (DMA) method and not the UART, as it is the most compatible. The UART methods do have a lot of caveats with them. I wonder if this issue effects the DMA method? The Wiki should be updated to contain some caution about this discovered information. The Wiki can be edited by anyone BTW. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
firstly, my humble thanks to everyone who has contributed to this library.
TL;DR: I suggest the ESP8266 Arduino Core WiFi library interactions with UART interrupts to be mentioned in the documentation. Maybe here or here?
--
Recently, I have been working on a "smart lighting" project using SK6812 LEDs driven by an ESP8266 and this library. Due to hardware choices, I am limited to using UART1, and since I expect my code to use a nontrivial amount of CPU time, I specifically picked
NeoEsp8266AsyncUart1Sk6812Method
.At system startup, I want the LEDs to light up with a default color with as little delay as possible. Therefore I decided that some of the first things my code should do are to call
Begin()
,ClearTo(initialColor)
, andShow()
on aNeoPixelBus
object. Initially this worked fine. However, at some point I noticed that only a part of the LEDs was lighting up at startup, potentially with shifted colors.A long and somewhat painful debugging story short: setting up WiFi immediately after the aforementioned NeoPixelBus calls disrupts the driving of the LEDs, due to
WiFi.mode()
andWiFi.begin()
disabling UART interrupts. Maybe the moral of this story might be "do not assume anything as innocuous-looking asWiFi.begin()
to actually be that simple under the hood"?I was able to find no mention of this, neither here, nor the official ESP8266 Arduino Core documentation. The latter even lists NeoPixelBus as a compatible library without caveats. Maybe this kind of behavior is self-evident to someone intimately familiar with embedded systems. To me it certainly was not.
Regardless of whether the startup sequence I described makes sense – I did not measure whether calling
WiFi.begin()
first makes any perceivable difference, but I can imagine someone following the same reasoning encounter the same problem – I think documenting this behavior could be helpful, either here or in the ESP8266 Arduino Core docs. Within this project, maybe the wiki page for ESP8266 NeoMethods or FAQ #8 could be an appropriate place for this?Any thoughts? Thanks.
Beta Was this translation helpful? Give feedback.
All reactions