To be honest, I haven’t had a chance to try just yet. I found the above link and thought to give that a try first as it’s a software change and has minimum impact on my set up. Can you elaborate more on what exactly you mean by PIO code and why I shouldn’t need to overclock?
EDIT: Seems like I only need to go up as high as 130000000 to fix the issue.
The Pico by default will be running at 133MHz, which is just above the frequency listed above.
Would it be possible to send through the code that you used? Someone from the forum will be able to pick the part (in software) that might be causing issues)
Hi Liam, here’s the guts of it. Note that it uses ulab (aka numpy) but that’s really just handy to convert my colours to bytes. The main workhorse is the machine.bitstream calls which was taken from the guts of several neopixel libraries.
Apparently picos ship with the internal clock set to 125MHz, even though the chip is rated for 133. I’ve heard several different opinions on setting the clock speed to a value in this range - some say technically it’s not overclocking, some say that it is since the pico is more than just the RP2040, it’s still counted as overclocking.
Thanks Liam, just having a look at these links now. If I understand correctly - you’re suggesting that using the PIO / state machine protocol should eliminate the problems from directly bit-banging the gpio pins?
Glad we got to the bottom of it and thanks for letting us know what solved it!
I’m not certain what the bitstream call is doing behind the scenes but definitely was related to something with timing.
If you’re keen to learn the machine class is open source and on GitHub!
Liam
Not to unearth this thread but there were further issues that came up from using neo pixels with Pio. From memory this link is what saved me should anyone else run into the same issue:
Tl;dr - most neopixel code includes the wrong timings, but the issues won’t show up for most builds. Clearly I crossed some sort of threshold and the timings were an issue for me.