FWIW, when I was looking at doing a gpio drive I was thinking of something like the following.
Devices: #G/gpio/ctl #G/gpio/$pin/ctl #G/gpio/$pin/data #G/gpio/$pin/event ... bing -a '#G' /dev A pin must be configured before use (and only if neither of its data & event file is open). For example: echo 'in rising edge high' > /dev/gpio/10/ctl Syntax reset # reset to default in [async][rising|falling][edge] [high|low] [init $value] [buf $value] out [pullup|pulldown] [init $value] [strength $value] alt [0..5] # pi specific You can use the same syntax to configure multiple pins by writing to /dev/gpio/ctl and appending pin numbers. echo 'out pullup 4 12 17' > /dev/gpio/ctl You can *gang* multiple pins into a single port. For example: echo 'create 100 1 2 5 10' > /dev/gpio/ctl This creates a new "pin" 100 (number must be >= # of physical pins) and creates a new entry in /dev/gpio. This succeeds only if the pins can actually be ganged (this is device dependent). You can now configure the port: echo 'in rising edge low' > /dev/gpio/100/ctl To delete a port echo 'delete 100' > /dev/gpio/ctl All constituent pins revert to their default state. Reading /dev/gpio/N/data returns a sample of the present value. [The following needs more work] Reading /dev/pio/N/event blocks the caller until something changes. Returns value and timestamp (in case of "async" inputs, events are handled in the interrupt handler and buffered). Random notes: An "in" pin has an init value since some pins can be bidirectional. "alt" may create other devices as a side-effect such as SPI, I2C, I2S, PWM, UART etc. Configs are sticky and persist across device opens, which is why there is a "reset" command. While this may be easy to use, its implementation would be somewhat complex.... Ideally one would break this into a small core kernel mode driver and a fancier user mode one for configuring. I stopped at this point for various reasons and never got back to it. On Sat, 02 Jan 2016 10:06:31 PST erik quanstrom <quans...@quanstro.net> wrote: > On Fri Jan 1 21:15:03 PST 2016, blstu...@bellsouth.net wrote: > > On Fri, 1/1/16, erik quanstrom <quans...@quanstro.net> wrote: > > > i'm looking @ the gpio interface, and i wonder what the recommended > > > technique for sampling a pin might be from a shell script? > > > > I haven't really used it in shell scripts, but if I were going to do > > so, I'd probably write up a little utility to take a hex string and > > a bit number and do the 'and' on it. Then feed that with the > > result of dd to get exactly one sample from devgpio. On the > > other hand, if one of the usual suspects (e.g. hoc, bc, dc, awk) > > have some bit-wise operators I'm forgetting, use that. > > the (atom) aux/number program does do that; none of the others do > for fairly fundamental reasons: as awk and hoc are really floating > point, and bc and dc are mp, and the mp library has no bit operations. > i believe acid can as well, but only with great pain. > > perhaps just using base 2 for the encoding would make life a lot easer. so > > 00000000000000000000000000010000000000000000000000000000000000000 > > for bit 27 active. with this format there's no limit to the number of bits > one could represent. > > also, mightn't there be some value in presenting the full state of the device > to allow it to be restored directly from the status file, so perhaps 3 lines > could be added, one each for up/down/float settings? > > 00000000000000000000000000010000000000000000000000000000000000000 > 00000000000000000000000000010000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000 > > might represent bit 27 set, with the pull up resistor active. (perhaps > float =E2=89=A1 (pullup | pulldown) =3D=3D 0? and could be elimitated. > > i'm sure a little tinkering with this idea can make it a lot more useful. > > - erik