PWM is disturbed when neopixel update a led strip / esp8266

[paradoxisme]

Hello,

I try to control a led strip (ws2811 with neopixel) with an nodemcu v3 and a pwm for controlling a buzzer (for creating a music with rtttl lib).
The both work fine separately. But together, I hear a break on pwm, like if the pwm is interrupted each time led strip is updated.
The firmware is '3.4.0; MicroPython v1.19.1 on 2022-06-18'

So I've tried to test this (without anything connected) :

>>> pwm3 = machine.PWM(machine.Pin(4))
>>> pwm3.freq(1000)
>>> pwm3.duty(512)

On pin D2, I can measure this signal, it is stable :

After that, I've created a neopixel object that use D0, and wrtite infinitely :
np = NeoPixel(machine.Pin(16), 60)

>>> while True:
...     np.write()
... 

I can see that pwm on D2 is very disturbed :

So, my questions are :
Does it a known issue, a known limitation or a bug ?
Do you think there is a solution for having a good pwm when neopixel write to the led strip ?

Thank you

Damien

[davefes]

Does a machine.Pin object default to Pin.OUT when used with NeoPixel?

[paradoxisme]

The mode of the machine.pin object is not defined

[jimmo]

Does it a known issue, a known limitation or a bug ?

This is a bug but not sure if it's one we can fix easily and whether it's in the IDF or in MicroPython. It's complicated, but worth investigating.

The simple answer is that MicroPython just forwards both of these functions to the ESP IDF:

• The neopixel write goes to the RMT driver. (Unless you disable this where it uses a software driver, but the default is to use RMT)
• The PWM goes to the PWM driver.

You would expect that both of these should be able to run concurrently (at the end of the day, that's the point of having hardware support). In particular the PWM should be just set-and-forget (even if the RMT driver has to run interrupts to keep the output buffer full).

Would need to investigate further and find out why the PWM peripheral isn't just running independently... surely it doesn't require an IRQ to keep running. It would be interesting to find out of the glitches are happening during RMT initialisation, or during the transmit of the data.

[dpgeorge]

If this is an esp8266 (as opposed to esp32) then it's a know limitation: the PWM is software based and so is the neopixel driver. They both require full control of the MCU without anything interrupting them (eg the PWM will miss transitions if the neopixel is outputting for too long).

So they don't work well together, unfortunately.

[jimmo]

Ah i completely missed that this was ESP8266 not ESP32. Yes, can't be fixed unfortunately.

[paradoxisme]

Yes, it is an esp8266. Ok I understand the behaviour. May be I will try with an esp32, or accept the limitation and update the led strip only when I have no sound (eg between 2 musical note).