Anyone know how to access RasPi GPIO without sudo?

Does anyone here know how to access /dev/mem as a normal user?

Don't do that.  There's a device driver for the gpios that can be made to expose them under /sys/class/gpio. Access is comparitively slow, but at least it's safer than messing with /dev/mem

You can find documentation for 'gpiolib' towards the end of Documentation/gpio.txt in any recent linux kernel source tree. There you'll find out how to export particular gpios to userspace. 

Note that you likely still need to chown some files under /sys/class/gpio to allow user access after exporting them as root. Roger is quite right on the security model - consider that gpio's will often be connected to something that sensitive and you should understand why you normally need root to access them.

Here's a trivial example in bash

echo 55 > /sys/class/gpio/export

echo out > /sys/class/gpio/gpio55/direction

echo 1 > /sys/class/gpio/gpio55/value

however note that 55 isn't a valid value unless you've added a gpio expander like the mcp23008 I'm using, and recompiled the kernel appropriately.

selsinork wrote:

 

Does anyone here know how to access /dev/mem as a normal user?

Don't do that.  There's a device driver for the gpios that can be made to expose them under /sys/class/gpio. Access is comparitively slow, but at least it's safer than messing with /dev/mem

Thank you for the suggestions, but I don't want slow.  This is more out of principle (what others call "pig-headedness") than any real need for my LEDs to blink one million times faster than my eye can resolve.  I figure, hey, it's my computer and what's the point of having memory-mapped I/O if I can't access it as memory?  If you're going to go through several layers of condoms to protect your GPIOs, you might as well be using a mainframe and where's the fun in that?

OTOH, I do accidentally delete files from time to time and I'd hate to accidentally delete a system file or directory while being root, so I don't like to stay root for more milliseconds than necessary.  OTOH, I find I've almost never screwed up a system by accessing the wrong memory address, probably because I'm more careful doing the latter.  Back when I was programming PDP-11s, I caused any number of bus errors but never accidentally wrote bad words into the hard drive control registers.

So here's something else I tried: I changed the permissions on /dev/mem to the dreaded 666 to allow anyone to access it.  That didn't work.  I also tried changing permissions on /dev/mem to 660 and added myself to the "kmem" group.  That didn't work either.  I'm a little nervous about changing the ownership of /dev/mem to myself since I'd worry that root might want to be the owner somewhere else.

selsinork wrote:

 

Does anyone here know how to access /dev/mem as a normal user?

Don't do that.  There's a device driver for the gpios that can be made to expose them under /sys/class/gpio. Access is comparitively slow, but at least it's safer than messing with /dev/mem

Thank you for the suggestions, but I don't want slow.  This is more out of principle (what others call "pig-headedness") than any real need for my LEDs to blink one million times faster than my eye can resolve.  I figure, hey, it's my computer and what's the point of having memory-mapped I/O if I can't access it as memory?  If you're going to go through several layers of condoms to protect your GPIOs, you might as well be using a mainframe and where's the fun in that?

OTOH, I do accidentally delete files from time to time and I'd hate to accidentally delete a system file or directory while being root, so I don't like to stay root for more milliseconds than necessary.  OTOH, I find I've almost never screwed up a system by accessing the wrong memory address, probably because I'm more careful doing the latter.  Back when I was programming PDP-11s, I caused any number of bus errors but never accidentally wrote bad words into the hard drive control registers.

So here's something else I tried: I changed the permissions on /dev/mem to the dreaded 666 to allow anyone to access it.  That didn't work.  I also tried changing permissions on /dev/mem to 660 and added myself to the "kmem" group.  That didn't work either.  I'm a little nervous about changing the ownership of /dev/mem to myself since I'd worry that root might want to be the owner somewhere else.

Thank you for the suggestions, but I don't want slow.  This is more out of principle (what others call "pig-headedness") than any real need for my LEDs to blink one million times faster than my eye can resolve.  I figure, hey, it's my computer and what's the point of having memory-mapped I/O if I can't access it as memory?  If you're going to go through several layers of condoms to protect your GPIOs, you might as well be using a mainframe and where's the fun in that?

At this point I'll respectfully suggest you're looking at it the wrong way. You have two conflicting requirements, you should pick one and be done with it. Either run as root and accept that you can delete files either by using 'rm -rf /' or by scribbling the wrong stuff into /dev/mem, or run as a normal user and accept those limitations.

You should also realise that the same gpio driver that you don't want to use 'owns' the memory locations you want to manually write to and as such you can't prevent the kernel from changing those locations behind your back. (you could try compiling out the gpio driver, but as the sdcard driver depends on it you'll have other problems).

This is part of the compromise you sign up to by running linux as your OS. You are of course free to do other things by not running linux, going for a bare metal approach and treating the Pi like an arduino.

I also agree with the sentiment that it's your computer and you should be able to do what you like. For that reason, especially on something like the Pi, I suggest simply running as root and forgetting about the 'problem' altogether     I have effectively just one user on my Pi - root (there are a few more, but no others can login and they're only there to keep stuff that expects them happy)