Determining the onboard LED for various RP2040 ports?

[freemansoft]

I thought I had a way to lock in on the onboard LED pins for the Pico and PicoW that would work for other RP2040 boards but apparently not. Should I open a request that all RP2 ports implement "LED" the way the Raspberry Pi Pico RP2040 version does?

There is a special LED construct for the Raspberry Pi Pico MicroPython that works for the wifi and non-wifi boards. It accepts a pin named/numbered as "LED" per the following snippet

>>> from machine import Pin
>>> machine.Pin("LED", machine.Pin.OUT)
Pin(WL_GPIO0, mode=OUT)
>>> import os
>>> os.uname()
(sysname='rp2', nodename='rp2', release='1.19.1', version='v1.19.1-782-g699477d12 on 2022-12-20 (GNU 12.1.0 MinSizeRel)', machine='Raspberry Pi Pico W with RP2040')

So I tried the same code on the Pimoroni Micro RP2040 port and no love.

>>> from machine import Pin
>>> machine.Pin("LED", machine.Pin.OUT)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't convert str to int
>>> import os
>>> os.uname()
(sysname='rp2', nodename='rp2', release='1.19.1', version='v1.19.1 on 2022-06-18 (GNU 11.2.0 MinSizeRel)', machine='Pimoroni Tiny 2040 with RP2040')      

Notice that it is hard to use os.uname given how close the text strings are. Is there any guarantee that the machine portion will stay the way it is across releases?

(sysname='rp2', nodename='rp2', release='1.19.1', version='v1.19.1-782-g699477d12 on 2022-12-20 (GNU 12.1.0 MinSizeRel)', machine='Raspberry Pi Pico W with RP2040')
(sysname='rp2', nodename='rp2', release='1.19.1', version='v1.19.1 on 2022-06-18 (GNU 11.2.0 MinSizeRel)', machine='Pimoroni Tiny 2040 with RP2040')      

My code was zeroing in on sysname but that won't work here.

[jimmo]

The background here is that that machine.Pin("LED") was a special thing that was added for the Pico W because the LED pin is not a "real" pin. We made it possible to use "LED" on all the other boards too (as long as they define PICO_DEFAULT_LED_PIN in their pico-sdk header).

Where did you get the firmware for the "Pimoroni Micro RP2040" from? I don't think we have a board definition for that, so did it come from Piomoroni instead? Your firmware is also a lot older (2022-06-18). I suspect it possibly doesn't have this feature.

We just (like four days ago) merged general support for pin naming for the rp2 port, so going forward it will match the other ports, including the ability to write machine.Pin.board.LED.

[freemansoft]

The Pimoroni build was the last "stable" build on the Micropyhon download site. I just tested the jan 20 2023 build and that worked as you described

>>> from machine import Pin
>>> machine.Pin("LED", machine.Pin.OUT)
Pin(GPIO19, mode=OUT)
>>> machine.Pin.board.LED
Pin(GPIO19, mode=OUT)
>>> import os
>>> os.uname()
(sysname='rp2', nodename='rp2', release='1.19.1', version='v1.19.1-831-g4f3780a15 on 2023-01-20 (GNU 12.1.0 MinSizeRel)', machine='Pimoroni Tiny 2040 with RP2040')

[freemansoft]

That worked nicely for the jan 20 nightly for the Pico W also

MicroPython v1.19.1-831-g4f3780a15 on 2023-01-20; Raspberry Pi Pico W with RP2040
Type "help()" for more information.
>>>
>>> from machine import Pin
>>> machine.Pin("LED", machine.Pin.OUT)
Pin(EXT_GPIO0, mode=OUT)
>>> machine.Pin.board.LED
Pin(EXT_GPIO0, mode=OUT)
>>> import os
>>> os.uname()
(sysname='rp2', nodename='rp2', release='1.19.1', version='v1.19.1-831-g4f3780a15 on 2023-01-20 (GNU 12.1.0 MinSizeRel)', machine='Raspberry Pi Pico W with RP2040')
>>>

[freemansoft]

And the Pico without wireless

MicroPython v1.19.1-831-g4f3780a15 on 2023-01-20; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>> from machine import Pin
>>> machine.Pin("LED", machine.Pin.OUT)
Pin(GPIO25, mode=OUT)
>>> machine.Pin.board.LED
Pin(GPIO25, mode=OUT)
>>> import os
>>> os.uname()
(sysname='rp2', nodename='rp2', release='1.19.1', version='v1.19.1-831-g4f3780a15 on 2023-01-20 (GNU 12.1.0 MinSizeRel)', machine='Raspberry Pi Pico with RP2040')
>>>

[obdevel]

I use this for code that may run on the Pico or Pico W

try:
    led = Pin('LED', Pin.OUT)
except TypeError:
    led = Pin(25, Pin.OUT)

[cve2022]

try:
    led = Pin('LED', Pin.OUT)
except TypeError:
    led = Pin(25, Pin.OUT)

That is the pythonic way to do it. :-)

Beeing a relatively newbie with python, it would not occur to me doing that (until now 😉). I mean, I have already used some more (I believe) sophisticated constructs, e.g., class inheritance, and also exception handling, but it would not occur to me using the error itself as a functionality.

Brilliant!!! The solution I mean. Very beautiful in its simplicity. Believe it or not, it is really aestetically pleasing to me looking at it. I still have a looooong way to go 😄 .

[freemansoft]

It is a Pythonic way of doing things that you don't see in some other language. Exceptions can be expensive creating stack traces.

This example converts a servo microsecond pulse width into the appropriate timer duty cycle. Some processors have 10-bit timers and others have 16-bit. The calculations are scaled to the timer length of the board.

            us = min(self.max_us, max(self.min_us, us))
            try:
                # the duty method takes the duty portion over 1024 so a portion of 1024
                # convert usec to duty cycle knowing  frequency in this case 50Hz results in 20ms period
                duty = us * 1024 * self.freq // 1000000
                self.pwm.duty(duty)
                if self.debug_enabled:
                    print("Servo: converted us:", us, " to duty:", duty)
            except AttributeError:
                # the rp2 rp2040 is 16 bit. The duty cycle over 0-65535
                # Total PWM period is 20ms or 20,000usec - 50hz
                duty = us * 65535 * self.freq // 1000000
                self.pwm.duty_u16(duty)
                if self.debug_enabled:
                    print("Servo request us:", us, " set duty_u16 to:", duty)

[peterhinch]

This is known as the EAFP principle - easier to ask forgiveness than permission. By contrast with LBYL - look before you leap.

I've often wondered if it is optimum in a microcontroller context because of the stack issue you mention. I try to judge each case on its merits.

[jimmo]

Some processors have 10-bit timers and others have 16-bit.

@freemansoft This is tangential to the original topic, but FYI the point of duty_u16 is not because it's a 16-bit timer, but to provide a consistent API for setting the duty cycle regardless of the underlying timer. i.e. the idea is that duty() is implementation-specific, but duty_u16() works the same way regardless. If you want a 50% cycle, then duty_u16(32768) works everywhere.

See https://docs.micropython.org/en/latest/library/machine.ADC.html

[jimmo]

I use this for code that may run on the Pico or Pico W

This will work on older releases, but from 1.20 onwards, all rp2040 boards with an LED will have machine.Pin.board.LED (or machine.Pin("LED").

We are also planning to allow all boards to provide a board module, allowing for board.led which will allow things like active-low LEDs to be handled via machine.Signal. See e.g. https://github.com/micropython/micropython/pull/10276/files#diff-2c74df564e7b3bc717d89070229a67117dc0401a39e04bd2d970107f67536c2e for one of the first boards to do this.