-
Notifications
You must be signed in to change notification settings - Fork 36
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
Comments
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. |
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
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]>
Is there any kernel documentation concerning this? In my testing GPIOs do not revert to their initial state when the |
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: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 theLineHandle
instance to a variable like this:Then the pin state is correctly set, presumably because the file descriptor contained inside the
LineHandle
doesn't immediately get dropped afterrequest
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 theLineHandle
instance in addition to theChip
.If you agree, then I will open a small PR to update the examples and docstrings to make note of this.
The text was updated successfully, but these errors were encountered: