preferred gpio and i2c access from user space under Angstrom

GoogleGroups
1

Hi All-

I have an application which will need to control some external devices via i2c and gpio’s from user space. It appears that this can be done with mmap to talk to the HW registers directly, or by using sysfs or for i2c using i2ctools which has some reliance on smbus which is broken in some kernels?

Is there any guidance on the “preferred” (meaning unlikely to be broken by future kernel changes) methods for these with some clear example code?

Thanks,
Dan

2

Hi All-

I have an application which will need to control some external devices via
i2c and gpio's from user space. It appears that this can be done with mmap

  I2C GPIOs.

I2C and GPIO are acronyms, and thus should be capitalised. Also 's means
something belonging to a GPIO, not a set of GPIOs.

to talk to the HW registers directly, or by using sysfs or for i2c using
i2ctools which has some reliance on smbus which is broken in some kernels?

mmap() of hardware which has a real driver attacehd to it is always a bad
idea.

I2C defines a /dev node than can be opended and ioctl()s can be used to
transfer data to/from a device. Documentation/i2c/dev-interface shows
some examples of how this can be done.

newish kernels export GPIOs to userspace by a sysfs interface, which is
documented in Documentation/gpio.txt.

3

i2c is working perfectly fine using i2ctools from userspace - I’ve certainly not had any issues… You can use /sys/class/gpio from userspace for GPIOs - again no issues here. Both of these interfaces have been stable within the kernel for quite some time.

These are the “generally preferred” methods of accessing hardware buses/GPIOs… The whole point of an operating system is to abstract the hardware away from application software and end users. While you can access the hardware registers with mmap() you should avoid this unless the kernel drivers simply don’t do what you need. Then you should probably tweak the kernel drivers rather than mmap()ing…

There are plenty of examples of using GPIO and i2c in this forum’s archives or via Google. You can view the i2c-tools source code online here: http://www.lm-sensors.org/browser/i2c-tools/tags/V3-0-0/tools to see how it uses the files in /dev/i2c.

If you are feeling bold and decide to write a linux kernel device driver for your hardware (its not actually that hard :slight_smile: then you should look here: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=tree;f=Documentation/i2c;hb=HEAD

For GPIO examples this thread has a lot of useful information: http://groups.google.com/group/beagleboard/browse_thread/thread/db4accfabf02d986/c623a16637625685

Since using the mmap() route is such a bad idea I’m not even going to find a link to any example code… but if you really do need it then Google will find it pretty quick…!

4

Hi Michael-

Thanks. The user mode app I’m writing I’m building with openembedded by placing a directory in /recipes which contains a .bb file and my sources are in a /files directory. But I’m having trouble getting the build system to pick up the right version of i2c-dev.h when it encounters:

#include <linux/i2c-dev.h>

Do you have an example .bb file that’s working for you for building code using i2ctools?

Thanks,
Dan Wright

5

Sorry I don’t use BitBake for my own projects… :slight_smile: I would try building a simple standalone app first to work out what the include path should be first and then take that to BitBake…

6

I have a similar need, but I need more efficient access to the GPIO.
I have tried the program
linked to in this thread that uses the /sys/class/gpio system file,
but it takes about 120 us to
flip a GPIO bit. (rewind, strcopy, fwrite, fclose)

This overall project is to port an X86, PC program that runs CNC
machine tools
via the parallel port. The PC parallel port can do byte transfers in
under 1 us, with a single
CPU instruction (INB, OUTB). (There may be driver overhead to
virtualize this from the user environment,
but it is pretty efficient.) This program normally runs under rt-
linux (old) or rtai (more recent).
But, I also have diagnostic and test program that run in user-space
for ease of testing.

So, does anyone know where there are examples of using more direct
means to control GPIO
pins my memory-mapped means or a far more efficient driver?

Thanks,

Jon

7

Hi Jon,

Here's a useful GPIO thread, including an example of direct GPIO
register access using mmap(). There's lots of dicussion of the
tradeoffs and hazards of direct GPIO register access versus going
through an operating system.

http://groups.google.com/group/beagleboard/browse_thread/thread/ff6f6aa843afd950

Hope this helps,
John