Giters

warthog618 / go-gpiocdev

A native Go library for accessing GPIO lines on Linux platforms using the GPIO character device

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Using already configured pin as output (AsIs)

Juergen07 opened this issue · comments

commented

Thank you for the perfect interrupt driven solution of GPIO pins - this works perfectly for me!
How to use a pin in it's existing configuration, e.g. as output without configuring it as output with a specific level?
I tried to:
pin, err = c.RequestLine(rpi.GPIO17, gpiod.AsIs)
I am able to read the configuration with pin.Info():

  1. If the pin is a input I set it to default AsOutput(0)
  2. If the pin is already a output I want to use it as is (AsIs).

In the application I read the value and change the value if required, e.g.
using: pin.SetValue(x). In case 2 above I get: "ErrPermissionDenied" because l.defCfg.Direction is unkown. I would expect that the AsIs will use the existing configuration (according pin.Info() -> output) and set l.defCfg.Direction accordingly. But this does not happen. Is this expected behavior? What is the correct solution to apply the existing "output" configuration to a pin without changing its output value?

As workaround I could call pin.Reconfigure(gpiod.AsOutput(x)) at all places in my application instead of pin.SetValue(). Another option is to reconfigure the pin after reading the value.

commented

That is the expected and intended behaviour - the line needs to explicitly selected as an output to set the value. That restriction is from the kernel and is to prevent you accidentally messing with an output line by accident, cos making the magic smoke come out is something we like to avoid.
So you have no alternative than to use Reconfigure(gpiod.AsOutput(x)) to request the line as an output after reading it. You only need to do that once - after that you can use SetValue(x). That is preferable to using Reconfigure all the time, as SetValue only changes the line value whereas reconfigure resets the complete request configuration and so is much heavier.

You generally can't rely on reading values in from output lines, whether that works or not is driver dependent so it isn't something we actively encourage, but if it works in your application then go for it.

commented

Thanks for the fast and detailed explanation! Makes all sense. On a PI 4 it works to read the output lines. I have implemented the proposed solution and as far as I can see there is no glitch when applying the read value in "Reconfigure(gpiod.AsOutput(x))". -> solved! Thanks again!