ofxGPIO Update [debian stretch]

I solved a small bug in ofxGPIO met on debian stretch.

1 Like

I’ve been maintaining a log of my pursuits so here’s more details of ofxGPIO.

I tried to get ofxGPIO to work without OF as well and it didn’t work. Error log below.

/usr/include/c++/6/system_error:200:3: note:   no known conversion for argument 1 from ‘std::ifstream {aka std::basic_ifstream<char>}’ to ‘const std::error_code&’
/usr/include/c++/6/system_error:274:3: note: candidate: bool std::operator<(const std::error_condition&, const std::error_condition&)
   operator<(const error_condition& __lhs,
/usr/include/c++/6/system_error:274:3: note:   no known conversion for argument 1 from ‘std::ifstream {aka std::basic_ifstream<char>}’ to ‘const std::error_condition&’
Makefile:14: recipe for target 'all' failed
make: *** [all] Error 1

So this might not be a oF related issue but more specific to Stretch in some other way. Spoke to Dario Longobardi on Facebook too (he’s made the ofxGPIO addon), he said he would investigate.

Just heard from Dario on Facebook that ofxGPIO is up and running on Stretch. Time for some Stretch tests soon and maybe I update my project from running on Jesse to Stretch if everything tests out well.

1 Like

Hey @ayruos,
Thanks for posting and wow many many thanks to @kashim for updating the ofxGPIO add-on! I’ll see if I can try it again on Stretch before the holidays. I wonder if we should start a new thread for this topic if we have more discussion about it? Anyhow thanks again for the update and it will be fun to see how it goes.

Edit: I did get ofxGPIO to compile in Stretch.
Edit: example-apa102-ledstrip compiled in Stretch, but the leds did not light up. My led hardware appears to be OK as the leds came on with a verification run in Jessie
Edit: in my own app, the MPR121 (I2C) appears to be working with Stretch, though I did get a runtime notification that the app failed to set the direction of GPIO4, which I use as an interrupt from the MPR121 IRQ pin. This app runs without this notification in Jessie.

Hi @TimChi

it could be a permissions problem, are you sure that your user is able to read and write
in the /dev/ folder for SPI and in the /sys/ for IO pin? try running your programs with sudo
for superuser privileges… if problem persists, create a issues on the git.

good day

did you run the app as sudo? ofxGPIO apps don’t write to the GPIO for me unless I run them as sudo. Confused the hell outta me for a while!

I had high hopes that running example-apa102-ledstrip with sudo would light up the leds in Stretch, but alas it didn’t. The example complies though, and indicates that the SPI is setup when it runs. I’ll open an issue on the ofxGPIO GitHub page. I’ve not had to use sudo with either the example or my own app with Jessie, even though user pi can not create files in /dev/. Maybe this is because I use sudo when I run the compileOF.sh script. But as @ayruos pointed out, sudo may be necessary depending on how Raspbian is setup for users and permissions.

I saw your issues, i keep you updated.

for permissions there are several ways to solve this:

sudo chmod -fR 777 /sys/class/gpio/


sudo chown -fR pi:pi /sys/class/gpio/

or add user pi to the group gpio:

sudo usermod -aG gpio pi
sudo chgrp gpio /sys/class/gpio/export
sudo chgrp gpio /sys/class/gpio/unexport
sudo chmod 775 /sys/class/gpio/export
sudo chmod 775 /sys/class/gpio/unexport

however these methods allow you only export and unexport
if you want to change permissions dynamically for all the nodes generated GPIOX
you have to add a small udev rule (/etc/udev/rules.d/):

SUBSYSTEM==“gpio”, ACTION==“add”, PROGRAM="/bin/sh -c ‘chown -R pi:pi /sys%p’"

1 Like

Anything new on this topic?

Having run into this issue myself, here is how i resolved it.

I first tried all of kashim’s recommendations regarding chmod/usermod/udev, but none of them worked for me. After some digging, it appears that we need to wait about 100ms after exporting a pin before trying to access it. I think this has to do with udev rules not being applied immediately but it feels like the answer is probably more complicated than that. Just to clarify, there should already be some default udev rules regarding the gpio and permissions and from what i can tell there was no need to add kashim’s udev rule. That being said, if this doesnt work for you, you may need to at least add pi to the gpio group using:

sudo usermod -aG gpio pi

here is the code that worked for me:


I found references to this issue here under Roman Savrulin’s answer: https://stackoverflow.com/questions/30938991/access-gpio-sys-class-gpio-as-non-root

UPD please beg in mind that when you export some GPIO via sysfs, you should wait for udev rule to fire and complete before you get desired access rights. The thing that worked for me was sleep about 100ms before trying to access GPIO files.

I also found some hints regarding a race condition with udev here:

I hope this helps someone, and would like to thank kashim for the wonderful work on ofxGPIO.

1 Like