Closed SpComb closed 7 years ago
I've taken a slightly different approach in #67, which is to ignore the error if the pin has already been exported. This way it's only one system call.
That sounds like it would also work just as well.
I used to workaround catching os signal, and unexporting in init through cmd.exec
@wiless I don't understand. The fix in #69 is https://github.com/kidoman/embd/pull/69/commits/091d6f558821db718702f1dd9636637d2c429d6f, I'm not sure what signals or cmd.exec have to do with that...
@tve I meant to say was my workaround to handle unexported GPIO issue
init()
I attempt to unexport the GPIO through calling echo 1 > /sys/class/gpio..
through cmd.exec
. This ensures that the error is avoided.I'm pretty convinced that this is taken care of by #69. Please reopen with an example if it's not.
Change digitalPin to allow the use of an already exported gpio pin, avoiding the
write /sys/class/gpio/export: device or resource busy
errors that currently result. This kind of situation is easy to end up in if you e.g. kill the process and restart it, without giving it a chance to unexport its pins.This should suffice to handle the issues mentioned in #30 and #44.
This also helps to deal with the
open /sys/class/gpio/gpio21/direction: permission denied
races in #52, by allowing us to use a helper script to pre-export the gpio pins and wait for udev to settle.