NeoPixel support does not work on pin 33 (and presumably Pin 32).

[toybuilder]

On a new board that I recently developed, I discovered to my horror that NeoPixel output does not work on GPIO33 (aka Pin 33). This appears to be a limitation in how NeoPixel output is mapped to the output pin in a normal ESP32 setup.

[robert-hh]

That's indeed right. It works for pin# < 32 only. Fixing that in neopixel.c should not be too complicated, by either checking for pin >=32 and choosing the proper register/mask pair, or by using the gpio_set_level() call, like machine_pin.c does.

[toybuilder]

It looks like espneopixel.c would also then have to change to write to the second-group GPIO output registers (GPIO_OUT1_W1TS_REG and GPIO_OUT1_W1TC_REG).

[robert-hh]

That's what I said with proper register/mask pair. gpio_set_level() does that obviously, but it is somewhat slower by including a check for a valid pin number. Still, using gpio_set_level() is the better style.

[toybuilder]

I was hoping there might have been a way to steer the logic through the MUX, but it looks like I don't have a nice way to easily loopback the signal without wire changes. I guess this forces my hand to make my own micropython build for the time being!

[robert-hh]

Making your own build is not that complicated. And it opens the chance for including your favorite scripts as frozen bytecode.
Since your actual neopixel problem is an omission, you can make a PR for that. It is a small change, so it has a good chance to get merged. There are other PRs for a more generic neopixel solution of all ports, but these are still open.

[toybuilder]

I'm running on Windows-sans-WSL and my initial attempt to build is failing. (I was first stuck with mpy-cross, but saw someone's suggestion to pip3 install mpy-cross...)

I was going to take a fairly simple approach - duplicating esp_neopixel_write to make esp_neopixel_write1, and updating the outputs to the GPIO_OUT1_xxx registers. Then at the top of esp_neopixel_write, if pin >31, invoke esp_neopixel_write1. It violates "DRY" principle, but it actually seems like the least disruptive way to do it?

[robert-hh]

for mpy-cross just go into the mpy-cross directory and build it. I do not know if pip3 installs the right version of it.
For the code change, sticking with direct register write, I would more use the way below (compiled, but not tested):

// Original version from https://github.com/adafruit/Adafruit_NeoPixel
// Modifications by dpgeorge to support auto-CPU-frequency detection

// This is a mash-up of the Due show() code + insights from Michael Miller's
// ESP8266 work for the NeoPixelBus library: github.com/Makuna/NeoPixelBus
// Needs to be a separate .c file to enforce ICACHE_RAM_ATTR execution.

#include "py/mpconfig.h"
#include "py/mphal.h"
#include "modesp.h"

void IRAM_ATTR esp_neopixel_write(uint8_t pin, uint8_t *pixels, uint32_t numBytes, uint8_t timing) {
    uint8_t *p, *end, pix, mask;
    uint32_t t, time0, time1, period, c, startTime, pinMask, gpio_reg_set, gpio_reg_clear;

    if (pin < 32) {
        pinMask = 1 << pin;
        gpio_reg_set = GPIO_OUT_W1TS_REG;
        gpio_reg_clear = GPIO_OUT_W1TC_REG;
    } else {
        pinMask = 1 << (pin - 32);
        gpio_reg_set = GPIO_OUT1_W1TS_REG;
        gpio_reg_clear = GPIO_OUT1_W1TC_REG;
    }
    p = pixels;
    end = p + numBytes;
    pix = *p++;
    mask = 0x80;
    startTime = 0;

    uint32_t fcpu = ets_get_cpu_frequency();

    if (timing == 1) {
        // 800 KHz
        time0 = (fcpu * 350) / 1000; // 0.35us
        time1 = (fcpu * 800) / 1000; // 0.8us
        period = (fcpu * 1250) / 1000; // 1.25us per bit
    } else {
        // 400 KHz
        time0 = (fcpu * 500) / 1000; // 0.5us
        time1 = (fcpu * 1200) / 1000; // 1.2us
        period = (fcpu * 2500) / 1000; // 2.5us per bit
    }

    uint32_t irq_state = mp_hal_quiet_timing_enter();
    for (t = time0;; t = time0) {
        if (pix & mask) {
            t = time1;                                              // Bit high duration
        }
        while (((c = mp_hal_ticks_cpu()) - startTime) < period) {
            ;                                                       // Wait for bit start
        }
        GPIO_REG_WRITE(gpio_reg_set, pinMask);                      // Set high
        startTime = c;                                              // Save start time
        while (((c = mp_hal_ticks_cpu()) - startTime) < t) {
            ;                                                       // Wait high duration
        }
        GPIO_REG_WRITE(gpio_reg_clear, pinMask);                    // Set low
        if (!(mask >>= 1)) {                                        // Next bit/byte
            if (p >= end) {
                break;
            }
            pix = *p++;
            mask = 0x80;
        }
    }
    while ((mp_hal_ticks_cpu() - startTime) < period) {
        ;                                              // Wait for last bit
    }
    mp_hal_quiet_timing_exit(irq_state);
}

[robert-hh]

Code tested at Pin 32 and it works. Works still at pins < 32.

[toybuilder]

Uh, this might be a dumb question, but since you already made the changes and have it working, were you planning to check in and PR the modification? Since you posted your code, I could make the same change, but I'd then be taking credit for your work?

[robert-hh]

Just take the code as it is for now. PR's may take some time. I can make one, but will definitely check first whether gpio_set_level() is also compatible with the neopixel timing.

[toybuilder]

Ok. I am fixing up an older Virtual Box image to do my local build (and having to grab and build CMake 3.1 because #7118). It is, as you pointed out, easy (once the tool dependencies are out of the way).

Thanks for your engagement on this.

[toybuilder]

BTW, I will defer to your familiarity with Micropython to make the appropriate checks and create the PR. Thank you.

[robert-hh]

I made the test with gpio_set_level(), and that fails. The basic timing is fine, but there is a single 4.4 µs pulse as the first one which makes the whole timing fail.

[toybuilder]

The first solution is working great for me, so I'm happy with it. I did have a steep learning curve, not realizing that I wanted firmware.bin, not micropython.bin, to be written to the target when erasing the device. Now that I figured that out, I think I am in a good place!

[robert-hh]

Great. Even after years of building images, I stumble over such little things. But uploading the firmware can be done with:
make deploy
If you have the USB of the ESP32 port linked into the virtual machine. But that's another story.