rp2: Neopixel library and docs

RP2040 based microcontroller boards running MicroPython.
Target audience: MicroPython users with an RP2040 boards.
This does not include conventional Linux-based Raspberry Pi boards.
Post Reply
User avatar
marfis
Posts: 215
Joined: Fri Oct 31, 2014 10:29 am
Location: Zurich / Switzerland

rp2: Neopixel library and docs

Post by marfis » Mon Sep 13, 2021 2:33 pm

The online doc for the rp2 has a quickref for neopixel:
pointing https://docs.micropython.org/en/latest/ ... 106-driver

I understand there is a major refactoring going on for this documenation, but I don't see how/if there is a module level support for neopixel at the moment. The code above does not work and the neopixel module doesn't seem to be frozen (has never been - i tested every release until 1.14)

So if there was a module for neopixel, where would I find it? The official driver https://github.com/micropython/micropyt ... eopixel.py
now requires an implementation for machine.bitstream - not really ideal since I'd love to use the PIO...

I'm aware of the PIO's code snippets (they work!), but would prefer to use the neopixels in the same API as the standard neopixel module that are available for other MCU's.

So my current assumption is to use the driver code mentioned above, copy / paste it and modify the write() so that it will work with the pico's PIO...

As you might have guessed, I'm basically a bit lost at the current state of "official micropython + rp2 + neopixel".

User avatar
mattyt
Posts: 410
Joined: Mon Jan 23, 2017 6:39 am

Re: rp2: Neopixel library and docs

Post by mattyt » Fri Sep 17, 2021 6:19 am

You're right that thie NeoPixel implementation has been undergoing some significant rework.

Most of it is captured in #7637 but, in short, NeoPixel is now generic across all ports but built expecting to have access to (the new) machine.bitstream. Bitstream is responsible for sending the timing-specific pulse stream required to drive devices like WS2812Bs. Bitstream is usually going to be port- (possibly micro-) specific and may use modules like RMT (ESP32) or PIO (rp2) to achieve accurate pulses.

When 7637 was merged there was actually no implementation for bitstream for the rp2 (or nrf or samd...); that was expected to come later.

Just yesterday, #7805 was raised to implement bitstream for rp2. It's actually implemented based on systick, not PIO at this stage. If you could try it out that would be really helpful!

Hope that helps clarify the situation.

User avatar
marfis
Posts: 215
Joined: Fri Oct 31, 2014 10:29 am
Location: Zurich / Switzerland

Re: rp2: Neopixel library and docs

Post by marfis » Sun Sep 19, 2021 7:45 pm

Thanks a lot for the detailed answer, that clarifies the situation. In that case... would a note make sense in the quickref, stating that the neopixel module is currently not available? To reflect the current state?

It's great that machine.bitstream is in active development for the rp2. Using systick is ok for me, I guess it's the straightforward way and in blocking mode it likely doesn't make much difference (in fact it frees one PIO for other purposes..)

My view is that the PIO really shines in non-blocking mode. I'm using it that way on my board and it works flawlessly. It really gives you time to process the next iteration of the neopixel strip while the DMA + PIO pushes the data to the neopixel in the background. Hopefully we see a non-blocking API soon.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: rp2: Neopixel library and docs

Post by Roberthh » Tue Sep 21, 2021 2:44 pm

The rp2 PR for bitstream was made by me. I considered using PIO, because it is fast and precise. But that would not be possible in an effective manner. The bitstream model for the high/low bitstream type requires the actual pin driver to handle four timing parameters, which define the pulse times.Due to the limited set of registers, PIO cannot handle them. Injecting them into the running code is possible, but would due to the demand for bit timing require most likely a blocking mode as well. Merging them with the data stream would also require fast timing or a large intermediate data buffer.

Post Reply