MicroPython on linux boards, libgpiod can be a good cross-platform GPIO interface

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
Post Reply
User avatar
adafruit
Posts: 12
Joined: Sun Oct 30, 2016 11:56 pm
Location: NYC
Contact:

MicroPython on linux boards, libgpiod can be a good cross-platform GPIO interface

Post by adafruit » Mon Nov 26, 2018 4:40 pm

With the interest in running MicroPython on linux boards, libgpiod can be a good cross-platform GPIO interface.

Earlier this year there was the announcement of mainline kernel integration of libgpiod (2/10/2018).
https://archive.fosdem.org/2018/schedul ... for_linux/

libgpiod is intended to be a fast kernel-level-supported method for writing/reading/monitoring GPIO pins on various linux boards, replacing the two main methods we see these days: sysfs file pokin’ and devmem twiddling.

With sysfs style control, you end up with files such as /sys/class/gpio/gpio16 (for pin #16) that you can write and read from to set direction and read values. it works ok, and is very easy to use with shell scripts, but is clunky from C or python, and is slow and incomplete (for example, pullup/down’s are not supported).

With devmem twiddling, you open up a file point directly to chip memory and start poking and prodding at the registers directly, somwhat similar to older computer’s ‘peek’ and ‘poke’ commands, or the microcontroller style PORTB |= 0x01 . Benefits? it is heckin’ fast. Downsides are that its a horrible idea to poke into memory, and you end up having to make register maps for each processor and revision because the registers move around. You can see some example code here for our DHT driver for Raspberry Pi
https://github.com/adafruit/Adafruit_Py ... /pi_mmio.c

…and then this different code for a BeagleBone (cause the register map is different)
https://github.com/adafruit/Adafruit_Py ... bbb_mmio.c

As you can tell, this quickly becomes hard to support and its dangerous – you need to be running as root and its incredibly easy to accidentally poke the wrong location.

With more linux boards coming out with GPIO (there’s probably 4 more released since we wrote this post) – having a consistent, reliable, complete GPIO interface is pretty important to avoid icky unmaintainable code. So we’re pretty psyched about libgpiod. From our experiments, its much much faster than sysfs. Its not as fast as mem twiddling, but that’s not too surprising, there’s still kernel messages and error checking done. A Pi 3 got us 400Khz pin output toggles in a loop in C, 100KHz in Python examples, and that’s pretty good for bitbanging. (For SPI or I2C, use the hardware peripherals, they can go multi-MHz and can be shared between processes!)

We’ve started with a basic ‘collect gpio pulses and store them in a circular buffer’ program, written by Brennen Bearnes:
https://github.com/adafruit/libgpiod_pulsein

This is basically code that will replace our Python DHT driver, and has the benefit of being forward compatible with any other Linux board that runs a 4.8+ kernel. We’ll slowly be replacing other CircuitPython code to use libgpiod, so that we can have broad support for CircuitPython on a Raspberry Pi, BeagleBone or Onion.io.

Image

There’s not a lot of libgpiod code out there, and libgpiod doesn’t come stock on Linux distros yet which may be why its taking a little while to catch on. There’s bindings for C and Python. Here’s a script that can help you get started by compiling it for you
https://github.com/adafruit/Raspberry-P ... ibgpiod.sh

If you have any controlling votes in a distro, please have libgpiod available thru your package manager! The latest code is here, and as you can tell there’s a lot of active development 🙂
https://git.kernel.org/pub/scm/libs/lib ... gpiod.git/

Post Reply