Does FastLED implement this string led length dependent end fame as discussed in articles below?
’
Summary
In summary, each update of an APA102 based LED string should consist of the following:
I don’t know for sure, but I expect it does. But note that many suppliers randomly ship SK9822s as APA102Cs and visa versa, the protocols are very similar but not identical. FastLED supports both 
@Jeremy_Spencer Just checked it with logic analyzer, adafruit on hardware SPI does this N/2 ones at the end of frame, Fast LED does not. I think this might be my problem, long strings might be corrupted by this thinking its a new update. I am going to start to include adafruit and see how it compared on these long strings. Not sure why this end frame would matter multistring vs single string though but study continues.
@Chris_Iannello @Jeremy_Spencer I remember a post a while back about this. Fastled DOES not do this because they assume that a refresh occurs when a start frame is sent. but its definutely a requirement, i do this in my libs and so do all other libs
FastLED does this as an end boundary:
void endBoundary(int nLeds) { int nDWords = (nLeds/32); do { mSPI.writeByte(0xFF); mSPI.writeByte(0x00); mSPI.writeByte(0x00); mSPI.writeByte(0x00); } while(nDWords–); }
The important thing is driving the clock enough to get the last of the signal through - I send these frames instead of all 1’s because if I send all 1’s and you define NUM_LEDS to be fewer than what you have on the strip you get random LEDs lighting up white at the end of the strip.
A more likely problem is FastLED drives hardware spi faster for apa102 than other libraries - try reducing the data rate to cut back on the long string corruption.
hello, from my experience for strip at 144 LED, you can drive at 8MHZ and they’ll be fine, at above 12 the same hardware will go crazy at pixels over approx. ~80s.
though I didn’t find in any case the end bytes making problem, I just keep them at recommended
@Daniel_Garcia When is end boundary sent? with 240 LEDs on ESP8266 NODEMCU (I am on hardware spi pins but understood fastled will be software spi) on dotstar library I see 120 ones at the end. I dont see those on fast LED…in fact I dont see 120 bits at all. At what point do you send end boundary?
From the show pixels method in the apa102 controller in chipsets.h:
startBoundary();
while (pixels.has(1)) {
writeLed(brightness, pixels.loadAndScale0(0, s0), pixels.loadAndScale1(0, s1), pixels.loadAndScale2(0, s2));
pixels.stepDithering();
pixels.advanceData();
}
endBoundary(pixels.size());
and i pasted the endBoundary method up above
i wonder if the esp32 compiler is going a little too aggressive on optimizing out the bitbang’d output when constants are being sent - i’ve already had one issue with that happening, wouldn’t surprise me if that’s what’s going on here. i’ll have to take a look at the compiler output later on.
Er, 8266 - same difference, though. Try setting the data rate really low (1mhz or some such) - my bet is that the delays would throw in enough extra complexity that the compiler will stop optimizing out adjacent writes to the same register.
@Daniel_Garcia Daniel, first I am very thankful for your time on this and the use of your library. Its wonderful work. Also, thanks for showing me the show method…you can tell I know very little about software, just enough get by. I think I can see this period. I have “what is this?” in my note but understand this is the end boundary you tiold me about. Now I am trying to do what you told me too on datarate…but while the width of the one changes from the clock, the clock period does not seem to change. Am I setting data rate right? see troubleshooting notes at this link:
https://drive.google.com/file/d/1nwxISDcF4hL2ZKn-CvWImMUZYOZfin7s/view?usp=sharing
Yeah - this is just confirming my guess that the esp compiler is doing some overly aggressive optimization that’s cutting out code needed for bitbanging this stuff properly. It’s going to take me some time to come up with a good fix for this.