gpio lib

[tehn]

so i tested GPIO on the proto and it works. in raspbian it's tied to the file system:

echo "35" > /sys/class/gpio/export echo "in" > /sys/class/gpio/gpio35/direction cat /sys/class/gpio/gpio35/value echo "35" > /sys/class/gpio/unexport

(export/unexport only needed for setup/cleanup)

but there are tons of libraries available as well: http://elinux.org/RPi_GPIO_Code_Samples

what do you think the best approach would be to fitting GPIO into the devices framework?

[catfact]

as you say, it's easy to read and write the GPIO using regular sysfs interface. making them show up in /sys/class is a standard kernel config option, not a special feature of raspbian.

what do you think the best approach would be to fitting GPIO into the devices framework?

well, the device_foo modules are all about managing hotplugged USB devices of various classes. GPIO doesn't change so there's nothing to manage. just:

• write to export on boot, as you say
• open a file descriptor for each pin (read/write, nonblocking)
• make a single thread that loops over the FDs and reads each one, with a short timeout (like a few microseconds)
• post event for each successful read

pretty simple.

[tehn]

oh, nice (re: kernel)

so i take that as yes, you're suggesting sysfs over the other options (like direct register access). sounds good to me.

On Sat, Mar 25, 2017 at 9:40 PM, ezra buchla notifications@github.com wrote:

as you say, it's easy to read and write the GPIO using regular sysfs interface. making them show up in /sys/class is a standard kernel config option, not a special feature of raspbian.

what do you think the best approach would be to fitting GPIO into the devices framework?

well, the device_foo modules are all about managing hotplugged USB devices of various classes. GPIO doesn't change so there's nothing to manage. just:

• write to export on boot, as you say
• open a file descriptor for each pin (read/write, nonblocking)
• make a single thread that loops over the FDs and reads each one, with a short timeout (like a few microseconds)
• post event for each successful read

pretty simple.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/catfact/norns/issues/35#issuecomment-289251893, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcEjjzLC3j5a8wuZLpy6-xHLCDpl6ks5rpcIQgaJpZM4MpQ1m .

[catfact]

here's the current usage of poll to watch for data on input devices: https://github.com/catfact/norns/blob/dev/matron/src/device/device_monitor.c#L191

i suppose we could just add /sys/class/gpio to the poll list.

but, i recently discovered epoll, which is similar to poll except that it can also wait on edge or level change conditions (whereas poll just waits until a (set of) file descriptor(s) becomes readable/writable).

so, probably want to use that instead, since i guess we mostly want edge-triggering and that will result in many fewer thread wakeups (i'd hope)

[tehn]

yes, epoll! this looks fantastic, great find.

On Wed, Oct 25, 2017 at 1:39 AM, ezra buchla notifications@github.com wrote:

just a note that i recently discovered epoll http://man7.org/linux/man-pages/man7/epoll.7.html, which is similar to poll except that it can also wait on edge or level change conditions (whereas poll just waits until a (set of) file descriptor(s) becomes readable/writable). so probably want to use that.

here's the current usage of poll to watch for hotplugging, btw: https://github.com/catfact/norns/blob/dev/matron/src/ device/device_monitor.c#L191

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/catfact/norns/issues/35#issuecomment-339220303, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPEcCkQn-nrca8rklbHQZQ3qod7cd6jks5svsmigaJpZM4MpQ1m .

[tehn]

this (and the man page) is a good start for epoll: https://gist.github.com/jadonk/2587524

not fully working as it's only doing a first read, not registering edge ints. fiddled with it for a while, will pick it up again later.

[tehn]

412b411c39bde1f3785b0c82ccdef0f2dc8ef61b