bifferboard reset by button press - no open_wrt

[docbee]

I realize that bifferboard reset button just triggers a GPIO pin and
therefore needs some driver/loop code that watches GPIO status to
recognize a button press. I also realize that there is a short c-
program in the wiki that makes use of "/dev/gpio_proxy" to listen for
button presses being reported. This seems to work along with a
corresponding open_wrt package that seems to setup the needed device.

I am in a situation that I have compiled 2.6.30.5 which runs in the 1
MB flash and I am wondering how to get the button evaluated from user
level, as "/dev/gpio_proxy" is not there. I applied available patches
to 2.6.30.5, as a result blinking the red LED via echoing to "/sys/
class/...." does work.

How can I get info about a button press most easily from where I am?
Any hint is highly welcome...

[Razvan Dragomirescu]

I think the easiest would be to just write a simple shell script that keeps doing something like

 

cat /sys/class/gpio/gpio15/value

 

Whenever that value goes to 0, the button has been pressed. You don't have to hammer the system with reads, one every second is perfectly fine (as long as your user keeps the button pressed for at least that long).

 

So, to summarize

 

#!/bin/sh

echo 15 > /sys/class/gpio/export

while : ; do

BUTTON=`cat /sys/class/gpio/gpio15/value`

if [ "$BUTTON" = "0" ]; then

    echo "Reset button pressed"

fi

sleep 1

done

 

Happy? :).

 

Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

[Nelson Neves]

Red LED (RTCRD/GPIO16)
Reset button (RTCAS/GPIO15)

for the Led you have used:
echo 16 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio16/direction
echo 0 > /sys/class/gpio/gpio16/value
echo 1 > /sys/class/gpio/gpio16/value

for the button you need to use:
echo 15 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio15/direction

cat /sys/class/gpio/gpio15/value

That's it!

Regards,
Nelson.

source: http://groups.google.com/group/bifferboard/browse_thread/thread/1dc454cdacc18ddb#

[Nelson Neves]

Sorry Razvan, didn't noticed that you already had an answer!

docbee, please follow Razvan example, that's really what you need ;)

Regards,
Nelson.

[docbee]

Thanks a lot!
I have it working by means of a small c program that also detects if
the button has been pressed for a short time <0.5 secs or for >2 secs.
It is going into a reboot when pressed for a longer time (took me some
time to find out that "kill 1" does a reboot) and just a restart of my
application on the short button press.

Again, thanks for your help.

On Sep 15, 11:20 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> Sorry Razvan, didn't noticed that you already had an answer!
>
> docbee, please follow Razvan example, that's really what you need ;)
>
> Regards,
> Nelson.
>
> On Tue, Sep 15, 2009 at 10:04 PM, Razvan Dragomirescu <
>

[Andrew Scheller]

> I am in a situation that I have compiled 2.6.30.5 which runs in the 1
> MB flash and I am wondering how to get the button evaluated from user
> level, as "/dev/gpio_proxy" is not there. I applied available patches
> to 2.6.30.5, as a result blinking the red LED via echoing to "/sys/
> class/...." does work.
>
> How can I get info about a button press most easily from where I am?
> Any hint is highly welcome...

I guess the 'brute force' approach would be to repeatedly keep reading
the relevant /sys/class/... file - however that's clearly not the
'correct' approach!!!
I've done a bunch of google-research, and I believe this is the
nearest I've got to the right answer:
http://www.google.co.uk/search?hl=en&q=sysfs+inotify+poll+select

However I'm not familiar with low-level Linux programming, so can't be
bothered to learn enough to 'go further'... hopefully someone else can
help out :)
From what (little) I've read I think it should all be possible using
syscalls, making glibc/dietlibc unnecessary.

Lurch

[bifferos]

On Sep 16, 1:12 am, Andrew Scheller <ya...@loowis.durge.org> wrote:
> I guess the 'brute force' approach would be to repeatedly keep reading
> the relevant /sys/class/... file - however that's clearly not the
> 'correct' approach!!!
> I've done a bunch of google-research, and I believe this is the
> nearest I've got to the right answer:http://www.google.co.uk/search?hl=en&q=sysfs+inotify+poll+select

Yeah, you can certainly use select from userspace with the right
driver, but aren't you forgetting something? Nobody gets 'told' when
the pin changes state (you can't associate a hw interrupt with it), so
either you poll in userspace, or you poll in the driver. You can
setup a 'kernel' thread to keep checking and maybe you save a few
cycles this way since no kernel->userspace switch, but it's not really
worth the bother unless you want to poll faster than every 50mS or so.

Biff.

[Andrew Scheller]

> Yeah, you can certainly use select from userspace with the right
> driver, but aren't you forgetting something?  Nobody gets 'told' when

Dunno, I'm not familiar with low-level linux programming... ;)
I dunno what the select and poll functions do either, I just had a gut
feeling that there had to be a 'better' way of doing things than
repeatedly opening, reading & closing the file... *shrug*

Lurch

[bifferos]

select() is a way of saying to the kernel something like "I want to go
to sleep until something happens to this file descriptor" (and
therefore the device behind the descriptor, be it NIC interface, or
file on disk, or other device). The sleeping process will not consume
any CPU while it's waiting. It might want to wait for some packets to
arrive on a NIC, or data on a serial port, or simply wait for another
process to do something. Select can make things more elegant because
a user application can be written to use it once, and then the kernel
could either poll or use interrupts depending on what it can support
for that device, so it provides an abstraction layer to prevent
application polling, however this will only be useful if there are
plans to port the app. to other boards which *do* have a real
interrupt that can be generated from that pin, or if there are other
applications that need to wait on the pin state at the same time (in
the latter case, we can do only one lot of polling in the kernel).
You are certainly on the right track, but it's not worth the effort if
this only needs to work on Bifferboard, and is only used for rebooting
the system.

Biff.