We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

Omega 2 C++ GPIO management library

  • 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:


    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.

  • @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 šŸ˜‰

  • @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 šŸ˜‰

  • 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, 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!

Looks like your connection to Community was lost, please wait while we try to reconnect.