checking the current status of the line

[ktostam]

I would like to check the current state of a particular line. I have a problem, because after setting the state, for example, for gpiochip0 line 200 (gpioset 0 200=1) I am not able to check through gpioget 0 200 the current state. The command sets 0 for that line and always displays the state as 0. Is there any other way to check what current state the line has?

libgpiod == 1.6.5 hardware == NanoPi neo Air system == buildroot

Best regards Jacek B

[brgl]

I'm not sure I understand your issue. Why would you need to check the state of the line you're driving? You know its value, you just set it. In any case - as long as you're driving it, it's busy and you cannot request it from another process.

[ktostam]

one of the processes writes a value depending on the result of some action, another process checks from time to time if the line is driven and depending on this performs some action. These are two different processes that do not communicate with each other. I am trying to adapt my scripts to libgpiod, previously I used /sys/class/gpio and there I could do it without any problems. Now I am wondering what will be the easiest way to adapt to libgpiod.

[warthog618]

What language are your scripts written in?

By default gpioget switches the line to an input, so losing any output value if one was set. With libgpiod v2, gpioget has a --as-is option to retrieve the value without changing the line direction. How well that works depends on the underlying driver, as that may return the line to its default state when the line is released, e.g. when gpioset exits. I'm not sure how the NanoPi driver behaves.

Your two scripts do communicate with each other - using the GPIO as shared state. Generally speaking using a GPIO as shared state is unreliable. Bart is developing a daemon that controls lines and allows you to query the state of lines as set by the daemon. That will be the most general replacement for the persistence the sysfs interface provided. Alternatively you could write the shared state to a file as well as the GPIO.

[brgl]

If you can build current master branch from sources then you can already try the daemon out. Please take a look at README and let me know if there's anything missing. Although I'm not sure if you have buildroot with D-Bus support. I have a branch with a yocto recipe that builds the daemon and autostarts it but you'd need devtool modify libgpiod to check out current master.

[ktostam]

Scripts are written in python. I will try to build from the master branch and try daemon. I have to rebuild the buildroot system anyway, so I will add D-Bus.

[warthog618]

If your scripts are written in Python, consider using the Python bindings rather than the command line tools. You can install the current bindings with pip install gpiod. There are examples in the bindings/python/examples directory of the sources. Not terribly relevant if you do use the daemon, but in case you don't.

[ktostam]

I tried to write a simple script in python using the gpiod library, but the result was the same as using system tools.... I will try again with the library, but will also try to use daemon.

[warthog618]

Similar to the command line tools, you need to select the direction=gpiod.line.Direction.AS_IS option in the line settings when requesting the line to not overwrite any existing output value.

[ktostam]

Thanks I will try out

[ktostam]

for now I cant build libgiod from source. I am using Fedora 40 and there is no autoconf >=2.72, so I need to wait for new release. I will try with with python and direction=gpiod.line.Direction.AS_ISoption, but ultimately I would like to use d-bus. so I'll come back to the topic in a month or so.

EDIT: direction=gpiod.line.Direction.AS_IS works great. libgpiod: v2.1.3 python lib: 2.2.1 board: nano pi neo air

[brgl]

autoconf >=2.72 We don't require it. Have you been able to test the D-Bus API? It's in master now and about to be released.

[brgl]

No activity so closing.