Pi internal LEDs (47) no longer accessible with gpiozero v2.0

[ziddey]

Operating system: Raspbian Bookworm
Python version: 3.11
Pi model: Pi Zero W
GPIO Zero version: 2.0
Pin factory used: RPiGPIO

>>> LED(47)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ziddey/doorman/venv_doorman/lib/python3.11/site-packages/gpiozero/devices.py", line 103, in __call__
    self = super().__call__(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ziddey/doorman/venv_doorman/lib/python3.11/site-packages/gpiozero/output_devices.py", line 192, in __init__
    super().__init__(pin, active_high=active_high,
  File "/home/ziddey/doorman/venv_doorman/lib/python3.11/site-packages/gpiozero/output_devices.py", line 74, in __init__
    super().__init__(pin, pin_factory=pin_factory)
  File "/home/ziddey/doorman/venv_doorman/lib/python3.11/site-packages/gpiozero/mixins.py", line 75, in __init__
    super().__init__(*args, **kwargs)
  File "/home/ziddey/doorman/venv_doorman/lib/python3.11/site-packages/gpiozero/devices.py", line 549, in __init__
    pin = self.pin_factory.pin(pin)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ziddey/doorman/venv_doorman/lib/python3.11/site-packages/gpiozero/pins/pi.py", line 413, in pin
    raise PinInvalidPin(f'{name} is not a valid pin name')
gpiozero.exc.PinInvalidPin: 47 is not a valid pin name

[ziddey]

As a workaround, I'm shoehorning GPIO47 into PLUS_J8 before having a pin factory set:

gpiozero.pins.data.PLUS_J8[2][47] = gpiozero.pins.data.PI1_GPIO47
led = gpiozero.LED(47, active_high=False)

or 29 for the zero2w https://forums.raspberrypi.com/viewtopic.php?t=324132

[waveform80]

I'm afraid this is a casualty of the new means of accessing GPIO pins. It is possible to address non-physical GPIOs via the gpiochip devices but most that users would be interested in are already marked "in use" by the kernel, and so cannot be allocated. For instance, output from gpioinfo on a Pi 4:

$ gpioinfo
gpiochip0 - 58 lines:
...
        line  41:  "PWM1_MOSI"       unused   input  active-high
        line  42: "STATUS_LED_G_CLK" "led0" output active-high [used]
        line  43: "SPIFLASH_CE_N" unused input active-high
...
gpiochip1 - 8 lines:
        line   0:      "BT_ON"       unused  output  active-high
        line   1:      "WL_ON"       unused  output  active-high
        line   2: "PWR_LED_OFF" "led1" output active-low [used]
        line   3: "GLOBAL_RESET" unused output active-high
        line   4: "VDD_SD_IO_SEL" "vdd-sd-io" output active-high [used]
        line   5:   "CAM_GPIO"       unused  output  active-high
        line   6:  "SD_PWR_ON" "sd_vcc_reg"  output  active-high [used]
        line   7:    "SD_OC_N"       unused   input  active-high

The [used] flags indicate that these GPIOs are already reserved (usually by the kernel). You are correct that this doesn't preclude use of those GPIOs via the legacy pin factories (like RPi.GPIO), but this left several unpalatable options:

1. Make the board info "aware" of the pin factory in use, so the non-physical ("internal") GPIOs appear with the legacy factories but not the gpiochip derived ones
2. Leave the board info "unaware" of the pin factory in use, and have scripts that will work on legacy pin factories, but not gpiochip derived ones
3. Leave the board info "unaware" of the pin factory in use, but remove non-physical GPIOs so script behaviour is consistent across different factories, but break people currently using non-physical GPIOs

Option 1 horrifically complicates the internal APIs, so that was out. Options 2 and 3 are both "nasty", but if the future is "everything goes via the kernel" and "GPIOs shall not be shared among processes" then only option 3 is realistic.

That said, I have noticed that I failed to remember to remove the section on controlling internal LEDs from the docs. That needs to be dealt with, so I'm assigning this to me.

[lurch]

By "non-physical GPIOs" do you mean any GPIO that isn't present on the Pi's 40-way GPIO header?

[waveform80]

Yes, sorry -- should've made that clear. It's a clunky turn of phrase, but then so is "GPIO not exposed on the header". Suggestions welcome for anything similarly brief, but more comprehensible!