5

For some time I've heard about the new GPIO character device API, sysfs deprecated, etc. Since I recently upgraded one of my RPi to bullseye, I decided to try this new API - or at least the "user tools" in the package named gpiod. I wanted a GPIO interface I could use in shell scripts, and from the cli.

I connected an LED and a 330 resistor in series between GPIO 25 and GND.

The material I read before deciding to try libgpiod/gpiod made use of the gpiod tools look very straightforward: 1, 2, 3, 4. So far, my experience has been anything but straightforward - at least with the gpioset tool.

Here's the issue:

$ gpioset pinctrl-bcm2835 25=1 # LED not illuminated 
$ gpioset gpiochip0 25=1       # LED not illuminated 
$ gpioset 0 25=1               # LED not illuminated
# gpioget issued immediately after gpioset returned 0 ?!

After "poking around", it seems gpioset ... is not persistent. man gpioset & gpioset -h describe 4 Modes:: I was able to illuminate the LED using the time & wait modes, but these modes are not generally well-suited for many situations. The exit mode seems to be the default, but it apparently toggles the GPIO so quickly that there is no trace of light - useless for an LED iow. And finally the signal mode described as follows: set values and wait for SIGINT or SIGTERM. Hmmm - interesting technique for switching GPIO output state.

I've found a few unofficial sources online that seem to confirm what I'm seeing; i.e. that gpioset is bizarrely non-persistent. But there don't seem to be any solutions offered - other than this ha project code.

Can anyone here confirm this, or offer a solution to get persistent GPIO control using gpioset or another tool based on libgpiod?

Seamus
  • 23,558
  • 5
  • 42
  • 83

4 Answers4

4

@Milliways is correct to say the gpiochip interface currently sets the GPIO back to defaults when the GPIO are released (explicitly by the program or by Linux when a user program terminates without releasing the GPIO).

Whether or not the GPIO should be reset upon release was a gpiochip designer decision. It would have been more flexible to leave this up to the user.

My opinion. Frankly the gpiochip interface is a mess. The designers have made fundamentally bad decisions. gpiochip should be able to control ALL GPIO modes, not just INPUT or OUTPUT. gpiochip should allow the user program to switch between modes without having to release and (hopefully) reclaim the GPIO.

If you want persistence you will need to use the lg daemon.

http://abyz.me.uk/lg/rgpiod.html

joan
  • 71,852
  • 5
  • 76
  • 108
2

UPDATE. This answer was correct at the time BUT no longer as the kernel drivers have been changed to enable persistence.

This is the whole point of these tools.

They are not intended to be used this way and clear any settings on completion. Whatever you do persists only for the duration of the code.

If you enclose in a script they should work but still restore state on exit.

Joan's library is more usable but fundamentally is the same.

If I just wanted to do something simple like set pin 25 HIGH I would use raspi-gpio set 25 op pn dh. No need to fiddle with code - of course libgpiod knows nothing about this.

Milliways
  • 62,573
  • 32
  • 113
  • 225
1

On Raspberry Pi 3 Bullseye Linux rpi 5.15.32-v7+ and gpioinfo (libgpiod) v1.6.2 the command line seems to be persistent. I have a relay connected to gpio17 and the commands:

gpioset 0 17=1 or gpioset 0 17=0

are persistent, as the relay maintain the last state.

Well here is my full history on libgpiod:

With Buster OS updated in July 2021 the libgpiod was persistent. By the end of 2021 I updated again the Buster OS and libgpiod lost persistence.

At the beginning of 2022 I moved to Bullseye and the library was still non persistent. Recently I updated again Bullseye an the library was again persistent.

As I see, it is something to do with the OS and if we want to be up to date with OS we can't rely on persistence as clearly stated by the author of the lib. Let us hope he will change his mind!

MatsK
  • 2,882
  • 3
  • 17
  • 22
Riccardo
  • 11
  • 2
0

In addition to the alternative solution offered by @joan, I'd like to add another alternative:

WiringPi has had some ups and downs since Gordon (the original author) resigned. The wiringpi package was dropped from the bullseye distribution for RPi, but has made a comeback, and is now available - as a deb package at least. Nothing at all against other APIs; in fact my preference for wiringpi is motivated in large part because it includes gpio - a user tool that can be used from the CLI, or in scripts. Note that gpio commands do have persistence... it feels silly having to say that... but this is in the post-libgpiod world!!

For now at least you can find the latest version of wiringpi here. You can download directly to your RPi by clicking one of the links from above.

Installation is accomplished as follows:

$ sudo dpkg -i <choose-your-file>.deb
Seamus
  • 23,558
  • 5
  • 42
  • 83