Ceci est une ancienne révision du document !
In my Python article for this month, I said “Being from Texas, most of us here have a tendency to “change horses in midstream” as the saying goes, and this month, I’m afraid I’m going to have to do just that.”. That applies even to the ‘Micro This Micro That’ article for this month. I try very hard to be consistent, but when issues come up with readers and/or users, I try to share information that might help other readers, especially when the topic is relevant to the subject of the articles. Last month, I said that I would expand on the compass project. My friend in Norway, Halvard, contacted me yesterday with an issue that dealt with his NeoPixel ring that I tried to help him with, and I thought I’d share that with you. He had found a new driver library for the Raspberry Pi Pico that was supposed to handle the NeoPixel devices a bit better than the “standard” statemachine version that we have used in the past. However, he was having a problem on his system, where, when he ran the example program, he set the number of LEDs to 24, but only 18 ever lit. That seemed very strange to me, so I started looking into his issue.
He pointed me to the repository for the driver which is https://github.com/shreyask21/neopixel_rp2040 . As I usually do, I downloaded the repository as a zip file rather than clone the folder. Once I got it downloaded, I unpacked it and copied the relevant files to a working folder. I already had the RPi Pico set up with the NeoPixel ring and the battery pack from trying to work on the next installment of the article from last month, so I thought I was good. Using Thonny, I copied the driver library and the example to the Pico and jumped in. The first thing I did was to change the Driver ‘In pin’ in the instantiation function call. led = neopixel_rp2040.neopixel(LEDS=2, PIN=16) To remind you, the PIN assignment is the GP16 pin which is the physical pin 21 of the Pico. In the example file the author uses led = neopixel_rp2040.neopixel(LEDS=2, PIN=22)
I purposely kept the number of LEDs set to 2, just to verify that the program worked. Halvard’s issue was that if he set the number of LEDs to 24, only the first 18 worked. To get the entire 24 to light, he had to set the LEDs to 32. Anyway, back to my story. When I tried to run the example, nothing happened. I was very confused. It turned out that my battery pack (which uses rechargeable batteries) had run low on power. After a brief 2 hours of replacing electrons into the batteries, I tried again. The example program worked with just the two LEDs without an issue (except for the brightness) and I then moved on to a test using just 12 LEDs. Again it worked. I then took a deep breath and tried all 24. Again, it worked. When I say that the brightness was an issue, I’m just saying that the darn things are TOO BRIGHT for my old eyes. It thought I was looking directly into a bright halogen bulb! So, I let Halvard know my progress and suggested that he check his battery pack.
It turns out that Halvard had purchased a newer version of the PixelRing that is RGBW, not just RGB. While you would think (on one side of your brain), that the RGB drivers would work with RGBW NeoPixel sets. They do, but not quite properly. When trying to figure out why things were not quite right, I stumbled across this web site https://forums.electricimp.com/t/neopixel-strips-rgb-vs-rgbw/4212/8. It contains a long discussion that eventually explains everything. Peter, one of the posters, explained it in a very short but important comment. “The RGBW ‘Neopixels’ are a different controller, SK6812, but it looks like the actual protocol is very similar (except for having 32 bits per LED instead of 24). It sounds like it’d be worth starting from the WS2812 library and making some modifications.” So that explains why things went wonky when Halvard tried to use the driver for WS2812 NeoPixels when he actually had SK6812 NeoPixels. Thank you Peter for the explanation.
So off I went again on a search for a driver that would, at least, support the SK6812 and hopefully for the WS2812 as well. I found it at https://github.com/blaz-r/pi_pico_neopixel. On his repository he states: “You create an object with the parameters number of LEDs, state machine ID, GPIO number and mode (RGB or RGBW) in that order. So, to create a strip of 10 leds on state machine 0 and GPIO 0 in RGBW mode you use: from neopixel import Neopixel pixels = Neopixel(10, 0, 0, “RGBW”) Mind that you can use whichever order of RGB / RGBW you want (GRB, WRGB, GRB, RGWB …). This only represents the order of data sent to led-strip, all functions still work with RGBW order. Exact order of leds should be on the package of your led-strip. (My BTF-lights sk6812 has GRBW).”
So if you are using a RGBW strip or ring, you can simply use the initialization as shown above in the quote. pixels = Neopixel(10, 0, 0, “RGBW”) If, however, you are using an older RBG strip or ring, you can simply replace the mode designation “RGBW” with “RGB”. pixels = Neopixel(10, 0, 0, “RGB”) The parameters are easy. pixels = Neopixel(NumberOfPixels, StateMachine, Pin, Mode) As always, Pin refers to the IO pin, not the physical pin. The distribution comes with four example programs that show off the abilities of the driver and I have to admit, they work well, both for me and for Halvard – who tested them as well and they ran fine for him when he modified the initialization call.
My favorite example is the firefly example program. It reminds me of summer evenings back when I was a child, chasing the fireflies in the back yard with a mason jar my mother let me use. Even today, when I see fireflies (which are actually in the beetle family and not flies at all), I am thrown back to those memories. So, with the pause for this month’s update, we'll press play on the compass program next month using the new driver for the NeoPixel display. Until next time, as always; stay safe, healthy, positive and creative!