which armbian and kernel support OPi.GPIO as non root?

[arhi]

The armbian I am running

Welcome to ARMBIAN 5.31 stable Debian GNU/Linux 8 (jessie) 4.11.5-sun8i

and few other versions that I tried have same issue with accessing GPIO from python as non root, and I, of course, need to access GPIO as non root

 

however I setup permissions for /dev and /sys and whatever udev rules I configure there is some race condition and I can't get access to GPIO as a non root from python

typical error is something like:

:IOError: [Errno 13] Permission denied: '/sys/class/gpio/gpio1/direction'

 

So I solved it by some hack of the OPi.GPIO library and udev rules that are not really feasible "always" so I'm trying to figure out if there's a combo of armbian distro and kernel where this works "out of the box" to use on other orangepi boxes I'm setting up?

[Igor]

Check this topic:
https://forum.armbian.com/topic/1851-rfc-make-armbian-more-iot-friendly/ There is a wish but few developers can't catch up with everything.
 

2 hours ago, arhi said:

so I'm trying to figure out if there's a combo of armbian distro and kernel where this works "out of the box" to use on other orangepi boxes I'm setting up

Armbian is a community project. If you made something that is generally usable, push it upstream and that functionality becomes a default. https://docs.armbian.com/Process_Contribute/

[arhi]

On 12/30/2017 at 8:02 AM, Igor said:

Armbian is a community project. If you made something that is generally usable, push it upstream and

Yes, but the "fix" is part of the OPI library not part of the Armbian and it's rather simple, just adds arbitrary delay (500ms) before accessing direction file.. problem is, while this works, it's an ugly patch ... for me it works but the lib accesses few different files in sequence and it's possible with different load, different sd card, different cpu the other files might also be a problem so in theory there should be some test of permissions all of those sysfs files are accessed with some configurable timeout.. but since python is really not my strong suit I just hacked it to get it to work for me.. I would never push a hack like this upstream...

 

now this type of race condition is not something I had with rpi and I heard some kernel configs for armbian are different and might work so hoped there's a "ready" solution .. it's anyhow the library issue not the armbian issue in the first place.

 

anyhow thanks for those links will check them out asap

 

p.s. happy new 2018

 

--- 1/OPi/GPIO.py
+++ 2/OPi/GPIO.py
@@ -239,6 +239,7 @@ Methods
 """
 
 import warnings
+import time
 
 from OPi.constants import IN, OUT
 from OPi.constants import LOW, HIGH                     # noqa: F401
@@ -358,6 +359,7 @@ def setup(channel, direction, initial=None, pull_up_down=None):
             else:
                 raise e
 
+        time.sleep(0.5)
         sysfs.direction(pin, direction)
         _exports[channel] = direction
         if direction == OUT and initial is not None: