Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve documentation about keeping LineHandles in scope #29

Open
kmdouglass opened this issue Dec 12, 2019 · 2 comments
Open

Improve documentation about keeping LineHandles in scope #29

kmdouglass opened this issue Dec 12, 2019 · 2 comments

Comments

@kmdouglass
Copy link
Contributor

Hello!

First, thanks a lot for creating this crate and the work you put into it.

I have a small suggestion that could improve the documentation. Consider the following program which is a simplified version of the driveoutput.rs example:

use gpio_cdev::{Chip, LineRequestFlags};

fn main() {
    let mut chip = Chip::new("/dev/gpiochip0").unwrap();

    chip
        .get_line(4).unwrap()
        .request(LineRequestFlags::OUTPUT, 1, "set-pin").unwrap();
    
    println!("Press Enter to exit");
    let mut buf = String::new();
    ::std::io::stdin().read_line(&mut buf).unwrap();
}

This program compiles and does not panic, but seemingly does nothing as the pin remains in an unset state while the program waits on the user to press Enter. However, if we assign the LineHandle instance to a variable like this:

let _handle = chip
        .get_line(4).unwrap()
        .request(LineRequestFlags::OUTPUT, 1, "set-pin").unwrap();

Then the pin state is correctly set, presumably because the file descriptor contained inside the LineHandle doesn't immediately get dropped after request is called.

I think that it is important to note in the comments that the LineHandle needs to remain in scope or assigned to a persistent variable to prevent these sorts of "silent failures." It may be obvious in the above example, but in my case I do some initialization of the chip and store it inside a struct that is passed around; it took me about a day of debugging to realize that I needed initialize and store the LineHandle instance in addition to the Chip.

If you agree, then I will open a small PR to update the examples and docstrings to make note of this.

@fpagliughi
Copy link
Contributor

fpagliughi commented Dec 12, 2019

I agree that's a good point. It's quite a surprise for people using the chardev GPIO for the first time, regardless of the language/implementation. There seems to be an assumption from the previous model that you can write a small app to set the value of a pin, and then when you exit the app, everything remains as you set. And the same goes for maintaining the handles from within the app.

So I'm all for improving the docs and examples for making this more obvious.

kmdouglass added a commit to kmdouglass/gpio-cdev that referenced this issue Dec 13, 2019
This commit addresses \rust-embedded#29 by expanding the documentation to explain the
importance of maintaining valid LineHandles in a program that uses this library.

- A comment was added to the Read State code example in the README to explain
  that the LineHandle must be maintained for the line to work
- A similar comment was added to the `driveoutput.rs` example
- A brief explanation was added to the section entitled "Exporting" a GPIO of
  the README about the file descriptor that is associated with a line
bors bot added a commit that referenced this issue Jan 15, 2020
30: Improve documentation about maintaining LineHandles r=nastevens a=kmdouglass

This commit addresses #29 by expanding the documentation to explain the
importance of maintaining valid LineHandles in a program that uses this library.

- A comment was added to the Read State code example in the README to explain
  that the LineHandle must be maintained for the line to work
- A similar comment was added to the `driveoutput.rs` example
- A brief explanation was added to the section entitled "Exporting" a GPIO of
  the README about the file descriptor that is associated with a line

Co-authored-by: Kyle M. Douglass <[email protected]>
@Florob
Copy link

Florob commented Nov 24, 2022

Is there any kernel documentation concerning this? In my testing GPIOs do not revert to their initial state when the LineHandle is dropped. So at least the README's claim that this "will" happen is incorrect.
I've not been able to find any concrete documentation concerning this. There is one blog post that also claims that GPIOs might reset, but like me they were not able to actually produce that behavior.
Maybe this depends on the underlying gpiochip/pinctrl?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants