In some of the discussions I've found online, and in all of the example sketches, there is a delay() from one to three seconds immediately upon entering the setup() function. Usually with a cryptic comment like:
// for sanity
or
// sanity check delay - allows reprogramming if accidently blowing power w/leds
So, what is the real purpose of the delay?
Which leads into the question of Power Sequence. Is there a problem of powering the LED strip/string without data (I.E., Arduino is unpowered)? Or turning the LED power off, but leaving the Arduino running?
I suspect someone put it in an early example and it just got copied. I can see no reason for having it and I have never used it myself.
Is there a problem of powering the LED strip/string without data
No.
Or turning the LED power off, but leaving the Arduino running?
Yes, you can burn out the first LED. That is one of the reasons you have a series resistor in the data line, to limit the current under those circumstances.
Lightbreaker from the Git gave me the definitive answer:
"It's there because in some situations, if your code suddenly lights up a lot of LEDs very brightly, it causes a voltage drop across the microcontroller, and the MCU goes into a "brownout reset" loop. If you're in the lab, and can easily disconnect the LEDs and reprogram the MCU, you don't need any delay -- just to unplug the LEDs. But if you can't easily unplug the LEDs from the MCU, e.g because it's all soldered together, or inside some enclosure, or high up on a wall, or out in the desert, having a couple of seconds to quickly start the reflash process can be enough to save the day. Dan and I both had the bad situation happen numerous times, and so we just started putting a startup delay in the beginning of all of our sketches.
It's not needed. It's insurance. And how much insurance you need depends on your circumstances. Use your own judgement. But as a general matter, it's not a bad place to start out with a few second delay before lighting any LEDs, for reasons described above.
Alternative: have a slow ramp up in FastLED.setBrightness(...) over the first few seconds. That's what I sometimes do now with wearables and other things where I want to see some light right away when I turn it on, but also want the insurance of being able to escape the brownout reset loop."
SteveMann:
"Lightbreaker" is one of the contributors to the fastLED library. (AKA Mark Kriegsman).
So it seems, but that doesn’t stop him from having wrong ideas about what is going on with hardware.
Or to be charitable is a bit crap at describing what is happening.
It's there because in some situations, if your code suddenly lights up a lot of LEDs very brightly, it causes a voltage drop across the microcontroller, and the MCU goes into a "brownout reset" loop.
If some unspecified situation does light up all the LEDs at once, and the design is so poor that the power supply can’t cope, then how is a delay going to do anything to elevate the situation. His explanation makes no sense what so ever.
Git" is short for GitHub.
Do you think I don’t know this? I also have a git account.
Grumpy_Mike:
So it seems, but that doesn’t stop him from having wrong ideas about what is going on with hardware.
Or to be charitable is a bit crap at describing what is happening.
If some unspecified situation does light up all the LEDs at once, and the design is so poor that the power supply can’t cope, then how is a delay going to do anything to elevate the situation. His explanation makes no sense what so ever.
I am not worthy to criticize one of the principal coders of the fastLED library.
The delay was probably in his programs used during the development of the library, and it never came out when they became example sketches. You probably have such code that was only useful in development but never got removed when you were done. But I have to agree with you that I fail to see what "insurance" the delay provides because any overload conditions he described would only be apparent after the delay.
Since you said "Read that first sentence again. It is pure rubbish.", I figured I would explain every word of it. Even what "Git" means.
No point trying to explain something that is indeed - complete rubbish!
The implication is that when this happens to "Lightbreaker", it was because he had a faulty power supply. The problem was a faulty power supply, nothing whatsoever to do with the code and not something that code could fix. (It's called a "kludge". )
Mike has explained concerns about powering the Arduino and the LED strip from different power supplies and in general it is preferred to power them from the same, adequately capable and properly regulated 5 V supply but this supply must be capable of reliably powering them, including at start-up. The ATmega chip already has a reset delay built-in and the boot code also provides some delay; if the power supply cannot stabilise within this time, it is clearly faulty.
It is thus simply mendacious to suggest that this delay() is in any way helpful.
)