Re: gpiod: Set pullup for Input Line

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 22, 2022 at 10:39:00AM +0100, Hans Kurscheidt wrote:
> 
> Am 22.03.2022 um 09:50 schrieb Andy Shevchenko:
> > On Tue, Mar 22, 2022 at 10:39 AM Hans Kurscheidt <lve0200@xxxxxxxxx> wrote:
> > > Am 22.03.2022 um 09:36 schrieb Hans Kurscheidt:
> > > > Am 22.03.2022 um 01:59 schrieb Kent Gibson:
> > ...
> > 
> > > > Still 1 more question. I understand the sense of a Pull-up in Input
> > > > mode, but reading the code, I see that the Bias option exists as well
> > > > for gpioset (Output). What is the sense of this, and what does it do?
> > I guess we started providing OPEN SOURCE / DRAIN in libgpiod v2.0
> > (Bart or Kent may correct me), but you should get an idea why it may
> > be useful.
> > 
> > On top of that, the pin can be reconfigured from input to output and
> > vice versa at run-time. So, keeping a bias setting will allow not to
> > think about it when pin direction is switched, although I agree this
> > may not be a clean case to use.
> 
> Hi Andy,
> 
> Open Source/Drain is completely different from Pull_UP/DOWN! Open
> source/drain defines, which active element (transistor) is attached to the
> line, while pull_up/down defines, which passive element (resistor) is
> attached to the line. In some sense one could say, what pull_up/down is for
> input, open drain/source is the corresponding thing for output, but they are
> realized by different means. IMHO, "bias" (pull-up/down) should be an option
> for gpioget, while "drive" makes only sense for gpioset, because I
> understand them as mutually excluding, but may be, I'm overseeing something.
> 

You understand that with open drain/source there is one state where the
line is not driven by the chip, but goes high impedance and is driven
by the external circuit?  
And the bias can be considered to be part of the external circuit?
If so, not sure what your issue is here.  You agree that drive and bias are
totally independent, but take issue at being able to set them
independently in gpioset?  What am I missing?

And there IS a bias option for gpioget - as it makes sense there as
well.  And gpiomon as well.

> Unfortunately, this leads me to yet another question: Bias defines "as-is"
> and "pull-up/down" as options. Just to be sure, that would imply that one
> has to set the bias option to pull_up/down for the first call to gpioget and
> that subsequent readings from the input pin should/can run w/out the bias
> option, hence "as-is", or do you recommend to have the bias option specified
> for each read from the pin?
> 

The "as-is" is an unfortunate side-effect of bias being a late addition
to the API, though it could be argued that it is useful in its own
right, as Andy mentioned.
Its main purpose is for backwards compatibility and is the default for that
reason.

If you need a bias then set it as needed.  I would use options consistently,
not have different options on subsequent calls.

I would also recommend using edge events, such as those provided by
gpiomon, rather than polling with gpioget, but that depends on the complexity
of your use case.

Cheers,
Kent.



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux