5

I have an powerpc board with 3.2 kernel running on it. Accessing gpio with sysfs works as expected e.g.

> echo 242 > /sys/class/gpio/export
> cat /sys/class/gpio/gpio242/value
>  1

Is there no API to direct access gpio pins from user space? Must I deal with the text based sysfs interface?

I seach for something like: gpio_set(int no, int val);

Thanks Klaus

Klaus
  • 24,205
  • 7
  • 58
  • 113
  • Try [this](http://foxlx.acmesystems.it/?id=22) or [this](http://www.mjmwired.net/kernel/Documentation/gpio.txt). – Piotr Praszmo Jun 15 '12 at 13:40
  • Have you tried any of the any of the answers here recommending `libgpiod` - or the `gpioset` "user tool"? Just curious because I've tried it on my Raspberry Pi, and it is beyond bad - well into the horrible range - at least wrt `gpioset` –  Mar 07 '22 at 05:59

4 Answers4

2

Edit: sysfs direct access for GPIOs is deprecated, new way is programmatic through libgpiod

sysfs is the lowest level at which you will be able to manipulate GPIO in recent kernels. It can be a bit tedious but it offers several advantages over the old style API:

  • No ugly ioctl
  • Can be scripted very easily (think startup scripts)
  • For inputs, the "value" file can easily be poll-ed for rising/falling/both edges and it will be very reactive to hardware interrupts

I have no example code at the moment but when accessing them through C code, I often implemented a very simple wrapper manipulating file descriptors and having variations of the following interface:

int gpio_open(int number, int out); /* returns handle (fd) */
int gpio_close(int gpio);
int gpio_set(int gpio, int up);
int gpio_get(int gpio, int *up);
int gpio_poll(int gpio, int rising_edge, int timeout);

From then, the implementation is pretty straightforward.

Léo Germond
  • 720
  • 8
  • 18
2

GPIO access through sysfs has been deprecated since Linux 4.8.

The new way for user space access is through libgpiod, which includes a library to link with (obviously), as well as some tools which can be run from the command line (for scripting convenience). Notably, GPIO lines are referenced with the line name string rather than an integer identifier, like with sysfs. E.g.

gpioset $(gpiofind "USR-LED-2")=1

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README

Jetski S-type
  • 1,138
  • 2
  • 16
  • 32
  • Please read the second example in the link you referenced, and explain what it means --- please. I think the documentation is as bad as the code. Have you actually tried to use this? If so, please let me know which platform you got your command to run successfully (meaning the "USR-LED-2" line remains HI/1. If it works on your pltform as you say it does, I'm switching to your platform. –  Mar 07 '22 at 05:52
  • @Seamus, late, but I indeed have had that working. There may be multiple gpio groups/hardware, hence gpiochip0, gpiochip1, etc. Within each group there is a set of lines, 0 to n. So a gpio line is addressed as "gpiochip1 23". You can play around with gpiodetect and gpioinfo to get an overview of what gpio hardware there is. – Jetski S-type Jul 26 '22 at 02:56
1

Once you have the devices created in the vfs tree, you can open them like typical files assuming you have a driver written and have the correct major and minor numbers assigned in the makedev file that creates the gpio pins on the vfs tree.

San Jacinto
  • 8,774
  • 5
  • 43
  • 58
-2

Every GPIO is memory mapped as a register, so you can access to it through /dev/mem. See here. If you want to access directly to a GPIO you have to work at kernel space level

b0b0b
  • 134
  • 1
  • 8
  • 3
    Sorry: That is wrong! Linux provide a well defined driver interface for all IOs. It provides also access to IOs which are not accessed via registers on the core chip. That enables you also to access pins on "extender" chips. If you read my question, you see that there is a driver interface. The question is not how to access a register mapped pin from kernel driver. Instead the question was how to access the driver without file system mapping. – Klaus Oct 29 '13 at 08:45
  • 1
    Memory mapped is an alternative to access gpio instead of sysfs – b0b0b Oct 29 '13 at 12:54
  • 1
    Physical memory access is neither a good or even tolerable way of accessing any hardware component, it relies on the code making very strong assumption about the target it is running on. What happens if the code is buggy or must be ported ? – Léo Germond Mar 06 '15 at 14:28