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

Issues on Pi Zero W #14

Open
ghost opened this issue Feb 18, 2019 · 0 comments
Open

Issues on Pi Zero W #14

ghost opened this issue Feb 18, 2019 · 0 comments

Comments

@ghost
Copy link

ghost commented Feb 18, 2019

Hi Brian,

to start, I would like to thank you for providing this library, your work is much appreciated! The approach of using the GPIO sysfs interface and a blocking select() call seems more appropriate to me than polling, as it is done in other GPIO implementations.

I use your lib in a private project, in which I am building an audio box, controllable via web app and also physical buttons, running on a Raspberry Pi Zero W.

However, I experience issues when adding new Pins to a button upon a fresh reboot or with unexported pins (via AddPin() with watcher receiver). The behaviour is reproducible. By extending the error printing in function exportGPIO() for debugging purposes, I could see that writing into the direction file is not working, when the issue occurs:

failed to open gpio 2 direction file for writing open /sys/class/gpio/gpio2/direction: permission denied

Restarting the application again the same way as before, the pin can then be added properly. The same goes for additional subsequent starts of the application. (I ruled out any actual permission issues of the user running the application).

Eventually I figured out that the duration of 10ms between calling exportGPIO() and setDirection() seems to be too short for a Pi Zero. Increasing this duration to 100ms, the issue does not occur anymore. So, I suppose that the Pi Zero is simply too slow in order to prepare the GPIO sysfs interface after exporting the pin and subsequently creating the direction file with proper permissions. So the main issue can be described as a race condition.

My actual issue with the described behaviour is that setDirection() calls os.Exit(1) when os.OpenFile() returns an error. I don't want my service to Exit(1), when the direction can't be set. I would rather handle the error and retry adding the pin. I use supervisord to restart my application a few times until all Pins are added and proper configured, however this seems as an ugly workaround for me.

I propose two possible solutions for the issue.

1.) Quick and dirty: Increase sleep duration between exportGPIO() and setDirection() to 100ms (?). Another approach but in the same direction could be providing the option in the lib to give the desired waiting duration externally via parameter to AddPin().

2.) More elaborate: Remove os.Exit(1) call from setDirection() (and ideally the whole lib) and return the error upstream to the exported function (in this case from setDirection() via exportGPIO() and NewInput() to AddPin(), in order to handle the error in the calling application. In case AddPin() fails, the application can then handle the error properly, i .e. retry adding in this case.

If you need more info, just let me know.

Best regards,

Jens

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

0 participants