Right, this is an ARM. The ideal situation would be to do the whole routine in assembly. The routine also has limitations based on if you are using the radio. Even though the routine is wrapped in no-interrupts the nRF51822 radio has priority even over that. There are other tricks to play when the radio is active.

T0H: 0.500µs. Extreme tolerance of spec (350ns ± 150ns)T0L: 0.937µs. Inconclusive whether this is in-spec (800ns ± 150ns) or not, but if it is, it's extremely close. (This one fell on the edge of my sampler, so the results alternated between 0.9583µs and 0.9167µs; I took the average)

I suppose it's possible that the issue here is not a protocol issue but a higher-level timing issue. The pattern I'm using is 21.2Hz for the whole pattern, with ten segments within the pattern, so I'm sending 212 updates/second. I was under the impression that this was well within the performance range of the WS2812, but perhaps I am mistaken. Or perhaps the issue is that I'm updating "mid-cycle" somehow for the WS2812, and I need to find a way to align my updates to avoid the behavior I'm seeing.

T0H: 0.500µs. Extreme tolerance of spec (350ns ± 150ns)T0L: 0.937µs. Inconclusive whether this is in-spec (800ns ± 150ns) or not, but if it is, it's extremely close. (This one fell on the edge of my sampler, so the results alternated between 0.9583µs and 0.9167µs; I took the average)

I'm quite rusty in assembly and a complete newcomer to ARM. tolson, is there anything we can do with the existing code to get this in-spec?

The waveform and specification you are using are for the WS2812 and are tight. The WS2812B is different.You can manipulate the number and positions of the NOPs to get it to work with your setup and/or convert more of the subroutine to assembler. For the WS2812B the T1L measured is even more so out of spec, while the others are OK.

I'm adding a new twist to the digital RGB LED strip issues. I finally got around to playing with the APA104 clone of the WS2812B. According to the Chinese timing specs for the APA104 the timing should be way off compared to either the WS2812 or WS2812B. But, I found that it works fine with my loadWS2812B() subroutine. What's up with that?! I don't know. But here is the video of it working...

I am having an issue with the APA104 strip though, in that upon applying power, all LEDs come on BLUE. To test if is was a timing issue like the WS2812(B) had earlier, I grounded the Data IN pin to the LED strip and cycled the power on and off. The BLUEs all come on. Hmm! So it is important to send zeros out to all the LEDs in the array as soon as possible during power on bootup. Anybody else seeing this with the APA104 LEDs?

The wordpress link I posted before explains much of how the protocol actually works. The LEDs have a 400 or 800 Khz internal oscillator. The weird protocol essentially comes down to latching bits after some multiple of cycles.

Yep, I know how they work. If you come across where the BLUE is suppose comes on "by design" please forward the reference. I suspect it is more like "oops". Does the "by design" spec say at what PWM level they come on at. Could really play badly with a power supply not expecting to run all the LEDs at the same time.

I will definitely send it if I can find it, but it's only a vague recollection. I'm sure you know there are more than a few poorly-translated "data sheets" for these, each claiming different timing specs. I could be mis-remembering some other forum post about them being blue on power-on, but I feel like I did see it at least described in one of those sheets. Maybe not "design" but at least "expected". But I hear you on the power-up concerns.

You might try contacting Daniel Garcia of FastLED fame. He knows these better than just about anyone I've spoken with. He might know.

APA104 have the same shape as ws2812b,ws2811, can be compatible as ws2812b,ws2811, can be use same control with ws2812b". So mainly, APA104 are for maintaining compatibility with older strips while the APA102 are not.

I'm adding a new twist to the digital RGB LED strip issues. I finally got around to playing with the APA104 clone of the WS2812B. According to the Chinese timing specs for the APA104 the timing should be way off compared to either the WS2812 or WS2812B. But, I found that it works fine with my loadWS2812B() subroutine. What's up with that?! I don't know. But here is the video of it working...

I am having an issue with the APA104 strip though, in that upon applying power, all LEDs come on BLUE. To test if is was a timing issue like the WS2812(B) had earlier, I grounded the Data IN pin to the LED strip and cycled the power on and off. The BLUEs all come on. Hmm! So it is important to send zeros out to all the LEDs in the array as soon as possible during power on bootup. Anybody else seeing this with the APA104 LEDs?

APA104 have based color ,when you power them without signal ,it turn on blue , and when it start ,it also have blue color ,but it is fast, normally if you don't pay attention , you will not see it , and ws2812b and WS2813 led Will not have this situation .

APA104 have based color ,when you power them without signal ,it turn on blue , and when it start ,it also have blue color ,but it is fast, normally if you don't pay attention , you will not see it , and ws2812b and WS2813 led Will not have this situation .

Experiment show that if you don't pay attention they stay on forever. You have to intentionally programatically turn them off as soon as possible in your program. If you do not, they never go out. Not good for a power supply not expecting to supply maximum power for entire chain.