Skip to content

Need a sleep/timeout after exporting pin? #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
martinsp opened this issue Aug 10, 2015 · 4 comments
Closed

Need a sleep/timeout after exporting pin? #5

martinsp opened this issue Aug 10, 2015 · 4 comments

Comments

@martinsp
Copy link
Contributor

If I run blinky example with pi user then I receive error:

pi@raspberrypi /sys/class/gpio $ id
uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),105(netdev),110(i2c),999(input),1002(spi),1003(gpio)
pi@raspberrypi ~ $ ./blinky 8 800 400
We have a blinking problem: Permission denied (os error 13)

If I run it with root user, everything is working correctly.

By trial and error I have found that after exporting a pin at least a 80ms sleep is required before exported pin can be manipulated by users in group gpio.

If I change blink_my_led function in blinky.rs to

my_led.with_exported(|| {
        sleep_ms(80);
        ...

then everything runs successfully with a pi user.

I have found that when pin is exported for short period of time the owner of the exported pin is root:root. Later the owner is changed to root:gpio. During the period when owner is root:root users in gpio group can't operate the pin.

pi@raspberrypi /sys/class/gpio $ echo 8 > unexport
pi@raspberrypi /sys/class/gpio $ echo 8 > export; ls -l gpio8/*
-rw-r--r-- 1 root root 4096 Aug 10 10:56 gpio8/active_low
lrwxrwxrwx 1 root root    0 Aug 10 10:56 gpio8/device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4096 Aug 10 10:56 gpio8/direction
-rw-r--r-- 1 root root 4096 Aug 10 10:56 gpio8/edge
lrwxrwxrwx 1 root root    0 Aug 10 10:56 gpio8/subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Aug 10 10:56 gpio8/uevent
-rw-r--r-- 1 root root 4096 Aug 10 10:56 gpio8/value
pi@raspberrypi /sys/class/gpio $ ls -l gpio8/*
-rwxrwx--- 1 root gpio 4096 Aug 10 10:56 gpio8/active_low
lrwxrwxrwx 1 root gpio    0 Aug 10 10:56 gpio8/device -> ../../../20200000.gpio
-rwxrwx--- 1 root gpio 4096 Aug 10 10:56 gpio8/direction
-rwxrwx--- 1 root gpio 4096 Aug 10 10:56 gpio8/edge
lrwxrwxrwx 1 root gpio    0 Aug 10 10:56 gpio8/subsystem -> ../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Aug 10 10:56 gpio8/uevent
-rwxrwx--- 1 root gpio 4096 Aug 10 10:56 gpio8/value

I'm not sure if this issue is specific to my Raspbery Pi / Raspbian version or this is how gpio sysfs works on Raspberry Pi. Maybe it should be documented somewhere that a timeout is required after exporting pin?

Raspberry Pi model 1 B+

pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l GNU/Linux
pi@raspberrypi ~ $ cat /etc/debian_version
7.8

@posborne
Copy link
Member

Thanks for filing the issue. I tested mostly on the BBB and RPi 1 and may have been running as root (I don't recall). My expectation is that the export would be a synchronous operation, but you clearly have some evidence to the contrary. Maybe changing of permissions is handled outside of the kernel by something like udev? I'll have to research a bit more.

@martinsp
Copy link
Contributor Author

You are right, permissions are changed by udev, the rules are in /lib/udev/rules.d/60-python3-pifacecommon.rules and /lib/udev/rules.d/60-python-pifacecommon.rules files.

@posborne
Copy link
Member

Ok, given that this is udev, I think I will update the example for greater compatibility and add a comment to the code stating that you may need a delay (or to poll for appropriate stat on some file). I don't think a change to the library core to add a delay would be appropriate as many systems would not be setup in the same way.

@dbrgn
Copy link

dbrgn commented May 4, 2016

I agree that this library should not need to handle delays caused by udev.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants