Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

[Software] sysfs deprecated, persistent GPIO state setup under /dev/gpio

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
cls377
Posts: 3
Joined: 2022-11-27 22:18

[Software] sysfs deprecated, persistent GPIO state setup under /dev/gpio

#1 Post by cls377 »

I have a Raspberry Pi model B running Raspberry Pi OS (formerly known as Raspbian, sort of) Bullseye.
I use the sysfs interface to operate a sprinkler valve attached to GPIO25.
The sprinklers are turned on and off by echo(1) commands in crontab(7).

I'd like to replace Raspberry Pi OS with plain old Debian.
I tried the nightly Bookworm build. I like it.
https://wiki.debian.org/RaspberryPiImages
The sysfs interface is deprecated, in favor of a multi-user friendly device interface API. (A device node and an ioctl structure.) The API comes with a set of command line tools that don't directly replace what I could do with
echo 1 > /sys/class/gpio/gpio25/value
before.

What's the Debian way to set a GPIO pin in a persistent state from a cron job? I found the gpiod package, and I can set pins high or low with gpioset(1), but the effect is ephemeral, it disappears when gpioset exits. I found a gpiod daemon on github https://github.com/maquefel/gpiod but as far as I can tell (no documentation) it's only for monitoring inputs.
I suppose I need a daemon that will own the pin continuously and listen for commands on a named pipe or a socket. There's no daemon in the gpiod package https://packages.debian.org/bookworm/gpiod.

User avatar
kent_dorfman766
Posts: 529
Joined: 2022-12-16 06:34
Location: socialist states of america
Has thanked: 56 times
Been thanked: 69 times

Re: [Software] sysfs deprecated, persistent GPIO state setup under /dev/gpio

#2 Post by kent_dorfman766 »

I generally avoid answering pi questions becuase I dislike the platform (as it teaches bad habits and gives feeble managers an unrealistic impression of the sophistication necessary to do real embedded programming)...but, your post shows some promise WRT understanding what you need to do.

My quick-n-dirty answer is that "there is no userland way to manage a GPIO in a persistent state from a cronjob". GPIO, by virtue of what it is and does should be managed from a single point and all IO should be a requested thru that service. There are very good reasons that direct hardware control is a privileged function.

If you intend to manage GPIO in useland then you should create a single long running daemon that owns and manages those GPIO leads, thus taking steps to always properly initialize and reset leads at program startup and shutdown. Adhoc access to invidiual GPIO is a bad idea...

cls377
Posts: 3
Joined: 2022-11-27 22:18

Re: [Software] sysfs deprecated, persistent GPIO state setup under /dev/gpio

#3 Post by cls377 »

Thanks, I kinda gathered that from the arguments in favor of deprecating sysfs, and I don't disagree.

Darn it, I was hoping to be scolded for not searching better, and given the name of the daemon I had overlooked in stable/main.

Before I asked, I actually looked up how to talk to /dev/gpiochip0 the new way,
https://blog.lxsang.me/post/id/33
and wrote a daemon to own the pin, . It listens for a character on a named pipe, then users with permission can echo 1 or 0 into it.
It works, but it seemed so clumsy it couldn't be right.
Which is why I said
>I suppose I need a daemon that will own the pin continuously and listen for commands on a named pipe or a socket.

Sorry if I wasn't clear.


https://www.thegoodpenguin.co.uk/blog/s ... eprecated/


Aki
Global Moderator
Global Moderator
Posts: 2816
Joined: 2014-07-20 18:12
Location: Europe
Has thanked: 68 times
Been thanked: 382 times

Re: [Software] sysfs deprecated, persistent GPIO state setup under /dev/gpio

#5 Post by Aki »

Hello,
cls377 wrote: 2022-11-27 22:43 [..] I found the gpiod package, and I can set pins high or low with gpioset(1), but the effect is ephemeral, it disappears when gpioset exits. [..] I suppose I need a daemon that will own the pin continuously and listen for commands on a named pipe or a socket. There's no daemon in the gpiod package https://packages.debian.org/bookworm/gpiod.
I don't own a RPI and I'm quite novice to the specific topic, but I find your post very interesting.

If I correctly understand the gpioset manual [1], the gpioset can be instructed to stay in background (using the "-m" option with "signal" parameter and the "-b" option for the background running) until it receive a signal (using the kill command with the appropriate signals [2]).

Therefore, you could create two scripts: one to put the specific gpio pin high, on to put it low.

Each script signals the gpioset command running in background to quit, before the script starting a new gpioset command with the desidered pin configuration.

These two scripts could be launched by cron at predetermined times.

---
[1] https://manpages.debian.org/bullseye/gp ... .1.en.html
[2] https://manpages.debian.org/bullseye/pr ... .1.en.html
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀

User avatar
kent_dorfman766
Posts: 529
Joined: 2022-12-16 06:34
Location: socialist states of america
Has thanked: 56 times
Been thanked: 69 times

Re: [Software] sysfs deprecated, persistent GPIO state setup under /dev/gpio

#6 Post by kent_dorfman766 »

>I suppose I need a daemon that will own the pin continuously and listen for commands on a named pipe or a socket.

Sorry if I wasn't clear.
No, probly more that my ADD prohibited me from thoroughly reading the OP. Point I was making is that you should create a delegate/daemon to handle the direct GPIO access and your indicated solution above is exactly what I'd tell my guys to do.

User avatar
kent_dorfman766
Posts: 529
Joined: 2022-12-16 06:34
Location: socialist states of america
Has thanked: 56 times
Been thanked: 69 times

Re: [Software] sysfs deprecated, persistent GPIO state setup under /dev/gpio

#7 Post by kent_dorfman766 »

Aki wrote: 2023-01-29 22:07
Therefore, you could create two scripts: one to put the specific gpio pin high, on to put it low.

Each script signals the gpioset command running in background to quit, before the script starting a new gpioset command with the desidered pin configuration.

These two scripts could be launched by cron at predetermined times.
That is the naive implementation I'm warning against. You now have multiple discrete paths to control a single hardware latch. In the embedded control world that's how things end up catching fire, destroying devices, hurting people,etc...especially in this "we can design crappy hardware and expect the software folks to cover it" world. Unfortunately it's become almost commonplace for hardware designers to cheap-out and not provide good safety critical hardware (hardware limit switches that cut power in unsafe situations), but instead to expect us embedded programmers to compensate.

Rereading the @Aki post I understand why you might think that. gpioset "owns" the pin until it is killed, but you're considering the possibility of a race condition where in the time between signal/kill and reassertion by a new process things can go flaky. That's why a single owning task/process is the only safe mechansim. Any gpio io must be considered a "critical section".

User avatar
kent_dorfman766
Posts: 529
Joined: 2022-12-16 06:34
Location: socialist states of america
Has thanked: 56 times
Been thanked: 69 times

Re: [Software] sysfs deprecated, persistent GPIO state setup under /dev/gpio

#8 Post by kent_dorfman766 »

but this discussion is more for an embedded forum. It's way too low level for typical users and administrators to wrap their heads around.

cls377
Posts: 3
Joined: 2022-11-27 22:18

Re: [Software] sysfs deprecated, persistent GPIO state setup under /dev/gpio

#9 Post by cls377 »

BTW I was unable to find a command line syntax for gpioset(1) to cause it to go into background and hold the pin high until signalled. This command line goes into background but doesn't change the pin from Hi-Z (the default) to driven high. Adding "--drive=push-pull" has no effect.
gpioset -m signal -b gpiochip0 25=1
The manpage and help message are incomplete. They don't give a syntax nor any examples for the arguments chip, offsetN, nor valueN.

Yes I did ask in Raspberry Pi forums. Raspberry PI OS has not yet deprecated sysfs and nobody knew what I was talking about.

Post Reply