74 LED WS2812B strip is flickering when connected to ESP8266 with Wi-Fi enabled

[krzychb]

I have been testing Fire2012.ino sketch with latest FastLED library (saved directly from GitHub) using WS2812B strip with 74 and 144 LEDs together with ESP8266.

Fire2012.ino works as expected when Wi-Fi of ESP8266 is off.
If Wi-Fi is on, the strip is flickering 😞

Has anybody tested ESP8266 in similar scenario? Do I miss something in configuration?
ESP8266 is all about Wi-Fi and I would like to set Fire2012 parameters (brightness, cooling and sparking) wirelessly.

I do not observe flickering for Fire2012.ino sketch when implemented with Adafruit_NeoPixel and NeoPixelBus libraries.

Here are my test sketches:
• EspNeoPixelBus
• EspAdafruit_NeoPixel
• EspFastLED

I really appreciate mature, feature rich and well documented code of FastLED and looking how to use it directly with ESP8266 without patching it with additional code.

Krzysztof

[msurguy]

Try adding FastLED.delay(1000 / FRAMES_PER_SECOND); under this line https://github.com/krzychb/EspFire2012/blob/master/EspFastLED/Fire.ino#L109 instead of doing manual delay via millis.

[focalintent]

@msurguy the problem with that is it then blocks the handling of wifi responses in a timely fashion.

@krzychb - what happens if you add #define FASTLED_ALLOW_INTERRUPTS 0 to the line immediately before you have #include <FastLED.h> - FastLED is different from the other libraries in that it allows interrupts to fire while processing WS2812 leds - however, if an interrupt takes too long to run, then it has to stop writing out the current flame.

Out of curiosity - where are you seeing flickering - is it at the beginning of the strip, the end of the strip, or across the entire strip?

(Note: I just ran an installation using esp8266's with 150 led tm1809 (similar timing issues as ws2812) with wifi on with no problems - and i was using wifi as both a heartbeat sync and to broadcast OSC data to nearly a dozen esp8266's).

[krzychb]

Thanks, @focalintent!

Sure enough, adding #define FASTLED_ALLOW_INTERRUPTS 0 resolved the issue 😄 👍
Flickering occurred towards the end of the strip - plese see this video

Thank you again for quick help 👍

Krzysztof

[Lightning303]

Seems like same issue as i had. Just a heads up. Not allowing interrupts will result in watchdog resets. On my project, roughly 1 reset every 5-10 minutes.

[focalintent]

Ok - yeah, what's happening here is the interrupts firing are cutting off the writing out of the frame data.

If you're hitting watchdog resets, grab the latest version of the code and try re-allowing interrupts - I did some timing adjustments on the retries (and upped the number of retry attempts).

[krzychb]

@Lightning303,

I just run about 100 min testing of Fire2012 on ESP8266 with simple web server enabled (to set up fire simulation parameters) using latest FastLED code from GitHub - 1b546b3

I am happy to confirm that I do not see any watchdog resets.

[TheAustrian]

@krzychb You might want to let it run over night to be on the safe side, i had wdt resets after about 12 to 36 hours with bitbanging and wifi but haven't tried the latest version yet.

[Lightning303]

I will definitely give the latest changes a try when i find some time. However you have to take into consideration that there might be a difference between having a webserver idling and a project where there is constant traffic. In mine i send 8 byte packages to my esp 24-60 times a second.

[krzychb]

@TheAustrian
This is very good point 😄
I have just set up a channel on ThingSpeak to monitor EspFastLed up time
Let's see if it will cut the mustard.

@Lightning303
My application is simple.
The more code and traffic, the more effort is required for successful debugging and stress testing.
I believe you will soon nail down the issue and identify the root cause!
Good luck 👍

[pi-ratte]

I just tested the latest github and it looks like the interupts are causing flickering for me.
My setup is im sending artnet to the ESP8266 (huzzah).
if i do a RGB walk over the leds:
interupts enabled = the leds behind the one lighting up flicker. so as the RGB walk runs the flickers get less as the walk gets to the end.
interupts disabled = no flicker, im yield()'ing right before and after FastLED.show() was running for an hour will test some more. And only calling show() when there is actually new LED info. (640 Leds configured)

[pi-ratte]

Ohh forgot to wrote im using WS2812B leds.. also without interupts it reset on me :( .
with interupts on i noticed if making fat white/black bars, it flickers white bars the same size down the line. nut zust random colors.
if i set #define FASTLED_INTERRUPT_RETRY_COUNT 0
the flicker is gone.

[krzychb]

As suggested by @TheAustrian I let the ESP8266 run over night and got the following result:

Time to do some troubleshooting 😄

[krzychb]

I run first round of testing of the three applications described in original issue report loading each of them on a separate ESP8266 module.

Test started on 29-May-2015 at about 11:00 CET and took about 30 hours. Each application was posting it's Up Time and free Heap Size to Emoncms.org. In case of self reset the Up Time is automatically reset to zero.

The number or self resets over the test period is summarized below:

EspFire 2012 Application	Number of Self Resets
EspFastLED	4
EspNeoPixelBus	0
EspAdafruit_NeoPixel	1

The cause of resets may be s/w, h/w or both. To eliminate h/w as the source of issue, I will move the s/w around using the same three modules in sequence below.

EspFire2012 Application	Test 1	Test 2	Test 3
EspFastLED	ESP A	ESP C	ESP B
EspNeoPixelBus	ESP B	ESP A	ESP C
EspAdafruit_NeoPixel	ESP C	ESP B	ESP A

Later today I will stop Test 1 and move to Test 2.

Any comments are welcome.

Krzysztof

[focalintent]

Is that with interrupts enabled or disabled?

[focalintent]

Actually, I might have an idea of what's going on (if this is happening with interrupts enabled) - I think the resets might be getting caused by the clock count register rolling over - if it doesn't roll over at 32 bits, but instead at something lower, some of the math that I use for timing would result in really long spins.

I can see about putting some extra guards in around that when I get home tomorrow.

[krzychb]

@focalintent,

I have disabled interrupts to avoid strip flickering:

#define FASTLED_ALLOW_INTERRUPTS 0
#include <FastLED.h>

Thank you for review of his issue.
Resets every 500 minutes or so for my application is not a problem.
My concern is if they are due to s/w or my h/w is faulty or power supply not adequate.

[krzychb]

I have moved the s/w around between modules after 22:00 (10:00 p.m.) CET yesterday as visible (reset of Up Time to zero) on chart below.

This was to eliminate h/w as potential source of module resets.
Unfortunately the issue with resets persists for EspFastLED and EspAdafruit_NeoPixel applications.
Also, as during previous test, EspNeoPixelBus did not suffer any resets at all.

This indicated to me potential issue with s/w. Therefore I attempted to compare code of all three libraries looking for differences how low level control of WS2812B is implemented.
I understand that FastLED (and Adafruit_NeoPixel) is using bit banging s/w control for ESP8266.
NeoPixelBus is using I2S DMA (as configured in my sketch) or UART, so pulse timing is done by silicon instead of s/w and interrupts.

Is my understanding correct that control of WS2812B by FastLED for ESP8266 is done using bit banging? Is there UART or DMA method implemented by FastLED for ESP8266?

I will keep this test running for another 12 hours or so and then do third swap of modules. If anybody is interested, the charts are available on-line under https://emoncms.org/dashboard/view?id=29419.

Any comments are welcome.

[focalintent]

It is done by bit banging - and I have no plans to support the dma/usart style unless I can get it to cover all the three wire chips FastLED supports - but I do know what's causing your resets and should hopefully have a fix today or tomorrow.

[krzychb]

Thanks, @focalintent.
Controlling of WS2812B fully by s/w, cutting in between Wi-Fi routines, is kind of acrobatics out of my reach 👍
I will be happy to set up a "cluster" of couple of ESP8266's to do quicker testing 😄
Krzysztof

[focalintent]

@krzychb grab the latest master@HEAD - this should get rid of your every 500 minute or so restarts :)

[krzychb]

@focalintent can't wait to test the changes once I am back home today afternoon.
Guessing your local time I see why "just say no to mornings... " :)
Thank you for your time helping me out with this issue.
Krzysztof

Update:
I have configured two ESP8266 modules that run Fire2012 with the latest 96704ee.
Application up time and heap size monitoring - https://emoncms.org/dashboard/view?id=29419.
Summary of previous three rounds of tests - https://github.com/krzychb/EspFire2012#stability

[krzychb]

I have loaded two ESP modules with latest commit 96704ee – ESP B used in previous testing, and a brand new ESP E. I have also reloaded EspNeoPixelBus application to ESP D - another brand new module.

The testing started at 20:40 CET on 2-Jun-2016 and took about 2100 minutes. The summary of results is below.

EspFire 2012 Application	Number of Self Resets	Module
EspFastLED_1	0	ESP B
EspFastLED_2	1 + 2 by manually cycling power	ESP E (new)
EspNeoPixelBus	0	ESP D (new)
EspAdafruit_NeoPixel	3	ESP C

The new module ESP E behaved suspiciously. It stopped posting data on Emoncms.org and I had to reset it manually two times. It used on average about 2kB more flash than ESP B loaded with identical application. I decided to remove it from testing.

The good news is the EspFastLED_1 application on module ESP B run without any resets throughout the whole test. With previous version of FastLED librarry application restarted on average 3 times during such period.

All modules are now restarted by cycling power and testing continues. Previously tested ESP A module is brought back to testing instead of suspicious ESP E.

To be continued… 😄

[unaiur]

To drive correctly a led strip in an ESP8266 board you need to use a hardware module. NeoPixelBus can use the I2S or UART1 modules. UART1 has a 128 bytes buffer, enough to store about 11 pixels. This gives enough time to the WiFi interrupt handler to keep the thing running. I2S uses Direct Memory Access so every pixel is written out asynchronously. I also contributed to NeoPixelBus an async mode for UART1, which uses interrupts to feed the UART1 asynchronously so the CPU can compute the next frame while the hardware module does its job.

[focalintent]

You don't need to - I have multiple projects that are using esp8266's with WS2812 style leds without using hardware - partly because, for me, parallel output is more important (and parallel output + shorter strips + interrupt's being enabled allows FastLED to work with this - I need to clean up the parallel output a bit more, then I should be able to publish that for everyone to use).

[unaiur]

I can reliably drive an 800 led strip with NeoPixelBus and output 30 frames per second. 2 parallel outputs is fine: you can put the ESP8266 in the middle of a led strip. But I see no point for more than 2 parallel outputs for two reasons:

• ESP8266 modules only have 9 usable GPIO pins and, usually, you want to connect some extra hardware to it (a button, a proximity sensor, an ambient light sensor...)
• You need extra point-to-point cables

PD: I just want to point you towards a solution. I don't want to start a flamewar.

[lance36]

@coryking im unable to light up at all my 5 led WS2811 strip with your fork.
i installed it right into Arduino IDE removing the official FastLED

if i just comment out //#define FASTLED_ESP8266_DMA it works just like before

maybe its because im not using a 3v3 <-> 5v level shifter? but should it matter on a strip so short?

and yes, im using pin 3:

#define FASTLED_ESP8266_DMA
#define FASTLED_ALLOW_INTERRUPTS 0
#define FASTLED_INTERNAL
#include "FastLED.h"
/*********************************** FastLED Defintions ********************************/
#define NUM_LEDS    5
#define DATA_PIN    3
//#define CLOCK_PIN 5
#define CHIPSET     WS2811
#define COLOR_ORDER BRG

edit: compilers seems to imply RGBW controller even if i havent defined FASTLED_RGBW.

 #    pragma message "Using RGBW controller as per FASTLED_RGBW define"

maybe that's the culprit?

[coryking]

I've only tested this /w the SK6812 RGBW strips and the strip below, which claims to be a WS2812b: https://www.amazon.com/gp/product/B00VQ0D2TY Could be timing? I kinda doubt it is a level-shift issue....

…

On Fri, Jan 5, 2018 at 5:16 AM, lance36 ***@***.***> wrote: @coryking <https://github.com/coryking> im unable to light up at all my 5 led WS2811 strip with your fork. i installed it right into Arduino IDE removing the official FastLED if i just comment out //#define FASTLED_ESP8266_DMA it works just like before maybe its because im not using a 3v3 <-> 5v level shifter? but should it matter on a strip so short? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#306 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgHqoJ4XRnNDZBOw_BuBsKCOIErlp5aks5tHiCvgaJpZM4IgVDm> .

[lance36]

I kinda doubt it is a level-shift issue....

Yeah same. tried it this morting on a 5m (98 IC) strip with a level shifter and had the same result.
What u mean timing? i seem to be unable to even light up my strip on the blink example. if i even mention #define FASTLED_ESP8266_DMA

i got a "workbench" set-up with a 5 led strip attached if you wanna take a guess...

[coryking]

stupid question -- are you using the right pin? The DMA stuff can only use GPIO3, which on my boards is the "RX" pin. In fact, it will completely ignore whatever pin you pass into FastLED...

…

On Fri, Jan 5, 2018 at 2:32 PM, lance36 ***@***.***> wrote: I kinda doubt it is a level-shift issue.... yeah same, what u mean timing? i seem to be unable to even light up my strip on the blink example. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#306 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgHqvxls1Z-aMa45fN6ec4HgYN-IuXSks5tHqLggaJpZM4IgVDm> .

[lance36]

Turns out, i was using D3 and not RX afterall...

buttery-smooth. great work.

[coryking]

Perfect. Glad to hear it!

…

On Fri, Jan 5, 2018 at 4:20 PM, lance36 ***@***.***> wrote: Turns out, i was using D3 and not RX afterall... buttery-smooth. great work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#306 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgHqnVRLxzK6yvqX055CCDHmsn05_wwks5tHrxmgaJpZM4IgVDm> .

[tonys0]

Hi guys - if someone is still visiting this thread...
My conclusion after many hours wasting precious time is that ESP8266 is not suitable for driving large WS8212 strips. What I finally did was I use Glediator protocol instead.
For those who are not familiar with Glediator, it is communicating over serial TTL logic. It starts with sending a 0x1 byte followed by red, green, blue byte for pixel 0, red, green, blue byte for pixel 1, etc. I added ten introduction bytes of 0x4 in front of this sequence to ensure some sync activity on the line. That way the starting 0x1 is easier to detect. So I attach a plain always reliable 5V Arduino mini for under $3 (so I do not need the level conversion) to my LED-matrix panel and run on it a trivial driver sketch translating Glediator protocol to WS8212. The ESP8266 is connected to the Arduino with serial cable from TX1 on ESP8266 to RX on Arduino. With the baudrate 1000000 I can easily control 32 x 16 = 512 pixels. (Remember the WS8266 control pulses are 800 kHz). By this I am also free from the risky hassle with electrical connections to LED-strips, jeopardizing both the strips and the ESP8266 output. This solution is so robust that I wish all of you struggling with FastLED or Adafruit_NeoPixel, NeoPixelBus library or whatever on ESP8266 good luck. My theory is, that Expressif has totally underestimated the possibility to run anything time-consuming and time-sensitive (like FastLED.show) without interruption. Their interrupt routines are far too long in time to be suitable as interrupt routines. The LED stripes need a very customized communication, that was obviously not tested by Expressif. On the other hand, serial communication is so well standardized, so that they would hardly dare to introduce any instability or unreliability in it. And it is not time critical. The serial sequence of one frame can be interrupted. First, when the whole frame is transferred, the Arduino sends it to the LED-matrix. People, who play with LED-matrices use the Glediator or Jinx! with Glediator protocol anyhow, so they might appreciate the same connection from the PC or the ESP8266. The only thing you need to do is replacing FastLED.show with something like @dersimn suggested on Nov 27, 2016

void ShowAsGlediator(bool doit) {
  static uint32_t fireTimer;
  if ((millis() > fireTimer + 1000 / FRAMES_PER_SECOND) || doit)
  {
    fireTimer = millis();

// dummy prefix for synchronisation
    for (int i = 0; i < 10; i++)
      Serial1.write(4);

// start byte          
    Serial1.write(1);
    
    for (int i = 0; i < NUM_LEDS; i++)
    {
      Serial1.write(leds[i].r);
      Serial1.write(leds[i].g);
      Serial1.write(leds[i].b);
    }
  } 
}

do not forget to initialize
Serial1.begin(1000000);
in the setup()

The doit parameter is there for bypassing the fireTimer. If you use this show-function for a sequence of animation, it is not critical to skip some frame, so you can send false as a parameter. But if you for ex. need to clear the matrix with one command, send true as a parameter.

If you declare the function prototype
void ShowAsGlediator(bool doit=false);
before the setup() you can skip the false parameter and call just
ShowAsGlediator();

Sorry wiseguys for this newbie talk :-)

[andgeno]

This is very interesting! I will have to try that out for sure. I had so much trouble to make all my different test LED strips display patterns correctly. I was thinking about off-loading the uC <-> LED strip communication to a simple Arduino but then again it adds to the hardware and requires two firmwares etc. etc. ... anyway, sounds great what you've written. :-)

[tonys0]

Hi @andgeno. Good to know someone is listening :-)
My journey started when I played with Glediator and tried to replace the Arduino Uno based WS8212 driver with ESP-01 (to save money !!!) I had never "enjoyed" so much frustration, as with this. It was just about conversion from serial to HIGH-LOW pulses!!! I suspected the WS8212 for their sensitivity, I tested condensators, resistors, pull-ups, level converters. and God knows what. I had no idea, that ESP-01 ambition is to handle probably 128 bytes serial buffer in one interrupt call - how stupid that might sound. Then I tried to use more sophisticated ESP8266 and ended up with ESP-32. None of them worked reliably for me. And from reading this thread - not for anyone else. And there were even scientifical analyses of random reboots etc. Hallelujah!
The most sophisticated of my projects was to use both cores in ESP-32 (one for WiFi server and the other for LED sequences). But the Arduino mini driver is the most reliable solution of them all.
With the Arduino IDE there is no trouble having two firmwares. The Arduino hardware driver is just there, attached to the LED-matrix, so you can forget it. You will never need to reprogram it unless you rebuild your LED-matrix. And it will gladly use the 5V power from the LED-matrix (with a 1000uF/6V capacitor over the terminals).

[marmilicious]

@tonys0 Glad you kept messing with it and thank you for sharing what worked for you. Good stuff.

[tonys0]

Hi @marmilicious, "messing" is the right word for it. No documentation on ESP8266 circuit and firmware and no documentation on WS8212 real schematics and electrical specifications. And if exists, it does not make sense (except maybe for some Chinese of course). To this, I must add usual Murphys law (secretly broken jumpers, missing groundings, things suddenly starting/stopping to work just by connecting the osciloscope probe, the GND level shift with USB - serial device etc.) The most frustrating thing was, that when it sometimes worked with one sketch it did not with another. I could never rely on it.
It is, of course, a little mess to have to add an extra custom routine with a few pre-requisites instead of FastLED.show, but it's worth it. Maybe some "nice guys" will eventually wrap it in a small Glediator library, because I am not that GIT-clever. After all, the pulse control of WS8212 is designed for short wires, while the serial (RS232) is for long wires (start, stop and parity bit if you want) which could be handy setting up a real control scenario for LED-matrix. Sooner or later you will need to connect your PC to it and run a real thing generated by a powerful CPU.

[tonys0]

By the way - has someone here tested the ESPixelStick ???

[Makuna]

I am going to just clear up a general comment made here. Esp8266 is able to sustain a solid signal for ws2812 (compatible) but you must use hardware features to do so; just like on the esp32 (and a lot of ARM chips as well). The issue for esp8266 is that there are only two hardware methods, i2s and uart, and each is tied to specific pins (there is no pin muxer); giving you a total of only three channels (i2s, uart0 an uart1) possible if you give up on serial support completely. NeoPixelBus supports all these as asynchronous sends.

The number of LEDs is a memory and time constraint (the comm protocol takes time to send thus long strips will have lower update frequency).

The FastLEds use of RMT hardware on esp32 allows it to split the update across multiple bus and increase the update frequency.

And yes, having long lead wires between the uC and the first LED can be a problem, especially on a 3.3v uC when the LED expects a 5v signal.

[tonys0]

Hi Michael @Makuna.
You should only know, how much I tried to use the NeoPixelBus library of yours - a genious work. But I gave up upon that too - and so did many others - there are followers with other libraries. Why would so many people struggle with different approaches to solve such a simple issue, if it was reliable from the beginning? It should be implemented in the FastLED and Adafruit NeoPixel long time ago.

But I am really happy to have the opportunity to get in touch with you, great man. Can you suggest to me, how do I solve the conversion from Glediator protocol (USB serial) to the WS8212B with an ESP-01 ? Where do I find the document saying that the DMA is not on ESP-01 ? Can I use the TX1 for UART1 output (IO2) method while using RXD for serial input? What do you mean by "asynchronous UART" method opposed to "normal UART" method? Isn't UART asynchronous by definition?
When using ESP-32 two cores. Both cores use the same I/O HW right? How are the interrupts treated? Will one core take care of the interrupts, while the other works uninterrupted? Why do I have to make the core 0 busy with some dummy I/O to prevent reboot?
Sorry for all these questions, that may not belong right here. I was just caught by the chance to ask you.

[tonys0]

Can anyone reopen this "Closed" thread, since it is obviously visited and the issue is not solved ?

[focalintent]

For what it's worth I have done multiple installations with ESP8266's and ~150 WS2812 leds using wifi for communication/synchronization and no flickering issues (I almost always use level shifters, and power injection and such) -- including one that had ~32 esp8266's sharing a wifi network for synchronization/communication - and this is with using the stock FastLED software - so this isn't a constant issue - and I think it's an issue of wider hardware/software/wiring/power/etc... and beyond the scope of a FastLED issue to be fixed at just the library level.

[focalintent]

That said - where I see people run into major problems is where they are effectively using FastLED as a frame buffer, where they are pushing full frames of LED data over wireless or serial (or less frequently, ethernet) - and this is decidedly a mode of use that is not a priority for FastLED development - my focus and interest has almost always been for on-device generation of animation and LED data (in my own installations, I use wifi for sync and command and control - I'm not slinging full frames around). For situations where folks just want a frame buffer that's driven by computer, there are dedicated solutions that are designed just for that (pixel pusher, fade candy), and I will admit that it is not a style of use I've ever prioritized for FastLED.

[tonys0]

Hi Daniel @focalintent and welcome to the closed thread.
150 LEDs is hardly a decent matrix. If you don't send frames, then you probably have them recorded on SD card as notoriously repeating ads or some other dead content. I am using a 32 x 16 matrix and I want to build another one just for more space for complex graphics. My interest for LEDs started with watching LED-cubes, but I soon realized that no matter how big (read: expensive) cube I build, I would want bigger. So I built it in VR in Unity with the size (LED count) as a parameter. And yes, I can roll the cube in 3D space while running the light show in it.
Later I was impressed by the people doing this: https://www.youtube.com/watch?v=E8Ecz_sntDo and I was curious, how could so many elements be individually controlled with almost no wires. The intelligent LED-stripes with one-wire control was the answer.
Recently I am impressed by the Glediator and Jinx! software (Jinx! for the possibility to create images and effects with its simple script language). Unfortunately, both seem to be abandonware today. I really want to play with the light show effects and not spend long nights tweaking the hardware to work without flickering.
You see, I don't know much, so I am trying to find my way experimenting by myself and listening to other peoples problems. And on this thread, you can see quite a few of them. When the uC is randomly rebooting, it is a disaster that I cannot accept. You don't want to have randomly rebooting webs, do you? I am not going to make statistics on reboots and be happy, when they are only twice a night. That would be probably acceptable in China. But I want things to work and rely on them, so I can sleep.
With that said - I am going to use the Glediator protocol until the day someone tells me there is a reliable (and cheap enough) device programmable in Arduino IDE for WS8212 control.

[focalintent]

If you don't send frames, then you probably have them recorded on SD card as notoriously repeating ads or some other dead content.

Wrong, on so many accounts. Everything I build runs dynamically generated and responsive animations on MCU. If I'm using the wifi connection for anything, it's for synchronization/high level control across multiple devices.

If what you want is to send frames from a computer for display on a cube or a matrix then FastLED is the wrong platform to be using. You should be using pixel pusher, fade candy, octows2811, or a setup similar what you've stumbled onto with gladiator. This is a use case that I have repeatedly made the conscious, explicit decision to not focus on supporting with FastLED.

And on this thread, you can see quite a few of them. When the uC is randomly rebooting, it is a disaster that I cannot accept. You don't want to have randomly rebooting webs, do you?

And the reboot cycling is setup/code/environment specific (and there have been fixes added in the two years since this was opened that mitigated the ones that can be at the FastLED level) - my esp8266 projects only reboot when I hit the reset button (or flash new code to them).

[tonys0]

I can reliably drive an 800 led strip with NeoPixelBus and output 30 frames per second.

Hi, can you describe your situation in more detail? How do you feed the pixel-data to the ESP8266 or is the pixel-data generated from the ESP8266? Do you use WiFi or serial communication? Which method do you use for NeoPixelBus? How is the physical connection between the ESP8266 and WS8212 ?
Thank you.

[Makuna]

following on to what @focalintent stated I have focused NeoPixelBus to support updating even with WiFi, I have limitiation due to it, but it will work without crashing.

I will link to my Wiki for esp8266 specifics and I will discontinue on the topic here.

You can chat on the NeoPixelBus gitter channel if you have questions about it.

[tonys0]

Hi Daniel,
I have to apologize to you. As a stupid newbie, I did not know, that you are the father of the ingenious FastLED, which is by many people preferred for driving LED-strips before NeoPixel library. So for what it's worth, you have my full respect and admiration.
You see for a newbie it is difficult to see what a class can offer. He starts with some fancy examples and uses the properties and methods from the example. For me, it is still a mystery, where all the properties and methods are documented for a human (I am not capable to understand them reading the C-code). Next thing to expect would be a list of limitations and recommendations on how to use it, what to use it for and what not. I know, programmers hate to create documentation which is soon obsolete, when they change the program. But it would save millions of people (your supporters) time and disappointment.
Or am I missing it, just because I don't know, where to find it?

I can respect your conscious, explicit decision not to prioritize "slinging full frames around". Just tell me, how do you create an animation with 32 devices, that (I suppose) display one complete picture, without sending at least parts of the frame around? I can see, that the power of FastLED is in creating animation in the device. But there must be a way to send the displayed objects between the devices...(?)

Your personal preference not to sling full frames around should not prevent you from using the hardware in devices, that are offering DMA. Believe me, there are many people, who would appreciate having a solution like NeoPixelBus integrated into FastLED. Even if you like "banging" there are certainly other useful tasks for the CPU that can be performed, while the hardware takes care of sending the pixels to the strip uninterrupted. Why don't you join your forces and experiences with Michael instead of trying to convince each other about the advantages and limitations of each other's work? Isn't that what Github is for?

Another thing. ESP8266 is a risc processor, isn't it. What I do not see is how are the principles of risc processor applied in the code. You still write
for (i = 0; i < n; i++) a[i] += 5;
instead of
apply a[i] += 5 to following amount of consecutive bytes, pixels etc.
or does the C-compiler take care of it?

[CRCinAU]

So yeah - this is still happening - now I'm only on 46 LEDs and get resets even when all LEDs are off...

Has there been any progress / consensus on solving this as yet?

[joysfera]

Release 3.3.3 - flickering with interrupts enabled, watchdog resets within minutes if interrupts disabled.