Closed haikusw closed 2 years ago
Hi, the LED on the pico W is not connected to the LED pin, it's connected to the wifi module. Circuitpython doesn't support the pico W wifi module yet. You'll have to follow #6558 to know when.
Edit: FYI the pin named LED on the pico (GP25) has a different purpose on the pico W, it is one of the connection lines with the wifi module instead. The W does not have a direct LED pin. You can connect an external LED to an available pin to blink.
HI! I see. Thank you. Somewhat counter intuitive.
Reasonable to assume that the CP abstraction layer will finesse this and map the board.LED to the appropriate wifi module when that is supported?
Reasonable to assume that the CP abstraction layer will finesse this and map the board.LED to the appropriate wifi module when that is supported?
Probably not, actually, because board.LED
is supposed to be an actual pin that you can use to create a DigitalInOut
, and that would not be possible due to the indirection through the wifi module. The Arduino Nano Connect has similar simulated "pins". We could special case all that but it would be a lot of board-specific code.
I see. Thanks for the reply. If not then it seems like a fair amount of documentation will need to be updated; the pi pico W is already very popular because of price and capabilities and a lot of folks are going to run into the basic getting started tutorials and samples and hit this.
The code to blink the LED via PIO is rather intense for a new learner like the ones CircuitPython is catering to:
https://github.com/micropython/micropython/tree/master/ports/rp2#pio-blinky
So I don't know if it's possible, but it sounds like there are two cases (Arduino Nano Connect and Pi Pico W) where this is probably desirable. Seems like board-specific code (in ports?) is a big part of what CircuitPython is doing to abstract away these complexities for new learners? I'm new to looking at all this so maybe I'm misunderstanding the goals of the project (likely!)).
Cheers.
The code to blink the LED via PIO is rather intense for a new learner like the ones CircuitPython is catering to:
PIO for that is not going to work for the LED on the Pico W either, since it assumes a direct pin connection. The blinking has to be handled by the firmware on the wifi module, and corresponding software on the Pico side. So we have to make a duck-typing implementation of DigitalInOut
for that "pin". And use of that "pin" for other purposes that it doesn't support, like input or pull-ups, has to be forbidden.
MicroPython does special case the LED, by letting you use "LED"
as the pin "number". Normally it takes integers as pin numbers. https://github.com/micropython/micropython/blob/master/ports/rp2/machine_pin.c
At the pico-sdk level, it's pretty different: https://github.com/raspberrypi/pico-examples/blob/master/pico_w/blink/picow_blink.c
So I'm not saying it's not possible, and perhaps I was being too grouchy about it. It would have nice if something as basic as LED blinking hadn't changed between the two boards. (It would also be nice to have pin numbers on the top of the board :smiley: ...)
Thank you for your patience. I apologize for my ignorance. I'm on day 2 of looking at python on these type of boards and most of that was spent fighting with building Mu locally so I could fix an annoying bug (can't seem to get it to build on my M1 MBP for some reason).
Yah, "LED" seemed like an ease of use definition - thanks for pointing me to the MicroPython code.
Interesting to read the pico sdk source that points down into a cyw43-driver project that doesn't provide source for the actual firmware. Complicated layers on layers on layers!
P.S. re PIN numbers - small is cool, but tradeoffs! Someone felt a need to make this AR scanner as result:
Pretty cool, but I need larger labels for my old eyes :)
The [video] (https://twitter.com/TrevTheVanguard/status/1547751301596864512)
That AR is from us :) . I made this paper label you can stick underneath: https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython/downloads
Thank you for your patience. I apologize for my ignorance. I'm on day 2 of looking at python on these type of boards and most of that was spent fighting with building Mu locally so I could fix an annoying bug (can't seem to get it to build on my M1 MBP for some reason).
It's a known bug on the Mu side with changing from PyQT5 to 6 in Mu's requirements on M1 Macs. I had the same issue last weekend.
Issue #6558 suggests that maybe Pi Pico W isn't fully supported yet (😿) but I wanted to add that even the most basic sample doesn't completely function:
prints the string repeatedly but the led on the Pi Pico W doesn't function (I have two Pi Pico W boards I got from adafruit between July 10 and July 20th, 2022).
Output:
Tested with all of:
output from the last most up to date version to
boot_out.txt
was:All tests done using Mu 1.1.1 on macOS 12.4 (M1).
No difference in behavior observed between any of these versions of CP. Possible both boards are from the same manufacturing batch and there's a common flaw, but I wouldn't know how to test that currently.