adafruit / circuitpython

CircuitPython - a Python implementation for teaching coding with microcontrollers
https://circuitpython.org
Other
4.09k stars 1.21k forks source link

Pi Pico W LED doesn't blink when running the standard Circuit Python tutorial blink sample #6628

Closed haikusw closed 2 years ago

haikusw commented 2 years ago

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:

import board
import digitalio
import time

led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT

while True:
    print("Hello, CircuitPython!")
    led.value = True
    time.sleep(1)
    led.value = False
    time.sleep(1)

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:

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable. code.py output: Hello, CircuitPython! Hello, CircuitPython! Hello, CircuitPython! Hello, CircuitPython! Hello, CircuitPython!

Tested with all of:

output from the last most up to date version to boot_out.txt was:

Adafruit CircuitPython 8.0.0-alpha.1-60-gf2bbe5a6a on 2022-07-20; Raspberry Pi Pico with rp2040 Board ID:raspberry_pi_pico

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.

Neradoc commented 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.

haikusw commented 2 years ago

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?

dhalbert commented 2 years ago

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.

haikusw commented 2 years ago

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.

haikusw commented 2 years ago

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.

dhalbert commented 2 years ago

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: ...)

haikusw commented 2 years ago

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:

Screen Shot 2022-07-22 at 11 52 57 AM

Pretty cool, but I need larger labels for my old eyes :)

The [video] (https://twitter.com/TrevTheVanguard/status/1547751301596864512)

dhalbert commented 2 years ago

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

prcutler commented 2 years ago

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.