Omega 2 C++ GPIO management library

Patryk Wychowaniec

Hey, fellow Omega programmers

I've been working on a PCD8544 driver last few days and thus I had to control GPIO pins from inside my C++ application - I didn't found any generic library for Omega 2 and so I've decided to roll my own one:

https://github.com/Patryk27/Omega2-GPIO

I've taken the mechanics from the fast-gpio tool and refactored it so it was down to two files and Arduino-like nomeclature (it has pinMode, digitalWrite, digitalRead and shiftOut).

I hope it gets useful for someone

I've included one simple example there and maybe tomorrow (depending on my free time) I'll post my PCD8544 driver - it will most likely be more useful than just this GPIO toggling tool, but it's always something to start with.

luz

@Patryk-Wychowaniec That's a nice and easy to understand library, thanks for sharing!

A while ago, I had the need for controlling digital inputs, outputs and even some PWMs (aka "analog" out) in an abstracted way so it would run on different Linuxes and with GPIOs as well as i2c and spi port extenders. So I went for using /sys/class/gpio, which is not as fast as the /dev/mem, but not specific to a certain SoC. The code though is part of a bigger library called p44utils with some dependencies and concepts that might come into your way of doing things. On the other hand, it has quite a lot to offer for writing complex, SoC target independent automation daemons in C++, so it might be useful in some cases.

In general, I wonder how much the speed difference is between /dev/mem/mmap vs. /sys/class/gpio actually is, when the value file is held open. Because from an architectural point of view, /dev/mem is a hack and a security problem - I'd like to have more firm ideas about the trade-offs for either choice - but haven't found the time for setting up proper measurements myself so far

Patryk Wychowaniec

@luz: Thanks for the p44utils link, looks interesting I'll take a more thorough look as soon as I return from work.

The aspect of speed difference between direct memory accessing and using the /sys/class/gpio is also intriguing (it'd seem like /dev/mem should be faster but who knows).

I must say that I completely forgot about the /dev/mem alternative when writing my library and now I can't wait untill I get to my Omega back so that I can do some benchmarks

Claude Robitaille

Hi,

on the topic of doing a generic gpio support library; I am looking for a solution that is highly portable. To that effect, the "native" Linux kernel gpiolib (why did they use the lib suffix? For me a lib is something userland, not kernel....) is a good thing. This http://lxr.free-electrons.com/source/Documentation/gpio/sysfs.txt describes the sysfs API. (Note that some other driver/system also uses the sysfs interface but differently, the "files" are not the same. Notably the Next Thing's CHIP is significantly different).

My question relates to the interrupt driven GPIO input. Or activity detection. I would like to get the time of the input event; and I would like to be as precise as possible. I saw in the kernel code (gpiolib, at http://lxr.free-electrons.com/source/drivers/gpio/gpiolib.c#L708) that the kernel does register the time of the event. I even see pass it up (http://lxr.free-electrons.com/source/drivers/gpio/gpiolib.c#L620) but I do not see or understand how to access this information from the userland. The documentation regarding /sysfs/class/gpio is silent on this. Anyone knows the answer?

Thanks

Brad Hontz

Thanks, be attempting a simple DHT22 project with the Omega 2+ and haven't gained any traction as of yet, hoping to piggy back on your work. Appreciate your sharing!