Trying to test out parallel output on a adafruit ESP8266 huzzah breakout board.
Getting this odd flicker on the first LED of each output. The flashing seems to be dependent on how many LEDs I ave configured in the strip. The more LEDs the slower the flicker.
It doesn’t happen in normal non-parallel output and if I disable interrupts it still occurs. Really strange but it’s my last barrier to being able to drive 1024 LEDs over 4 strips in parallel so I would love to solve it.
Any ideas?
While the parallel output code is in place for the ESP8266 it is currently broken.
Well for currently broken it works pretty damn well apart from that first LED!.
I’ve got it outputting stable 4x 256 LEDs per strip, I had to adjust the interrupt wait to 15us to get it stable, and set retry count to 3. But I’ll tweak that further once I have my wifi code in place.
Is there any hints you can give me as to where to start to fix it? I’m happy to dig in and give it a go as I’d like to learn a little more about the underpinnings anyway.
I’m going to lunch now but will chuck the scope on it and see if I can’t figure out what’s wrong with the first LED.
Feels like this is just a latching timing issue on the end of the ws2811 sequence?
Well so far I’ve managed to eliminate my hardware at least. Definitely a software issue as you suggested. It appears to be cumulative as well, initially when it starts up I get an occasional bad stream of data a few times a second maybe, then it takes a good few seconds to build up to the point where every other sequence is broken up incorrectly. The more pixels in a strip the faster this accumulates, so I’m guessing there’s a small timing issue that’s building up causing the main problem?
From what I can see writeBits in clockless_block_esp8266.h is the meat of the code related to this and I’m pretty sure this is where the problem will be. The backwards logic due to the transpose8x1_noinline optimisation is confounding me though 
@Daniel_Garcia holy crap I fixed it.
Turns out the showRGBInternal function in clockless_block_esp8266.h did not have the ICACHE_RAM_ATTR attribute applied to it, so it was being copied into the iram cache on execution of each frame messing with the timings.
Adding that one keyword fixed the first pixel flicker entirely, i now have 4x 256 strips outputting stable with no noise. I have bumped the interrupt wait up to 13, but as I said I’ll have to tweak that when I actually start using the wifi I’m sure.
I only managed to catch this as I was giving up, switching back to 4 separate controllers and ran into the “section .text' will not fit in regioniram1_0_seg’” error which I’ve encountered before when messing with these chips. I was digging around for functions to remove from iram to make it all fit, I removed the ICACHE_RAM_ATTR attribute from the showRGBInternal method in the clockless_esp8266.h (non-blocked) and suddenly I had the same bug in my single controller output.
Gotta love coding, you always solve it just when you’re about to give up!
Wow, well done! Could you share the fix?
I’ll file a proper PR tomorrow but for now just add the ICACHE_RAM_ATTR to the showRGBInternal method in the clockless_block_esp8266.h file in the platforms/esp/8266/ folder of FastLED source.
I’ve filed a PR https://github.com/FastLED/FastLED/pull/389 it will need more testing before merging, but feel free to give it a go.