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?
Hi,
-----Original Message----- From: Peter Suetterlin <pit@astro.su.se> 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.
-----Original Message----- From: Guillaume Gardet <Guillaume.Gardet@arm.com> Sent: 16 September 2021 10:01 To: Peter Suetterlin <pit@astro.su.se>; arm@lists.opensuse.org Cc: Matthias Brugger <mbrugger@suse.com> Subject: RE: GPIO trouble
Hi,
-----Original Message----- From: Peter Suetterlin <pit@astro.su.se> 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
Guillaume Gardet wrote:
-----Original Message----- From: Guillaume Gardet <Guillaume.Gardet@arm.com>
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!
-----Original Message----- From: Peter Suetterlin <pit@astro.su.se> Sent: 16 September 2021 10:34 To: Guillaume Gardet <Guillaume.Gardet@arm.com> Cc: arm@lists.opensuse.org; Matthias Brugger <mbrugger@suse.com>; nd <nd@arm.com> Subject: Re: GPIO trouble
Guillaume Gardet wrote:
-----Original Message----- From: Guillaume Gardet <Guillaume.Gardet@arm.com>
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
[+ivan +andreas] On 16/09/2021 10:01, Guillaume Gardet wrote:
Hi,
-----Original Message----- From: Peter Suetterlin <pit@astro.su.se> 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.
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¢
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
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
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 <pit@astro.su.se> 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)
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 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
participants (5)
-
Andreas Färber -
Freek de Kruijf -
Guillaume Gardet -
Matthias Brugger -
Peter Suetterlin