Jump to content

libgpiod-extra "New GPIO Interface for User Space"


Recommended Posts

I have deleted this project please see https://github.com/sgjava/userspaceio as it covers I2C, SPI and serial in addition to the new GPIOD.


I posted instructions over in the H2/H3 forum, but my build project for libgpiod should work on any Armbian mainline distribution, so I'm posting a link here to my Github site. The install is scripted and comes with the ability to generate Python and Java bindings. libgpiod replaces the deprecated sysfs since kernel 4.8. libgpiod-extra project aims to make cross platform/cross language GPIO development a reality. No more one off hacked up Wiring Pi or RPi.GPIO for each SBC.


I need help testing across multiple SBC platforms. Just follow the instructions on https://github.com/sgjava/libgpiod-extra.


Verified on:

  • NanoPi Duo (H2+)
  • NanoPi Neo+ 2 (H5)


import time
from argparse import *
from libgpiod.libgpiod import *

parser = ArgumentParser()
parser.add_argument("--chip", help="GPIO chip number (default 0 '/dev/gpiochip0')", type=int, default=0)
parser.add_argument("--line", help="GPIO line number (default 203 IOG11 on NanoPi Duo)", type=int, default=203)
args = parser.parse_args()
consumer = sys.argv[0][:-3]
chip = gpiod_chip_open_by_number(args.chip)
# Verify the chip was opened
if chip:
    line = gpiod_chip_get_line(chip, args.line)
    # Verify we have line
    if line:
        # This will set line for output and set initial value (LED on)
        if gpiod_line_request_output(line, consumer, 0) == 0:
            print "\nLED on"
            # LED off
            gpiod_line_set_value(line, 1)
            print "LED off"
            print "Unable to set line %d to output" % args.line
        print "Unable to get line %d" % args.line
    print "Unable to open chip %d" % args.chip


import java.util.concurrent.TimeUnit;

import libgpiod.LibgpiodLibrary;
import libgpiod.LibgpiodLibrary.gpiod_chip;
import libgpiod.LibgpiodLibrary.gpiod_line;

public class LedTest {

	public static void main(String args[]) throws InterruptedException {
		// Default GPIO chip (NanoPi Duo chip 0)
		int chipNum = 0;
		// Default line
		int lineNum = 203;
		if (args.length > 0) {
			chipNum = Integer.parseInt(args[0]);
			lineNum = Integer.parseInt(args[1]);
		// Use to debug if JNA cannot find shared library
		System.setProperty("jna.debug_load", "false");
		System.setProperty("jna.debug_load.jna", "false");
		// Use class name for consumer
		final String consumer = LedTest.class.getSimpleName();
		// Load library
		LibgpiodLibrary lib = LibgpiodLibrary.INSTANCE;
		final gpiod_chip chip = lib.gpiod_chip_open_by_number(chipNum);
		// Verify the chip was opened
		if (chip != null) {
			final gpiod_line line = lib.gpiod_chip_get_line(chip, lineNum);
			// Verify we have line
			if (line != null) {
				// This will set line for output and set initial value (LED on)
				if (lib.gpiod_line_request_output(line, consumer, 0) == 0) {
					System.out.println("\nLED on");
		            // LED off
		            lib.gpiod_line_set_value(line, 1);
		            System.out.println("LED off");
				} else {
					System.out.println(String.format("Unable to set line %d to output", lineNum));
			} else {
				System.out.println(String.format("Unable to get line %d", lineNum));
		} else {
			System.out.println(String.format("Unable to open chip %d", chipNum));


Link to comment
Share on other sites

Donate and support the project!

OK, finally watched the video and it all makes sense now (I emailed the author to confirm the use of the consumer arg). The Python wrapper I generate is solid now. I needed to add a couple ctypes Structures to an include file and it works on 32 bit and 64 bit platforms. I've given up on sysfs for good!


ledtest.py https://github.com/sgjava/libgpiod-extra/blob/master/python/ledtest.py now accepts command line arguments, so it's easy to run on any SBC. I shows you how to safely open the GPIO chip and get the line without suffering a Segmentation Fault! Once I'm done't with the basic demos I'll work on using threads in Python to handle non-blocking callbacks. I kind of like the idea of handling threads in the bindings instead of using C pthreads. Then you have more control.

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...