Neopixels do not work correctly

[ste7anste7an]

This is not direclty an issue for the lvgl_micropython implementation, but i would like to address it here. Hopefully, someone comes up with a solution.

Using the lvgl_micropython firmware build (idf 5.4) for ESP32 wth SPIRAM, NeoPixels do not work properly. I see that some pixels are not lighting up, and thers are the wrong color. It seems that the timing (RMT) is slightly off.

Comparing to the official micropython 1.25 build (idf 5.2.2) When I compile the lvgl_micropython.

Would it be possible to use idf 5.2 for building lvgl_micropythin, to see wther that solves the problem?

from machine import Pin
from neopixel import NeoPixel
np=NeoPixel(Pin(19),9)  # 9 pixels
np.fill((100,100,0))
np.write()

I tried to replace /lib/esp-idf with 5.2.2 and recompile. But I notice that there are specific 5.4 objects that are used (I get an error with e.g. self->bus_config.dma_burst_size = 64;) and generate errors.

[ste7anste7an]

I tracked it down to bad behaviour when I enable SPIRAM. So, normal compile without SPIRAM, NeoPixels work fine. Compile with BOARD_VARIANT=SPIRAM I get bad pixels and bad colors for NeoPixels.

[kdschlosser]

I am going to open an issue upstream in MicroPython as this is going to be an issue there.

what is the ESP32 you are compiling for? is it a variant or just the plain ESP32?

[kdschlosser]

OK I have been looking at the driver and it looks to be pretty easy to write up a new driver that would be non blocking when transferring data so it would be faster. You can allocate multiple frame buffers to handle this. The frame buffers would be num_pixels * 3 in size. I would write the driver so you can allocate as many frame buffers as you like and that would be the maximum number of buffers you could queue up to be transmitted. There would be a callback that gets called so you can track which buffers are being transmitted and which ones can be written to. I would not have it erase the pixel data in the buffer after a transmit was successful

[ste7anste7an]

I use the ESP32-PICO-V3-02. This is a variant of an ESP32-wrover, with 2MB of PSRAM. The metal case of this chip is about half the size of a normal ESP32-wrover. I did a quick test on a normal ESP32-WROVER. Same results. neoPixels have all different colors when I set the all to e.g. RED.

I also quicly looked in the machine_bitstream.c driver, but I have to admit, this code is above my expertise level. I had chatgpt suggesting some changes, but chatgpt doesn't understand the code either.

For the time being, compiling it without PSRAM does the job.

In some micropython issues I do see they mention recoding the RMT driver using API from esp-idf 5.4 (micropython/micropython#16293).

The framebuffers you mention in your last message above, would that be something that solves the NeoPixel problem? Because I already experience the problem, even without enabling lvgl.

[kdschlosser]

what are you using for an LED strip? what is the model of the IC's used for the pixels?

[kdschlosser]

The neopixel library is set up for the ws2812 IC's so if you are not using a strip that uses those specific IC's then some additional things need to be done to get it to work properly.

[kdschlosser]

so as an example. if you are using the APA109 IC's you would do the following..

from machine import Pin
from neopixel import NeoPixel


np=NeoPixel(Pin(19), 9, timing=(300, 900, 600, 600))  # 9 pixels
np.fill((100,100,0))
np.write()

if you are using the SK6822 IC's it get a but more complex because you need to change the byte order for the pixel data.

The reason why I do not like the way it is done currently is because it is terribly slow. Not only because of the blocking that takes place when sending the data but also because the code that does the reordering of the byte data is written in Python and that is 200 times slower than C code. By writing a proper C driver it will be a heck of a lot faster. It's not that hard to do either.

[ste7anste7an]

I use the standard WS2812B pixels. When disabling SPIRAM, they work perfectly. When enabling PSRAM, I get all colors of the rainbow. Something in the timing of the RMT (and hence the bitstream) gets disturbed by enabling PSRAM.

I want to try with a vinilla Micropython version 1.25 compiled with esp-idf 5.2 and 5.4, with and without PSRAM enabled. Depending on the outcome, I also can make an issue at the micropthon git. I will also keep you posted here on the outcome.

[kdschlosser]

I am getting close to being finished writing a new driver. I still have to write the python side of the driver but that is not going to be too difficult to do.

[kdschlosser]

OK so the driver isn't defaulted to the timings for the WS2812B IC. That is a different set of timings.

The timings for the ws2812 are

(350, 800, 700, 600)

and the timings for the IC you are using is

(400, 850, 800, 450)

you see how close they are?? which could explain why the PSRAM access slows things down a bit which mucks up how the timings are.

Try setting the timings to the above and see if it works better.

[kdschlosser]

The timings are +- 150ns typically but the RMT driver only has us precision. so that will throw things a bit outta wack as well.

[ste7anste7an]

The resuls remains the same, regardless of the timing I use.

I compiled a vanilla MicroPython using esp-idf 5.2.2 with and without SPIRAM. Same for esp-idf 5.4.1

Both versions (5.2.2 and 5.4.1) without SPIRAM work fine.
Both versions (5.2.2 and 5.4.1) with SIPRAM gave random colors.

Looking at the pattern when things are not OK, I see instead of all red LEDS: off, green, yellow, red, off, green, yellow, red, etc. It looks definitely as a timing issue.

Earlier I compiled MicroPython 1.24.1 using esp-idf 5.2.2 with SPIRAM enabled, and there the neopixels work fine.

[kdschlosser]

Did you open an issue in the MicroPython Repo for the problem?

You might also have to open an issue on Espressif's repo for the ESP-IDF as well. There is without a doubt something that is amiss with it. I have to double check to see if MicroPython is using a deprecated API. It could be.

[kdschlosser]

yes it is using a deprecated API. Let me update the driver to use the new API and see what happens....

[kdschlosser]

You can give it a try now. I updated the driver in MicroPython so it should hopefully work now. I did not try to compile it so the build may fail. If it does paste the exact error(s) so I can fix them.