Current proper way to interface GPIO from C code?

Question

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.

• Seamus: Yes, I support your comment re Kafkaesque. +1. :)
• John U: @KentGibson yes I know, the point was more that the internet suggested they'd come ready-installed on recent builds but weren't, so it's an additional thing to install if you want your code to run rather than being compatible out of the box.

Answer 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!

• John U: 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.