1

I've done a lot of googling and it's only confused me further; the old /sys/class/gpio way is deprecated and there's a rag-tag bunch of libraries that appear to have sprung up, none of which have much of an air of officialdom about them, the Raspberry Pi site only mentions the Python GPIOZero method as being the One True Way with nothing about C or command line interfaces to GPIO.

Just for example, running down the list of eLinux Raspberry Pi GPIO code samples for C:

  • Direct register access behind the kernel's back is a no-no
  • WiringPi is dead
  • SysFS is deprecated
  • bcm2835 library is not official and is using direct register access (and I'm using CM4 so BCM2711)
  • piGPIO/lgpio/rgpio appears to be unofficial / potentially doing the same naughty register access / I've read comments suggesting it should not be used for production code (although that was 50 tabs ago now) and "The C library is not conventionally accessible." which does not fill me with confidence.
  • ...that's it.

There also appear to possibly be two different libraries both calling themselves libgpiod/lgpio or some variant of.

Although one libgpio appears to be part of the newer kernels and thus the "favourite" so far, it doesn't seem to get mentioned in any Raspberry Pi docs / tutorials, almost as if figuring out how it should be used on a RPi is left as an exercise for the user.

What have I missed?

Edit: libgpiod seems to be the new way but not present on my Pi4 running Bullseye (gpiodetect etc. fails command not found, C examples fail with <gpiod.h> no such file) despite some suggestions online that it's been installed by default in the last few releases (since Bookworm if my reading of this thread is correct), plus a reference to using /dev/gpiochip made by Joan in that thread, it's unclear to me (and I haven't found any good looking documentation) that suggests I could do basic GPIO through the /dev/gpiochip filesys as a reliable & portable solution.

EDIT2: If I install libgpiod-dev from Bullseye repos I can then use the command line tools, but the installed version (1.6.2-1) is somehow too new for older examples to work but too old for the current (V2.x) examples to work... this all feels somewhat Kafka-esque.

John U
  • 181
  • 11

2 Answers2

1

The current "proper" way is libgpiod (a poor choice of name as it is not a daemon) although the current version in Bookworm is (at least) 3 years old, poorly documented and has absolutely NO example code.

The python version gpiod does at least work (although the documentation is rudimentary and it is glacially slow). See https://raspberrypi.stackexchange.com/a/145544/8697

There has NEVER been any officially supported library (except sysfs - which still works for PWM etc, but not gpio) which is why there are other libraries.

The closest to any official GPIO library is python gpiozero, which in its latest incarnation uses lgpio as the underlying engine.

Joan's lg libraries (both c & python) are a user friendly wrapper around the underlying gpiochip system and is highly functional but it is possible to write code c which directly uses the gpiochip interface.

Incidentally most of the existing GPIO libraries still work on Bookworm - they just don't support the new hardware used on Pi5. It is possible to directly access Pi5 RP1 hardware (although the mechanism has changed - this is used in the pinctrl application) so I suspect it is only a matter of time before libraries doing this are produced - I am contemplating this myself, but wonder if it is worth the effort.

pinctrl DOES allow command line interface (at least to set Input, Output and pulls, but not other functions which are available through the kernel) and is documented.

You have misquoted my comment "The C library is not conventionally accessible" which relates to pigpiod which is only accessible through a socket and pipe interface not as a conventional linked library but it is still highly functional, just not as fast as direct register access.

If you write c code using the socket interface pigpio does work but for Pi5 lgpio seems the best option at the moment.

Many of the links in your question are old >4 years. Things change!

Milliways
  • 59,890
  • 31
  • 101
  • 209
  • 1
    You might want to point out that pinctrl is intended as a debug tool and will contend with the kernel drivers and should only be used with extreme care. As stated in its own help - "only use it if you know what you are doing and at your own risk!". The libgpiod tools are a safer option. – Kent Gibson Mar 26 '24 at 13:28
  • @KentGibson we have exchanged views on this before. Until or unless there is proper documentation e.g. a man file and working examples libgpiod is a lemon. Most Pi are single user systems performing a single task so what "risk" are you concerned about - something may not work; in which case you try again. Anyone writing code to perform multiple tasks needs to exercise caution - which was the norm when everything was in assembler. – Milliways Mar 26 '24 at 13:44
  • 1
    I don't remember you. The number of users is not relevant - the number of active threads is the issue, and Linux is inherently multi-threaded. The risk is that contending writes to hardware registers will result in a hardware state other than either intend, with unknown consequences. You think the pinctrl author would add that warning if pinctrl was guaranteed harmless? The libgpiod tools have man files. libgpiod v2 includes examples. We're not talking writing in assembler, but about end users being casually encouraged to use tools with the potential to break their hardware. – Kent Gibson Mar 26 '24 at 14:01
  • Thanks for the response - the comment about "not conventionally accessible" seemed to suggest my code would become a daemon, which is not necessarily convenient and makes me worried that it could cause issues or weird interactions. The links may be old but I'm struggling to find anything that looks official / reliable that isn't the GPIOZero (python) docs and shows me sensible basic examples of how to use GPIO pins on a newer Pi OS. I am trying to avoid hacks with this as it needs to be future-proof, I've already been tripped over by the whole Python setup changing. – John U Mar 26 '24 at 14:39
  • @KentGibson if Debian/Raspberry Pi OS implement v2 it may be usable but this is likely to be in 2 years at earliest. – Milliways Mar 26 '24 at 21:10
  • It is package, not implement. Where does the 2 year estimate come from? If it is really going to take them that long then I might consider creating some deb packages in the interim. It can always be installed from source, it isn't that difficult. Even the libgpiod v1 tools already packaged in Pi OS are a viable alternative to pinctrl. And I agree the libgpiod name isn't the best, particularly the gpiod package, but renaming at this point is just going to cause even more confusion. – Kent Gibson Mar 27 '24 at 00:05
  • @KentGibson Debian normally does not make major changes until a new release - Due 2025. libgpiod does not provide a command line interface that I am aware of - which the OP asked. – Milliways Mar 27 '24 at 00:29
  • The command line tools are packaged in the aforementioned gpiod package. On the Raspberry Pi forum the Pi guys indicated they were looking at packaging libgpiod v2 independently of Debian - though not sure where they are at with that. – Kent Gibson Mar 27 '24 at 00:46
1

Well... Yes - I feel "rag-tag" does sum up the situation fairly well for some of the libraries you've mentioned. As Milliways has pointed out, we've been hearing for years that sysfs is on the way out, and libgpiod is "THE FUTURE". I've spent some time with libgpiod, and if that is indeed the future, then give me "Planet of the Apes" instead. :)

Just a couple of points to make; then I'll butt out, and leave this to you for a decision:

  1. Despite rumors to the contrary, wiringPi is not "dead". In fact, they seem to be energized now, and making progress. They've declared some ambitious objectives, but they have just released a ver 3.2 that works w/ both bullseye & bookworm. I've not been compelled to try the new release yet as all of my systems (except the RPi5) are bullseye. Disclosure: I'm a long-time fan of wiringPi.

  2. pinctrl is very interesting. You can read the understated capabilities on the GitHub page. I don't have a lot of experience with it, but having used it a couple of times for small projects on my RPi5 I found it to be spare, rational and effective. Another thing I found appealing about pinctrl is its extensibility; i.e. it's split into a library and separate client app - but in a far more rational way than libgpiod. pinctrl also eschews the sysfs interface, and I've wondered if pinctrl is Raspberry Pi's "insurance" policy against what appears to be the "software Hindenburg" that is libgpiod. Disclosure: I've tried both the "stock" version (1.6), and the latest version (2.1 last I checked) of libgpiod. I believe libgpiod's proponents are 'whistling Dixie' - but that's just my opinion.

Seamus
  • 21,900
  • 3
  • 33
  • 70
  • The GPIO character device is the official GPIO userspace interface for Linux, and libgpiod is the official C library for that. Neither are going away anytime - even if they were deprecated today they would hang around for years - sysfs was deprecated about 8 years ago and only now is it finally being removed. pinctrl leaves you at the mercy of the Pi devs - how is that working for you so far? – Kent Gibson Mar 27 '24 at 00:59
  • wiringpi.com is a single page that reads: "This is wiringpi.com. As of the end of 2023, you'll not find anything here anymore. It's gone." that does not fill me with reassurance that I want to base my project on it, however the repo you linked is certainly more positive... just a shame people can't join things up so Gordon's website points to the new team or something. – John U Mar 27 '24 at 10:04
  • @JohnU: Gordon (original author of wiring pi) owns wiringpi.com, and apparently won't release it. He was "pre-Git". There are stories about Gordon that have been floating around for years. I don't know Gordon at all, but at one time he had a much more negative message on his website than the one you saw. I think he may have invested too much of himself in wiringPi. It all went into the code & nothing was left for the people using it. But of course it's you who has to make the decision wrt your project. – Seamus Mar 27 '24 at 19:00
  • That's a shame, but certainly wouldn't be the first case of that sort of thing happening. – John U Mar 28 '24 at 09:31
  • Kent: I'm not being snarky, who decides the "official userspace interface" for Linux? Is it kernel.org, GNU, Ubuntu, Raspberry Pi Foundation? I though "Linux" was an unstructured world where different distributions decide what they want to ship and users decide what they want to use for a variety of reasons. – Chad Farmer Mar 30 '24 at 05:16