(Part 1, Part 2, Part 3, Part 4) This is likely the penultimate of these “Halloween Sprint” posts…if I do one more, it’s most likely just the finished costume, and then writing the “proper” Learn guide later. As mentioned in Part 4, I could have scrambled to finish for the weekend prior to Halloween, but took things easy. By luck this turned out for the better, because weird things popped up…

The wiring’s finished…just propped up with safety pins for now, I’ll sew in a pocket for it later. It’s a bit of a rat’s nest, partly because of an issue mentioned last time where I didn’t have a good body double to measure from, which had me wiring from the strips to the microcontroller board rather than the other way around…all the cable slack piles up in one place and looks bad (though it’ll be hidden under the cloak). Doesn’t affect functionality, it’s just ugly. That’s why I’m doing this shakedown build, so the tutorial version can be neater.

The weird part was finding a NeoPXL8 library bug that only came up because of this particular hardware/softwware combo…

I’d been wanting to test out a different WS2812-compatible LED strip type from a third party. Bought these a while back. It has “Eco” in the name, and I’d jumped to conclusions at the time that this must be a low-power thing. Nope! It’s short for “economical.” They’re addressable LEDs made of lower-cost materials…and with a lower lifespan to match…but for a Halloween costume seemed worth testing.

Every WS2812-compatible variant has slight signal timing differences, and I noticed these “Eco” strips would occasionally flicker with the Feather M0 I was originally testing with. On M0, M4 and ESP32, the NeoPXL8 code takes some liberties with WS2812 protocol timing to save on RAM. That’s worked fine with the NeoPixel strips we have in the shop, but was right on the edge for these weird eco strips. So I switched out for a Feather RP2040, as that version of the code is better able to approximate “traditional” WS2812 timing. Built everything around that…and wanting to keep things compact, didn’t even use sockets, just soldered headers directly from Feather to Wing, no going back…and then found that nothing would light at all!

The NeoPXL8 examples all worked fine on the exact same hardware, it was only the Ooze Master 3000 code that wouldn’t light. I’ll spare you the lengthy bug hunt story and just explain that NeoPXL8 on RP2040 doesn’t like dynamically declaring a NeoPL8 object like so:

NeoPXL8 *leds = new Adafruit_NeoPXL8(args);
leds->begin();

It’s fine on the Feather M0, issue only manifests on RP2040. This never came up before because all the NeoPXL8 examples use static declarations:

NeoPXL8 leds(args);
leds.begin();

The ooze code uses dynamic declaration because all the LED strips might be different lengths, and it makes a pass through a table to determine the longest one before allocating.

So the quick-and-dirty fix was to patch my own version of the code to use a static declaration, already knowing the fixed length of my longest strip. Solves the immediate problem, but a Good and Proper Fix will require finding the issue in the library. Also means that if anyone’s been following along to build something similar, and opted for the same Feather RP2040 instead of M0, you’d be at the same impasse. So it’s a good thing perhaps that the tutorial doesn’t need to be done this week.

Also added a NeoPixel flame effect to the eyes, and dressed up the scythe with some fairy lights. No good reason other than I just wanted more lights on things! More lights = more interest, and I hope someone will see all that on Halloween and be extra inspired to learn about electronics.