Let me start by saying I have no connection with Pimoroni apart from being a very happy customer of theirs for many years.
Some background:
I have a number of Pimoroni Pico Display 2.8" boards. (see https://shop.pimoroni.com/products/pico ... y-pack-2-8 for details).
They have a mounting socket for the Pico (assuming you have header pins installed, as in the H variants), and have an ST7789 display, four push-buttons, and an RGB LED on board.
Pimoroni provide excellent support for their products, including a github repository which provides MicroPython and C/C++ SDK software.
In the course of developing my UI for controlling some smart home devices which Amazon Alexa no longer supports, I have run into an oddity.
As part of the hardware initialisation, I want to turn off the RGB LED, as it doesn't add anything for this particular project, but I don't want to go the whole hog and cut the tracks to disable it permanently.
Within my routine, I have a temporary RGBLED object which I initialise, then set it to black (R=0,G=0,B=0) and set the brightness to 0 also.
This, as expected, turns off the LED. No surprises there. The object, which was on the stack, is destructed when the routine returns, again, as expected.
Here's where I go "Huh?", because on the Pico2W (I'm guessing also the Pico2, but I haven't tried it), the LED stays out. However, on the PicoW, it doesn't, and lights up again with some seemingly random colour, which, as I am chromatically challenged, I am unable to determine.
Oh.
Now, I know why this is happening, probably. The constructor configures the pins the LED is connected to (#26,#27,#28) by setting the function of the pins to GPIO_FUNC_PWM. It does some other magic as well, like actually configuring the PWM for each pin.
The destructor for the object then sets the function of the pins to GPIO_FUNC_NULL.
However, this begs the question as to why does the LED light up again on a Pico, but not on a Pico2?
Obviously, I have "worked around" this by NOT destroying the RGBLED object but I am still curious as to why they behave differently.
Some background:
I have a number of Pimoroni Pico Display 2.8" boards. (see https://shop.pimoroni.com/products/pico ... y-pack-2-8 for details).
They have a mounting socket for the Pico (assuming you have header pins installed, as in the H variants), and have an ST7789 display, four push-buttons, and an RGB LED on board.
Pimoroni provide excellent support for their products, including a github repository which provides MicroPython and C/C++ SDK software.
In the course of developing my UI for controlling some smart home devices which Amazon Alexa no longer supports, I have run into an oddity.
As part of the hardware initialisation, I want to turn off the RGB LED, as it doesn't add anything for this particular project, but I don't want to go the whole hog and cut the tracks to disable it permanently.
Within my routine, I have a temporary RGBLED object which I initialise, then set it to black (R=0,G=0,B=0) and set the brightness to 0 also.
This, as expected, turns off the LED. No surprises there. The object, which was on the stack, is destructed when the routine returns, again, as expected.
Here's where I go "Huh?", because on the Pico2W (I'm guessing also the Pico2, but I haven't tried it), the LED stays out. However, on the PicoW, it doesn't, and lights up again with some seemingly random colour, which, as I am chromatically challenged, I am unable to determine.
Oh.
Now, I know why this is happening, probably. The constructor configures the pins the LED is connected to (#26,#27,#28) by setting the function of the pins to GPIO_FUNC_PWM. It does some other magic as well, like actually configuring the PWM for each pin.
The destructor for the object then sets the function of the pins to GPIO_FUNC_NULL.
However, this begs the question as to why does the LED light up again on a Pico, but not on a Pico2?
Obviously, I have "worked around" this by NOT destroying the RGBLED object but I am still curious as to why they behave differently.
Statistics: Posted by SteveSpencer — Fri Jan 23, 2026 9:29 am — Replies 5 — Views 90