Prior configuration:
-Prior to getting a RP 5, I had connected my Raspberry Pi Pico WH board via USB to an iMac (circa 2012) desktop with a legacy OS (High Sierra) that I can’t upgrade anymore. Was able to get started with inventr.io (now Crafting Table) on a couple projects. Now that I have an RP 5 with an external RP Monitor, Keyboard, Mouse, I went to get back into these projects, but transition away from the iMac, and have the Pico connect directly to the new RP 5. Therefore, I can use apps like Thonny on RP5 to program stuff.
Troubleshooting the connection:
-Flashing Firmware: I remember having to do this for the Pico when connected to iMac. Not sure if I need to do again. Within Thonny on RP5, the Pico is mounted on the same breadboard and MicroUSB cable now connected to the RP5. In bottom right, I see: Local Python 3 and MicroPython (Raspberry Pi Pico). The Python 3 is the local RP 5, therefore I’m the Pico is talking to the RP 5.
-Issue I’m having now, is that when I ran a script, none of the lights are lighting up on the Pico. I’ve wired it up for Day One of Nebula Raiders. This is the link to that same project I did before for wiring, etc.
-I recently did the MicroPython upgrade on the Pico. It shows v1.28.0 on 2026-04-06; Raspberry Pi Pico W with RP2040. Based on today being 9/14/2026, and this URL, I think I’m OK. https://micropython.org/download/RPI_PICO_W/ Looks like it was updated recently, so I’m good for now.
-I’m now wondering if this is something with having to select the “active COM/USB” port. In bottom right, I see: MicroPython (Raspberry Pi Pico). Board in FS Mode @//dev/ttyACM0. Q: Is that USB?
-The answer is yes: Yes, "/dev/ttyACM0" is a virtual serial port created by a USB device connected to your computer.
- USB Connection: The device connects through a USB cable.
- ACM Driver: The
ACMname stands for Abstract Control Model. It means your computer treats the USB device like an old-school serial communication port.
-Well, that explains about the serial port connection. Also, why there was a conflict prior with Plymouth, as I remember that referring to ACM10.
In Thonny, I’m seeing within: View, Files some files within “Raspberry Pi Pico: that I had used prior. I’m wondering if this is why it’s not loading the script, because I’m not seeing it there. Script I’m trying to load is: green-flash.py
When I do “Run, Run Current Script” it says: MPY: soft reboot, but I’m not seeing the LED flash. Also, I tried the test script recently and the built-in green LED on Pico flashed, which proves a connection.
I don’t believe it!!!! I got it working:
I had the LEDs inserted backwards. This code has been running for over a day, and taling to the board. When I flipped each LED around, they started lighting up, in series, as the script is programmed. Several things I learned from this, from an experiential learning perspective:
-There is a big risk of blindly following a schematic, and plugging things in to the breadboard, without an underlying understanding of the electronics required. In this case, nothing bad happened and all components (LEDs, RP Pi Zero, cable, RP Pi 5, power-related items) were not damaged.
-I read a post that said, ” LED Orientation: The longer leg of the LED (positive/anode) connects to your chosen Raspberry Pi Pico GPIO pin. The shorter leg (negative/cathode) connects to a GND (Ground) pin through the resistor.” I basically remember this learning from a while back when I originally did the same project on the iMac. Of course, I haven’t kept up my thinking/awareness of the difference between Anode and Cathode and leg length. When I recently looked at the schematic, I had misinterpreted the squiggle in the schematic for the wrong part of the LED.
-Now that I look at the breadboard, with the resistors, and the cables connected to the Pi Pico, it’s now really obvious what was required. Fully mapping out just one LED (eg Blue, where the longer leg of the LED (positive/anode) connects to RP Pico GPIO pin):
-The blue LED has its longer leg (anode) in breadboard column e, row 24. The shorter leg LED (cathode) is in breadboard column e, row 25. I have a blue lead in column a, row 24 that connects the Pi Zero GP13 via breadboard physical pin (column a, row 17).
-The schematic doesn’t refer to ground (GND), but the Pi Zero has a ground (GND) on breadboard column a, row 18. I have a lead that connects from there to the positive column of the breadboard and in row 18. That means that everything in this positive column is connected to GND.
-There is a 220 ohm resistor, with the color red side, connected in the positive (+) column, row 25. The other part of the resistor is in column b, row 25. This resistor therefore connects to the anode of the blue LED.
How to turn off the LED when I’ve stopped the script:
When I stop the script, it’s possible that one of the LEDs are still lit. Goal is to turn off the LED, so it doesn’t burn out. That may not happen, but I don’t want the light on. I’m also trying to avoid unplugging the USB cable too often.
In Thonny, click the Red Stop sign icon to stop the script
This command assumes that the LED that’s lit is associated with Pin 15. I enter both of these commands in the bottom of Thonny, as if on a command line:
from machine import Pin
Pin(15, Pin.OUT).value(0)
Note: When I did that the LED turned off. Done.
Various logic flaw I have, and some answers/insight:
-I basically understand that the resistor resists energy to avoid burning out an element.
-I basically understand the energy flows from positive to ground
-I don’t really understand the source of energy.
-I don’t really understand the concept of ground
-Based on energy flow, I don’t get how the resistor can be either before the device you’re protecting or after. Something about the full circuit being active.
Description of the energy flow, for overall understanding:
I think I’m going to make this into a new post, as there’s too much going on within this post.
–