All of the blether in this thread has been good... but as stated by one of the participants here under another thread:
It seems the author has seen the folly of lack-of-persistence. Ver 2.1 of gpioset includes an option called --daemonize (or -z); described in the man as "set values then detach from the controlling terminal". Anyway - test results follow :
The test configuration:
![Image]()
Here's my *interpretation* of what happened after the 'gpioset -c 0 -z 24=1' command: - when the gpioget -c 0 24 command malfunctioned.
From the earlier post from 6by9:
This commit made changes to the pinctrl driver which (apparently) overcame the libgpiod ver 1.6 lack of persistence. That change is now having an undesirable effect on the libgpiod ver 2.1 version of gpioset; i.e. perhaps "too much persistence"?
Additional testing is ongoing, but this looks like progress to me. Analysis or comments?
Taking this statement at face value, I've installed the ver 2.1 libgpiod on my Pi 3a 'bullseye' system. A bit of a pain (compared to `apt install ...`) , but I think I have gotten all the pieces in the right places. It occurred to me that in the 3 years (3 years) since release of the 1.6.2 version installed on my bullseye system, surely the author must have learned a few things. I thought I would give 2.1 a spin & run a few simple tests. I am mildly encouraged.libgpio[d] is the correct answer for any variant of Pi now. [balance excised]
It seems the author has seen the folly of lack-of-persistence. Ver 2.1 of gpioset includes an option called --daemonize (or -z); described in the man as "set values then detach from the controlling terminal". Anyway - test results follow :
The test configuration:
Code:
$ gpiodetect --versiongpiodetect (libgpiod) v2.1# blah blah blah$ gpiodetectgpiochip0 [pinctrl-bcm2835] (54 lines)gpiochip1 [raspberrypi-exp-gpio] (8 lines)$ gpioget -c 0 24"24"=inactive$ gpioset -c 0 24=1# The LED illuminates, but the bash prompt does not return...??? - issue 'ctrl-C'^C$ gpioget -c 0 24"24"=inactive# The LED is extinguished immediately$ gpioset -c 0 -z 24=1# using daemonize option; LED illuminates, and bash prompt returns immediately$ gpioget -c 0 24gpioget: unable to request lines: Device or resource busy# hmmm... use ps-hunt-and-kill$ ps -aux | grep 'gpioset'pi 7854 0.0 0.0 1988 84 ? Ss 19:54 0:00 gpioset -c 0 -z 24 1$ kill 7854$ gpioget -c 0 24"24"=inactiveHere's my *interpretation* of what happened after the 'gpioset -c 0 -z 24=1' command: - when the gpioget -c 0 24 command malfunctioned.
From the earlier post from 6by9:
The Pi kernel branch has a patch that keeps the state on close... ref Pi0-4
This commit made changes to the pinctrl driver which (apparently) overcame the libgpiod ver 1.6 lack of persistence. That change is now having an undesirable effect on the libgpiod ver 2.1 version of gpioset; i.e. perhaps "too much persistence"?
Additional testing is ongoing, but this looks like progress to me. Analysis or comments?
Statistics: Posted by irishmonk-57 — Thu Dec 21, 2023 9:03 pm