Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 5273

Advanced users • Re: Is everyone happy with the quality of libgpiod?

$
0
0
... I'd certainly be dis-inclined to get involved with a project lead who may be completely out of his depth. What does this guy not get about persistence? Does he have a 'spring return' on the light switch in his bedroom such that he has to stay up all night holding it OFF to get some sleep???
If you accept the principle of 'libgpiod' to be that 'whoever claims a GPIO owns it until they relinquish that ownership' it makes sense.

There is no spring needed while the guy owns the light switch; he turns it on and it stays on, he turns it off and it stays off, until he turns it on again. While he owns it there's an invisible guard placed outside the bedroom door who prevents anyone else coming in and interfering with the switch setting.

The issue arises in what to do when no one owns it, when someone comes in, takes ownership of the light switch, turns it on, relinquishes ownership, leaves - which is effectively what 'gpioset' does; ownership is relinquished when that command terminates and passes control back to the command line.

The light switch setting can either persist or it can revert to some default, when ownership is relinquished, or ownership is subsequently claimed.

In the case where someone, some app, takes ownership and never relinquishes ownership there is no problem. It is only when using the command line where 'gpioset' and 'gpioget' are 'pop-in, own it, set or get, relinquish ownership, and leave' that it's an issue.

A 'gpioset' which doesn't persist makes little sense to me, though that seems to have been the functionality at one point.

As to 'gpioget' resetting to a default, whether that should be the case or not depends on whether wanting to read an output setting, or wanting to read an input on that pin. One can argue that, rather than a single command with an option, it would have been better to have two distinct commands.

The main problem with 'gpioget', at least with 1.6.3 on Bookworm, is '--as-is' doesn't exist, that there is no way to override the resetting to default. And 'gpioinfo' doesn't show what signal levels output pins have.

I have no idea how things actually are with anything later than 1.6.3.

<...going back to the beginning of this thread...>
hippy: I'm interested here in your comment about "ownership",
-------- or as you put it, "the principle of 'libgpiod' to be that 'whoever claims a GPIO owns it until they relinquish that ownership'" :

On a RPi5 under 'bookworm', using libgpiod, gpioget and gpioset ver. 1.6.3, there are
two users: 'pi' and 'not-pi', both members of group 'gpio' ===>

RE "Ownership"

Code:

# from the terminal of user 'pi': pi@raspberrypi5:~ $ gpioset gpiochip4 24=1        # LED @ GPIO24 turns "ON" pi@raspberrypi5:~ $ # from the terminal of user 'not-pi': not-pi@raspberrypi5:~ $ gpioset gpiochip4 24=0    # LED @ GPIO24 turns "OFF" not-pi@raspberrypi5:~ $ 
And so I'm confused by the concept of "ownership" you mentioned. In this scenario, user 'pi' did nothing to relinquish ownership. But of course 'gpioset' did exit, and I guess that effectively relinquished ownership of GPIO24. But that seems (to me) to be something besides "ownership"... and could also be thought of as a loss of persistence, since user 'pi' lost his "persistence" due to the actions of user 'not-pi'. What happened to that "invisible guard" you mentioned? :)

And it makes no difference whether or not these commands are executed from the CLI, or from a shell script - they will behave exactly the same as shown here. There may be something in 'libgpiod' that allows a user to exercise "ownership" of a GPIO (in the sense of the "invisible guard" you mentioned), but there's nothing in 'gpioset' that does. And so it's unclear to me how 'gpioset' and 'gpioget' (ver 1.6.3) behave any differently than 'sysfs' did... at least in 'sysfs' one was required to use 'sudo', which did not afford "ownership", but at least granted some "exclusivity".

RE "main problem with gpioget"
You also said that you felt the main problem with 'gpioget' (ver 1.6.3) is that it didn't have an '--as-is' option (as gpioget ver 2.1 does). But I must disagree; the actual problem with 'gpioget' is that it behaves as 'gpioset' ! You should not need an option to force a 'get' function to not behave as a 'set' function; this shouldn't be controversial, I hope.

Code:

# from the terminal of user 'pi': pi@raspberrypi5:~ $ gpioset gpiochip4 24=1        # LED @ GPIO24 turns "ON" pi@raspberrypi5:~ $ gpioget gpiochip4 24          # LED @ GPIO24 turns "OFF" pi@raspberrypi5:~ $ gpioset gpiochip4 24=1        # LED @ GPIO24 turns "ON"pi@raspberrypi5:~ $ # from the terminal of user 'not-pi': not-pi@raspberrypi5:~ $ gpioget gpiochip4 24      # LED @ GPIO24 turns "OFF"not-pi@raspberrypi5:~ $ 
I'll make my comments on the ver 2.1 'gpioset' and 'gpioget' in a separate post.

Statistics: Posted by irishmonk-57 — Sun Jan 14, 2024 4:00 am



Viewing all articles
Browse latest Browse all 5273

Trending Articles