Suggested method for avoiding pixels-on-full during program upload

[sandandstars]

Large numbers of pixels, when on full brightness, need inconveniently large power supplies - up to 7Amps/metre. An easy way to reduce the power requirement is to light up just a few pixels at a time, or many at a lower brightness. However, with common controllers, such as the ESP8266, uploading a new program causes every pixel to light up on full due to the way the neopixel output pin is used during programming. This can overload a smaller power supply, blow fuses, damage wiring, etc.

There's a great way to resolve this. Firstly, neopixels are usually powered at 5V, but many microcontrollers run at 3V3, and neopixels don't work reliably if driven at a much lower voltage than they are powered. A common way around this is to use the ICs 74HCT125 or 74HCT245 to convert the microcontroller output from 3V3 to 5V.
These ICs have an ENABLE input for each converter, and this can be used to solve the upload problem.

Simply connect the ICs Enable inputs to a pin on the microcontroller that is HIGH AT BOOT (e.g. D0 on the ESP8266). This will disconnect the neopixels until your program runs, preventing the upload from affecting the pixels. Then, in the program, set the pin to LOW in order to allow data to reach the pixels.

[Makuna]

Linked this FAQ entry to this discussion.

[ErikBasalt]

@sandandstars Thank you for this good suggestion!

Long story:
Initially, I used a 74HCT126 level shifter, that has positive logic to enable the output. I couldn't get it to work, and replaced it with the 74HCT125, connected to D0 (GPIO16) just as described above by @sandandstars, but that didn't solve it.
So I added a 10K pullup resistor at D0 to ensure high level directly from start, and a 10K pulldown at the output of the 74HCT125 because when the output is not enabled it is at high impedance. Still the Neopixels were not responding when the WeMos was powered from USB, while it did work when powered from a separate 5V power supply.

TL;DR
I finally found this topic: https://forum.arduino.cc/index.php?topic=599023.0 where 'arnemauer' reported an issue with his Wemos D1 Mini Pro (same board as I am using): the crap manufacturer decided to replace the 470 ohm resistors in the RX and TX lines from the ESP8266 towards the CP2104 by 2 ohm resistors. I changed (with surgical precision) the one in the RX line for a 1K resistor (I couldn't find a 470 ohm), and now it's working perfectly!

I will keep the 10K resistors mentioned above, not knowing if they are really needed.
And probably it could work with 74HCT126 and positive logic at another GPIO port, but I will leave it like this now.

@sandandstars and 'arnemauer' from forum.arduino.cc:
Thank you so much for your hints!

BTW:
Same Wemos board also has only 4MB flash instead of 16 MB that the "Pro" version normally has.
Despite of all this, I still love this small Wemos board :-)

[sandandstars]

Thanks for your interesting comment @ErikBasalt.
I see that the difference between the 74HCT125 and 74HCT126 (which I didn't know existed!) is that the 74HCT125 disables the outputs when the ENABLE pin is HIGH, and the 74HCT126 disables the outputs when the ENABLE pin is LOW.
The WEMOS D1 Minis I use have several pins that are HIGH on boot (and also during program upload), which works great for the 74HCT125, but the 74HCT126 would, as you suggest, need to be connected to a pin that was LOW on boot and during upload, which the program could then set HIGH - it would need some experimentation.
With RX connected to an input of the 74HCT125, I'm curious that there needs to be a resistor at all, but then again, anything is possible!
The 10k pullup should not really be necessary, although I have noticed the occasional very brief flash from the odd noepixel, so there may be some use in having it.
The 10k pulldown is more definitely not necessary. The problem is that the noepixels receive 'junk' data which gets interpreted as commands; it shouldn't matter what state the output is in as long as it's not changing, and I don't think they have a problem with a floating input. But I wait to be corrected...
I use the minis to control a string of neopixels based on a predefined sequence that is sent from a JAVA program via WiFi; even half of the 4MB flash can hold thousands of changes; for the price, I agree that the Wemos D1 minis are excellent.

[ErikBasalt]

Hi @sandandstars, thanks you for your elaborate feedback.

The difference between 74HCT125 and 74HCT126 is indeed as you described. Of course I inverted the logic in my code when changing to the other type.

The 470 ohm resistors are in the schematic schematic of the Wemos D1 Mini Pro.

As you can see, the RX input of the ESP8266 is connected via a 470 ohm resistor to the TX output CP2104, which translates USB to/from UART. This RX/TX crossing is normal BTW.

With NeoPixelBus in DMA mode, something special happens: the RX input of the ESP8266 becomes an output for Neopixel data. This output is connected to the data input Neopixel strip, via the 74HCT125 in our case.

But the TX output of the CP2104 is also still connected to the "RX input" = "Neopixel output" of the ESP8266, so 2 outputs are connected to each other. The 470 ohm resistor in between ensures that the Neopixel output signal from the ESP8266 "wins" from the CP2104. But that resistor needs to be sufficiently large for that.

For sure, 2 ohms is far to little and causes the issue that I had: the Neopixels were working when the Wemos was powered from 5V supply (because then the CP2104 is not active), but NOT working when powered from the USB bus (because then the active output of the CP2104 interferes with the RX input" = "Neopixel output" of the ESP8266.

So, very logical in the end, but I'm really disappointed in the manufacturer who made this change to 2 ohms. Because they were cheaper? Or the 470 ohm was out of stock? Anyway, I'm happy I found it, and was able to fix it.

-/-/-

About the 10K resistors: as said, I myself will leave them in now. Just wanted to mention them, in case someone has a weird problem
she/he can try this as well. At least it doesn't hurt adding them. And I don't see any occasional random flashes at startup, so maybe it helps a little indeed :-)