neopixel crashing the the board?

So, we may file this under speculation then?

'pulse duration would be too short'

I don't believe this applies as the pulse train is a fixed duration based on four bits each. Looking for where I read that. Those two lines apply to a waiting state.

Related to this creating the pulse train, and likely how Neopixels were done before the tutorials.

http://www.espruino.com/Reference#t_l_SPI_send4bit

One reference by @allObjects #2 but not the one I'm after:

http://forum.espruino.com/conversations/330532/

We are all end users acquiring new skills while experimenting with our new ideas.

One can certainly learn the hows and whys while peeking under the covers. But it was the post title along with the explanations that just weren't adding up.

I'm curious what prompted the initial post. It struck me as a bit odd to single out those two lines of code, as most (myself included) typically aren't concerned with how things work under the hood. I actually hadn't looked at the Neopixel code until this thread. What sent me off in detective land was based on a daily hammering on the limits with Neopixels as I heard rumblings that Javascript was never going to be fast enough. I put that noise to rest over a year ago building a module to produce animations using the WS2812B x 60 strips and running on the Pico. Had to take a break as the source was growing just too large to run on the MDBT42Q and Pixl even with 'inlineC' sections. The limiting factor was more of the incorrect use of setInterval(). Produced some amazing animations along with sequencing and color changing. As there hasn't been a recent demand for examples, I may get back to a tutorial this winter.