GPIO trouble

older
Help! OpenSUSE Tumbleweed with KDE...

Peter Suetterlin

15 Sep 2021 15 Sep '21

15:52

Hi list, slowly trying to get known with my Pi 4 running Tumbleweed. I added a fan, and wanted to control it via GPIO. But I fail to actually control the pins :( I was trying to follow this description: https://howchoo.com/g/ote2mjkzzta/control-raspberry-pi-fan-temperature-pytho... that uses GIOP17. So I installed the needed 'gpiozero' python package using pip. Trying the command 'pinout' that is part of it results in an error: Unable to initialize GPIO Zero. This usually means that you are not running pinout on a Raspberry Pi. If you still wish to run pinout, set the GPIOZERO_PIN_FACTORY environment variable to 'mock' and retry, or refer to the Remote GPIO section of the manual* to configure your environment to remotely access your Pi. So I export GPIOZERO_PIN_FACTORY=mock, then I get a pinout listed, I can run python, and with from gpiozero import OutputDevice fan = OutputDevice(17) I can use fan.on(), fan.off() or fan.value to set/read the state. Just the pin doesn't do anything, it always stays low :( So I wanted to get most basic and tried echo 17 > /sys/class/gpio/export but that gave me only "write error: Invalid argument" Indeed the directory only lists Pi4:~ # ls /sys/class/gpio export gpiochip446 gpiochip454 unexport which suggests lowest GPIO available is 446!? What am I missing?

Show replies by date

Guillaume Gardet

16 Sep 16 Sep

08:01

Hi,

...

-----Original Message----- From: Peter Suetterlin Sent: 15 September 2021 17:52 To: arm@lists.opensuse.org Subject: GPIO trouble

Hi list,

slowly trying to get known with my Pi 4 running Tumbleweed. I added a fan, and wanted to control it via GPIO. But I fail to actually control the pins :(

I was trying to follow this description: https://howchoo.com/g/ote2mjkzzta/control-raspberry-pi-fan-temperature- python that uses GIOP17. So I installed the needed 'gpiozero' python package using pip.

Trying the command 'pinout' that is part of it results in an error:

Unable to initialize GPIO Zero. This usually means that you are not running pinout on a Raspberry Pi. If you still wish to run pinout, set the GPIOZERO_PIN_FACTORY environment variable to 'mock' and retry, or refer to the Remote GPIO section of the manual* to configure your environment to remotely access your Pi.

So I export GPIOZERO_PIN_FACTORY=mock, then I get a pinout listed, I can run python, and with from gpiozero import OutputDevice fan = OutputDevice(17) I can use fan.on(), fan.off() or fan.value to set/read the state. Just the pin doesn't do anything, it always stays low :(

So I wanted to get most basic and tried echo 17 > /sys/class/gpio/export but that gave me only "write error: Invalid argument"

Indeed the directory only lists Pi4:~ # ls /sys/class/gpio export gpiochip446 gpiochip454 unexport

which suggests lowest GPIO available is 446!?

What am I missing?

Did you have a look at https://en.opensuse.org/openSUSE:GPIO for standard packages to access GPIO instead of downstream, RPi specific, software? You can use 'gpioinfo gpiochip446' and 'gpioinfo gpiochip454' to get info about the gpio available. You can try to use an offset of 446, so try to set gpio 463 (446 + 17). Not sure why there is such an offset, though. Matthias, any idea? Cheers, Guillaume IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Guillaume Gardet

08:05

...

-----Original Message----- From: Guillaume Gardet Sent: 16 September 2021 10:01 To: Peter Suetterlin ; arm@lists.opensuse.org Cc: Matthias Brugger Subject: RE: GPIO trouble

Hi,

...
-----Original Message----- From: Peter Suetterlin Sent: 15 September 2021 17:52 To: arm@lists.opensuse.org Subject: GPIO trouble

Hi list,

slowly trying to get known with my Pi 4 running Tumbleweed. I added a fan, and wanted to control it via GPIO. But I fail to actually control the pins :(

I was trying to follow this description: https://howchoo.com/g/ote2mjkzzta/control-raspberry-pi-fan-temperature - python that uses GIOP17. So I installed the needed 'gpiozero' python package using pip.

Trying the command 'pinout' that is part of it results in an error:

Unable to initialize GPIO Zero. This usually means that you are not running pinout on a Raspberry Pi. If you still wish to run pinout, set the GPIOZERO_PIN_FACTORY environment variable to 'mock' and retry, or refer to the Remote GPIO section of the manual* to configure your environment to remotely access your Pi.

So I export GPIOZERO_PIN_FACTORY=mock, then I get a pinout listed, I can run python, and with from gpiozero import OutputDevice fan = OutputDevice(17) I can use fan.on(), fan.off() or fan.value to set/read the state. Just the pin doesn't do anything, it always stays low :(

So I wanted to get most basic and tried echo 17 > /sys/class/gpio/export but that gave me only "write error: Invalid argument"

Indeed the directory only lists Pi4:~ # ls /sys/class/gpio export gpiochip446 gpiochip454 unexport

which suggests lowest GPIO available is 446!?

What am I missing?

Did you have a look at https://en.opensuse.org/openSUSE:GPIO for standard packages to access GPIO instead of downstream, RPi specific, software?

You can use 'gpioinfo gpiochip446' and 'gpioinfo gpiochip454' to get info about the gpio available.

You can try to use an offset of 446, so try to set gpio 463 (446 + 17). Not sure why there is such an offset, though. Matthias, any idea?

And latest released Tumbleweed (20210901) test in openQA shows gpiochips 0 and 1: gpiochip0 [pinctrl-bcm2711] (58 lines) gpiochip1 [raspberrypi-exp-gpio] (8 lines) See: https://openqa.opensuse.org/tests/1898134#step/libgpiod/14

...

Cheers, Guillaume

Peter Suetterlin

08:34

Guillaume Gardet wrote:

...

...
-----Original Message----- From: Guillaume Gardet

...

...
Did you have a look at https://en.opensuse.org/openSUSE:GPIO for standard packages to access GPIO instead of downstream, RPi specific, software?

Ah no - I saw that there is a different gpio package, and installed it, but had no clue how to use it :( So I first had a try at the 'basic /sys method'..

...

...
You can use 'gpioinfo gpiochip446' and 'gpioinfo gpiochip454' to get info about the gpio available.

Actually 'gpiochip0' and 'gpiochip1'. But yes, that indeed does the trick. Reading further explains also why I failed with /sys: Note that the base, which is the N from /sys/class/gpio/gpiochipN, must be added to the GPIO number. This is never mentioned because on Raspbian N is 0. So indeed a bit irritating with the implementation that it lists /sys/class/gpio/gpiochip446 and /sys/class/gpio/gpiochip454 but refers to them as gpiochip0 and gpiochip1 in gpioinfo whereas the /sys interface requires the 446/454 offsets. I'd assume that is a kernel thing?

...

And latest released Tumbleweed (20210901) test in openQA shows gpiochips 0 and 1: gpiochip0 [pinctrl-bcm2711] (58 lines) gpiochip1 [raspberrypi-exp-gpio] (8 lines)

Indeed, that's what I see here, too :D I'm physically away from the Pi, so I cannot verify that the output actually gets 'high' - but I'm very confident it does. Thanks for getting me on the right track!

Guillaume Gardet

08:38

...

-----Original Message----- From: Peter Suetterlin Sent: 16 September 2021 10:34 To: Guillaume Gardet Cc: arm@lists.opensuse.org; Matthias Brugger ; nd Subject: Re: GPIO trouble

Guillaume Gardet wrote:

...
...
-----Original Message----- From: Guillaume Gardet

...
...
Did you have a look at https://en.opensuse.org/openSUSE:GPIO for standard packages to access GPIO instead of downstream, RPi specific, software?

Ah no - I saw that there is a different gpio package, and installed it, but had no clue how to use it :(

So I first had a try at the 'basic /sys method'..

...
...
You can use 'gpioinfo gpiochip446' and 'gpioinfo gpiochip454' to get info about the gpio available.

Actually 'gpiochip0' and 'gpiochip1'. But yes, that indeed does the trick.

Reading further explains also why I failed with /sys:

Note that the base, which is the N from /sys/class/gpio/gpiochipN, must be added to the GPIO number. This is never mentioned because on Raspbian N is 0.

So indeed a bit irritating with the implementation that it lists /sys/class/gpio/gpiochip446 and /sys/class/gpio/gpiochip454 but refers to them as gpiochip0 and gpiochip1 in gpioinfo whereas the /sys interface requires the 446/454 offsets. I'd assume that is a kernel thing?

The GPIO /sys interface is a deprecated interface provided by the kernel and is not recommended to use anymore.

...

...
And latest released Tumbleweed (20210901) test in openQA shows gpiochips 0 and 1: gpiochip0 [pinctrl-bcm2711] (58 lines) gpiochip1 [raspberrypi-exp-gpio] (8 lines)

Indeed, that's what I see here, too :D I'm physically away from the Pi, so I cannot verify that the output actually gets 'high' - but I'm very confident it does.

Thanks for getting me on the right track!

Great! Let us know if it is working, once you will be near to the Pi. Cheers, Guillaume

Matthias Brugger

09:33

[+ivan +andreas] On 16/09/2021 10:01, Guillaume Gardet wrote:

...

Hi,

...
-----Original Message----- From: Peter Suetterlin Sent: 15 September 2021 17:52 To: arm@lists.opensuse.org Subject: GPIO trouble

Hi list,

slowly trying to get known with my Pi 4 running Tumbleweed. I added a fan, and wanted to control it via GPIO. But I fail to actually control the pins :(

I was trying to follow this description: https://howchoo.com/g/ote2mjkzzta/control-raspberry-pi-fan-temperature- python that uses GIOP17. So I installed the needed 'gpiozero' python package using pip.

Trying the command 'pinout' that is part of it results in an error:

Unable to initialize GPIO Zero. This usually means that you are not running pinout on a Raspberry Pi. If you still wish to run pinout, set the GPIOZERO_PIN_FACTORY environment variable to 'mock' and retry, or refer to the Remote GPIO section of the manual* to configure your environment to remotely access your Pi.

So I export GPIOZERO_PIN_FACTORY=mock, then I get a pinout listed, I can run python, and with from gpiozero import OutputDevice fan = OutputDevice(17) I can use fan.on(), fan.off() or fan.value to set/read the state. Just the pin doesn't do anything, it always stays low :(

So I wanted to get most basic and tried echo 17 > /sys/class/gpio/export but that gave me only "write error: Invalid argument"

Indeed the directory only lists Pi4:~ # ls /sys/class/gpio export gpiochip446 gpiochip454 unexport

which suggests lowest GPIO available is 446!?

What am I missing?

Did you have a look at https://en.opensuse.org/openSUSE:GPIO for standard packages to access GPIO instead of downstream, RPi specific, software?

You can use 'gpioinfo gpiochip446' and 'gpioinfo gpiochip454' to get info about the gpio available.

You can try to use an offset of 446, so try to set gpio 463 (446 + 17). Not sure why there is such an offset, though. Matthias, any idea?

Unfortunately not. Maybe it would be something worth to investigate as users regularly get confused about that. I remember that we had that discussion in the past, but can't recall what was the outcome. Andreas do you remember? Regards, Matthias

...

Cheers, Guillaume

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Peter Suetterlin

10:00

Matthias Brugger wrote:

...

[+ivan +andreas]

On 16/09/2021 10:01, Guillaume Gardet wrote:

...
Did you have a look at https://en.opensuse.org/openSUSE:GPIO for standard packages to access GPIO instead of downstream, RPi specific, software?

You can use 'gpioinfo gpiochip446' and 'gpioinfo gpiochip454' to get info about the gpio available.

You can try to use an offset of 446, so try to set gpio 463 (446 + 17). Not sure why there is such an offset, though. Matthias, any idea?

Unfortunately not. Maybe it would be something worth to investigate as users regularly get confused about that.

I remember that we had that discussion in the past, but can't recall what was the outcome. Andreas do you remember?

As a simple user without distracting background knowledge ;^> : The main source of irritation seems to be that the naming scheme is different - at least compared to Raspbian. But when searching the web, most of the hits will refer to that. The behavior of the /sys interface (deprecated or not) is consistent (N + line, with N the number from gpiochipN). Just that 'for us' N is not zero. For the user it would be a help if that naming could (also) start with zero. Not sure if there is a kernel boot parameter to influence that (similar to the ethernet device naming schemes), or if it's a compile time parameter... libgpiod seems to refer to the first one as gpiochip0 anyhow, so adjusting the kernel name would increase consistency, IMO. My 2¢

Freek de Kruijf

13:43

Op donderdag 16 september 2021 12:00:15 CEST schreef Peter Suetterlin:

...

Matthias Brugger wrote:

...
[+ivan +andreas]

On 16/09/2021 10:01, Guillaume Gardet wrote:

...
Did you have a look at https://en.opensuse.org/openSUSE:GPIO for standard packages to access GPIO instead of downstream, RPi specific, software?

You can use 'gpioinfo gpiochip446' and 'gpioinfo gpiochip454' to get info about the gpio available.

You can try to use an offset of 446, so try to set gpio 463 (446 + 17). Not sure why there is such an offset, though. Matthias, any idea?

Unfortunately not. Maybe it would be something worth to investigate as users regularly get confused about that.

I remember that we had that discussion in the past, but can't recall what was the outcome. Andreas do you remember?

As a simple user without distracting background knowledge ;^> :

The main source of irritation seems to be that the naming scheme is different - at least compared to Raspbian. But when searching the web, most of the hits will refer to that.

The behavior of the /sys interface (deprecated or not) is consistent (N + line, with N the number from gpiochipN). Just that 'for us' N is not zero.

For the user it would be a help if that naming could (also) start with zero. Not sure if there is a kernel boot parameter to influence that (similar to the ethernet device naming schemes), or if it's a compile time parameter... libgpiod seems to refer to the first one as gpiochip0 anyhow, so adjusting the kernel name would increase consistency, IMO.

My 2¢

I have been struggling with this on a Raspberry Pi 1B and made the Python module for that device called RPi.GPIO. However there is a difference between a RPi1 and other RPi's. RPi1 shows "export gpio321 gpiochip298 unexport" in /sys/class/gpio/, where the start of N is clearly 298. However on a RPi4 /sys/ class/gpio/ shows "export gpiochip446 gpiochip454 unexport". To me the question is: which one of 446 and 454 is the start value? On a RPi3 with Raspbian one gets in /sys/class/gpio/ "export gpiochip0 gpiochip100 gpiochip504 unexport", as mentioned earlier the start value is 0. -- fr.gr. Freek de Kruijf

Peter Suetterlin

14:31

Freek de Kruijf wrote:

...

I have been struggling with this on a Raspberry Pi 1B and made the Python module for that device called RPi.GPIO. However there is a difference between a RPi1 and other RPi's. RPi1 shows "export gpio321 gpiochip298 unexport" in /sys/class/gpio/, where the start of N is clearly 298. However on a RPi4 /sys/ class/gpio/ shows "export gpiochip446 gpiochip454 unexport". To me the question is: which one of 446 and 454 is the start value?

454 is the correct start value. You get more info running (from libgpiod-utils) Pi4:~ # gpiodetect gpiochip0 [pinctrl-bcm2711] (58 lines) gpiochip1 [raspberrypi-exp-gpio] (8 lines) Pi4:~ # cat /sys/class/gpio/gpiochip454/label pinctrl-bcm2711

...

On a RPi3 with Raspbian one gets in /sys/class/gpio/ "export gpiochip0 gpiochip100 gpiochip504 unexport", as mentioned earlier the start value is 0.

I got several other replies - not sure why they don't show up here on the list. Upshot is, Raspbian has a downstream patch that changes that number for the 'right' gpiochip to 0 :( I'm now using python3-gpiod. Seems straight forward, given that even I with my absolutely basic python knowledge was able to make the needed changes. import gpiod chip=gpiod.Chip("gpiochip0") fan=chip.get_lines([17]) fan.request(consumer='fancontrol', type=gpiod.LINE_REQ_DIR_OUT) fan.set_values([1]) fan.get_values() fan.release() chip.close() :D

Peter Suetterlin

14:37

Peter Suetterlin wrote:

...

I got several other replies - not sure why they don't show up here on the list.

Ah, my fault - seems the list daemon doesn't send it to me if I'm CCed on the submitted post, and my mailer only sorts mails from opensuse into this folder...

Andreas Färber

10:08

Hi Matthias and Peter, On 16.09.21 11:33, Matthias Brugger wrote:

...

On 16/09/2021 10:01, Guillaume Gardet wrote:

...
...
-----Original Message----- From: Peter Suetterlin Sent: 15 September 2021 17:52 To: arm@lists.opensuse.org Subject: GPIO trouble

Hi list,

slowly trying to get known with my Pi 4 running Tumbleweed. I added a fan, and wanted to control it via GPIO. But I fail to actually control the pins :(

I was trying to follow this description: https://howchoo.com/g/ote2mjkzzta/control-raspberry-pi-fan-temperature- python that uses GIOP17. [...] So I wanted to get most basic and tried echo 17 > /sys/class/gpio/export but that gave me only "write error: Invalid argument"

Indeed the directory only lists Pi4:~ # ls /sys/class/gpio export gpiochip446 gpiochip454 unexport

which suggests lowest GPIO available is 446!?

What am I missing?

Did you have a look at https://en.opensuse.org/openSUSE:GPIO for standard packages to access GPIO instead of downstream, RPi specific, software?

You can use 'gpioinfo gpiochip446' and 'gpioinfo gpiochip454' to get info about the gpio available.

You can try to use an offset of 446, so try to set gpio 463 (446 + 17). Not sure why there is such an offset, though. Matthias, any idea?

Unfortunately not. Maybe it would be something worth to investigate as users regularly get confused about that.

I remember that we had that discussion in the past, but can't recall what was the outcome. Andreas do you remember?

Raspberry Pi have a downstream patch that's hardcoding numbers to align with their schematics or whatever. That's not acceptable to upstream. With multiple GPIO chip devices there's no guarantees of their relative probing order and thus number, so the best way is to use DT overlays to specify GPIOs as input or output to the respective driver, if there is. Then userspace doesn't need to deal with GPIO numbers at all. In fact there is a gpio-fan binding that might just be used here: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Doc... Also, the sysfs GPIO interface is documented as obsolete, so with Factory it may break at some point. https://www.kernel.org/doc/html/latest/driver-api/gpio/intro.html#gpio-inter... libgpiod is the designated replacement since multiple years. https://build.opensuse.org/package/show/hardware/libgpiod Not familiar with which of the interfaces which Python packages consume. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

Peter Suetterlin

11:19

Andreas Färber wrote:

...

Hi Matthias and Peter,

...

Raspberry Pi have a downstream patch that's hardcoding numbers to align with their schematics or whatever. That's not acceptable to upstream.

Ah, that explains it. (And I agree we should stick with upstream...)

...

In fact there is a gpio-fan binding that might just be used here:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Doc...

Interesting! Thanks for the link - I'll have avery close look at it :)

...

Also, the sysfs GPIO interface is documented as obsolete, so with Factory it may break at some point.

I had only used it to verify HW is working, and as that had failed, too, I got nervous...

...

libgpiod is the designated replacement since multiple years.

So we only need to communicate that to "the others" *eg*

...

https://build.opensuse.org/package/show/hardware/libgpiod

Not familiar with which of the interfaces which Python packages consume.

My (remote) tests with python3-gpiod indicate everything works fine. I'll verify tomorrow when I'm (physically) at the Pi again.

Peter Suetterlin

17 Sep 17 Sep

11:44

Peter Suetterlin wrote:

...

My (remote) tests with python3-gpiod indicate everything works fine. I'll verify tomorrow when I'm (physically) at the Pi again.

As expected, the fan is perfectly working now with the adapted script. I'm just compiling (kstars - takes an hour or so), it automatically switched on (at 65⁰C), and does switch off again once below 55⁰C :D

950

Age (days ago)

952

Last active (days ago)

List overview

Download

12 comments

5 participants

participants (5)

Andreas Färber
Freek de Kruijf
Guillaume Gardet
Matthias Brugger
Peter Suetterlin

GPIO trouble

tags

participants (5)