brian-armstrong/gpio

Go library to do GPIO on systems with /sys/class/gpio (sysfs)

gpio's Issues

openPin() architect improvement

in
func openPin(p Pin, write bool) Pin {
}

It would be better not to call fmt.Printf() and os.Exit(1) inside openPin()
instead please return p, err

it's works on NenoPi NEO2

Hi Brian
Thanks for your work! I appreciate very much this project.
I'm have tested your library on NanoPi NEO2. It's works!

Thank you!

Please forgive me for using the Issues to leave a message for you.

Support/expose channels

Instead of calling a blocking function, listening to a channel would be better.

We could select between a gpio event and something else.

Issue with watcher on Pi Zero

Hello Brian,

I’m using the latest Raspbian image on Raspberry Pi Zero + Zero Ws, I can read a pin manually without issue, but I haven’t gotten any action out of the watcher. I have two questions:

1. Has the library been tested on the Zero / Zero W before? If not, is there any reason to think it might not be compatible?

2. I’m using BCM pin 7 (physical pin 26) as an input. As far as I understood, the kernel uses BCM numbering; pin := gpio.NewInput(7) works, so is there any reason why watcher.AddPin(7) wouldn’t?

Thanks for your help!

GPIO0-GPIO7 Always High

Because GPIO0 through (and including) GPIO7 are set as Pull-Up (always High) by default, you have to connect them to GND to switch them from 1 to 0.

You cannot set them Low().

Other sysfs peripherals

Hi Brian
Thanks for your work! I appreciate very much this project.
I'm preparing to test your library on Beaglebone Black and UDOO. Hope this help 😊

Just a question, did you plan to add also some other peripherals (PWM for example)? I can try to do that, but I'm not sure you want such things in your project (name of your repo is gpio). Let me know

Cheers,
Andrea Cioni

Non-blocking way to catch the pin change events ?

watcher.Watch() is good, but it blocks the program execution. Is there a non-blocking way to catch the pin change events ?

Can watcher.Notification do this ? If yes, could you give me some example code ? I am very new to golang. Thanks.

De-jankify select() call

The merging of posix-style select() call with Go seems pretty jank, at least in this implementation. The select() has a 1-second timeout, so that if there are no pins changing, it takes up to a second to add and remove new pins to the watcher https://github.com/brian-armstrong/gpio/blob/master/watcher.go#L112 and https://github.com/brian-armstrong/gpio/blob/master/watcher.go#L193

We should investigate if it's possible to remove these in some way without impacting CPU.

One possible option, though sort of gross, would be to open a file in /tmp (or a socket) and have our select() call include it in its readfds. Then a goroutine could write to this file descriptor in order to wake up the select() caller, which could then do maintenance like adding/removing pins or closing. If we did this, we could possibly remove the 1-second timeout entirely, allowing us to sleep more while having very good latency for these sorts of operations.

failed to call syscall.Select, interrupted system call

Hi @brian-armstrong

for quickly enough changes, I'm getting this error, I think it's comming from

gpio/watcher.go

Line 118 in 72b0058

if err != nil {

Cannot we add here check for syscall.EINTR and return there?

Thank you in advance

Jan

Wrong permissions + Timing issue in NewOutput/NewInput

Hi @brian-armstrong,

I'm start testing your work on Beaglebone Black, I'm getting the following error: failed to open gpio 60 direction file for writing. I've changed last parameter in all occurences of os.OpenFile in sys.fs to 0666 (r/w for everyone) and everything works. I'm using it as a non-root user but my account belongs to gpio group.

Andrea Cioni

Issues on Pi Zero W

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

Issues on RPI3B+

Is anyone aware of breaking changes between using this library on a RPI 3B compared to a RPI 3B+? We have strange behavior sometimes (yes, really strange) when controlling a RPI relay board https://www.exp-tech.de/module/relais/7442/rpi-relay-board via this library. It might be changes to the /sys directory which only apply to RPI3, but I am not quite sure. We run our software in docker containers on rpi and the only difference really is RPI3B+ instead of RPI3B. Any help appreciated!