Neopixels ESP32

[Geek]

This script, with 30 neopixels, in ESP8266 works, and with micro:bit also works perfectly. But in ESP32 it cause fluctuations. The neopixels are with power suppy and 1000 uF capacitor.

I have noticed that I place a Say block before the set all neopixels color block things improve. Timing problem?

ESP32 problem?

‌

[Geek]

https://microblocks.fun/run/microblocks.html#scripts=GP%20Scripts%0Adepends%20%27NeoPixel%27%0A%0Ascript%20456%20112%20%7B%0Acomment%20%27Fluctuations%27%0AneoPixelAttach%2030%205%0Alocal%20%27var%27%200%0Afor%20i%20255%20%7B%0A%20%20neoPixelSetAllToColor%20%28colorFromRGB%20i%20i%20i%29%0A%20%20waitMillis%2050%0A%7D%0Afor%20i%20255%20%7B%0A%20%20var%20%3D%20%28255%20-%20i%29%0A%20%20neoPixelSetAllToColor%20%28colorFromRGB%20var%20var%20var%29%0A%20%20waitMillis%2050%0A%7D%0A%7D%0A%0Ascript%20903%2099%20%7B%0Acomment%20%27With%20Say%20block%20-%20Better%27%0AneoPixelAttach%2030%205%0Alocal%20%27var%27%200%0Afor%20i%20255%20%7B%0A%20%20sayIt%20i%0A%20%20neoPixelSetAllToColor%20%28colorFromRGB%20i%20i%20i%29%0A%20%20waitMillis%2050%0A%7D%0Afor%20i%20255%20%7B%0A%20%20var%20%3D%20%28255%20-%20i%29%0A%20%20sayIt%20var%0A%20%20neoPixelSetAllToColor%20%28colorFromRGB%20var%20var%20var%29%0A%20%20waitMillis%2050%0A%7D%0A%7D%0A%0A

[John Maloney]

Thanks for the test scripts! Very helpful…

What version of the MicroBlocks firmware are you using? I recently fixed a possible problem with the ESP32 Neopixel code in firmware v135. Using that firmware, both versions of your test (with and w/o the “say” block) run without glitches on a 8-Neopixel ring on my NodeMCU ESP32-S board.

If you are still seeing glitches with v135 of the firmware, you might try setting the number of Neopixels to a smaller number (e.g. 8) to see if the number of Neopixels makes any difference.

Incidentally, the timing problem is quite subtle. Even though the Neopixel output code runs with interrupts turned off, timing glitches can be introduced by the ESP’s “execute in place” (XiP) system, which fetches instructions from the external Flash memory into an internal RAM cache as needed. That process takes enough time to mess up the timing of the Neopixel signal. The glitch usually effects only the first Neopixel in the string because after that that the code is in the instruction cache.

Other things, such as bus contention from the second CPU, might also cause problems in theory, although I haven’t seen an evidence of that so far. If such glitches do occur, I’d expect them to be more likely when the radio system is in use for WiFi, Bluetooth, or ESP Now. Are you using the radio system while doing the Neopixel tests?

[Geek]

The ability to send scripts as URLs is very useful 😃

I have done the tests with firmware v135 and earlier.

The glitches occur with 10 neopixels or more.

Failures occur even without the radio. The scripts that posted produces the glitches without adding anything else.

[John Maloney]

Thanks for the testing.

Do the glitches always occur in the same Neopixels (e.g. the 11th one)?

Do the glitches occur only at higher brightness levels? If so, that might suggest that the power supply is having trouble providing enough current. How you powering the Neopixels?

Yet another potential problem is a bad electrical connection somewhere in the chain.

I usually only test with a 10 Neopixel strip, but I can daisy-chain several strips to try to reproduce this.

In the past, I tested with >30 Neopixels on an ESP32 and discovered that the ESP32 RTOS scheduler causes a timing glitch after ~32 NeoPixels (in spite of interrupts supposedly being disabled). It’s possible that a recent change to the ESP32 RTOS decreased the time between scheduling epochs so that glitch now happens after just 10 Neopixels. I haven’t found any source code for the ESP32 RTOS; I’m guessing it is not open source. Since the RTOS is a black box, it is hard to know exactly how the scheduler works or how to control it. The Neopixel data stream is about 800k bits/sec. The pulse widths for individual bits are 300-900 nanoseconds so it only takes a handful of instructions (e.g. handling an interrupt or even an instruction cache miss) to create a glitch.

[John Maloney]

I just tested with 30 Neopixels connected to my NodeMCU ESP32-S board. I used three Elecfreaks strips (https://www.elecfreaks.com/neopixel-rainbow-led-strip-and-gvs-conector-10-leds.html) daisy-chained and powered directly from the 3.3v and GND pins of the board and no extra capacitor. The board itself was powered by the USB cable.

I used you test program. I did not see any glitches. All 30 Neopixels changed color (gray level) at the same time.

SInce your failure is after the first 10 Neopixels, if you are also using 10-Neopixel strips it could be a bad electrical connection between the strips or, potentially, a defect in one of the strips.

[Geek]

I use a single strip of 30 neopixels.
In principle (only in principle) I rule out the power supply problem because with a NodeMCU (ESP8266) it works fine. I also discard it because with the second script it works.
I rule out the failure of the neopixel strip for the same reasons.

I use an ESP32 Wroom. Could the difference be there? (I don't know the difference with the ESP32-S that you use)

I will keep testing

[John Maloney]

I use a single strip of 30 neopixels.

Okay, so it is definitely not an issue of connections between 10-neopixel strips. :-)

In principle (only in principle) I rule out the power supply problem because with a NodeMCU (ESP8266) it works fine. I also discard it because with the second script it works.
I rule out the failure of the neopixel strip for the same reasons.

Good points. The fact that your second script works with the exact same hardware is telling. That rules out electrical and power supply issues. It certainly seems to be a software issue.

It is puzzling that I can’t recreate the problem. My NodeMCU ESP32-S is based on a Wroom module. It could be a matter of different tolerances between my Neopixel strips and the strip you are using. It may help to add a bit more time between the RGB values. (See https://wp.josh.com/2014/05/16/why-you-should-give-your-neopixel-bits-room-to-breathe/)

I’ll use an oscilloscope to check the timings and make some changes.

Have you ever used esptool.py to install firmware? If so, I could send you some versions of the ESP32 MicroBlocks firmware to try. Otherwise I’ll make my best guess and include it in the next pilot release.

‌

[John Maloney]

Just pushed a new Pilot release. Firmware 136 in that release has modified Neopixel timing for the ESP32. Let me know if that addresses your problem.

[Geek]

I have downloaded the 1.1.34 pilot and I have the same problem. But it shows firmware v135

[John Maloney]

You can install the v136 firmware by selecting “update firmware on board” from the gear menu. You may need to hold down the “boot” button on your board to allow the update to occur. When it has been updated successfully, the “about” box should show “Firmware v136”.

[Geek]

That was doing and kept showing v135.
I have deleted the flash with Espressif's "flash download tool" and it already shows v136 after updating.

It works!!!! wow!!
Neopixels no longer glitch.
I'm going to keep testing, but at the moment it works perfectly.

Thank you very much!

[John Maloney]

Excellent! The pulses in v135 were on the shorter end of the tolerance range. Apparently the Neopixels in my strips could handle that timing but not the ones you have. I believe there was a change in the specs a few years ago so newer Neopixels may behave differently from older ones. Or the the chips might just vary between manufacturers or even within a single batch from the same manufacturer.

I’m going to mark this issue “Resolved” but you can still add comments to it your testing uncovers any problems.