danjperron
Posts: 4667
Joined: Thu Dec 27, 2012 4:05 am
Location: Québec, Canada

Re: Raspberry Pi 5 GPIO programming with C

Tue Nov 28, 2023 6:03 pm

What is the diff between libgpio and gpiod?

Does libgpio lock access like gpiod? Only one application controlled the pin?


I was able to run bitbanging in user mode with ds18B20 using gpiod!

viewtopic.php?t=360259#p2161135

irishmonk-57
Posts: 104
Joined: Sat Dec 16, 2023 8:57 am

Re: Raspberry Pi 5 GPIO programming with C

Sat Dec 16, 2023 9:11 am

neilgl wrote:
Sat Nov 04, 2023 8:55 pm
On a pi5 running Bookworm LITE 64-bit, downloaded the source (libgpiod-2.1) from the link 6by9 gave, and was able to build libgpiod and build & run the examples and tools e.g. "gpiodetect".


I've also built libgpiod-2.1 - for my RPi 4B under 32-bit `bullseye`. I'm a little unsure about how to configure things in `/usr/lib/arm-linux-gnueabihf`, but it appears all I need to do is set the "old" (ver 1.6) gpiod tools aside, and create a link for `libgpiod.so` to `/usr/lib/arm-linux-gnueabihf/lib/libgpiod.so.3.1.0`. Analysis/comments or a heads-up with known pitfalls would be greatly appreciated.

Has anyone heard when/if there will be an upgrade to the latest `libgpiod` available for `bullseye` and `bookworm`??

JinShil
Posts: 135
Joined: Wed Mar 15, 2017 11:35 am

Re: Raspberry Pi 5 GPIO programming with C

Thu Dec 21, 2023 4:58 am

Some discussion about upgrading libgpiod at viewtopic.php?p=2170579#p2170579

emenn01
Posts: 1
Joined: Sat Dec 30, 2023 7:24 pm

Re: Raspberry Pi 5 GPIO programming with C

Sat Dec 30, 2023 7:35 pm

Here is a Raspberry PI newbie!

I'm struggling to get the GPIO to work on Raspberry Pi 5 64Bit.
Is there an example C code to e.g. blink an led?

That will help me a lot.

witringPi.h -> Not working
pigPio.h -> not working.
lgpio.h -> Compiles correct, but lgGpioWrite unknown (I o something wrong I hope)

Is there a blink.c example code that will run on Raspberry Pi OS by default?
If not, what are the steps to get blink.c running?

Thanks for your help!

danjperron
Posts: 4667
Joined: Thu Dec 27, 2012 4:05 am
Location: Québec, Canada

Re: Raspberry Pi 5 GPIO programming with C

Mon Jan 01, 2024 2:58 pm

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <gpiod.h>


// define gpiod structure
struct gpiod_chip  *gpiochip;
struct gpiod_line  *gpioline;

// INITIALIZE GPIOD
bool  init_gpiod(void)
{
  gpiochip = gpiod_chip_open_by_name("gpiochip4");
  if(gpiochip == NULL)
      gpiochip = gpiod_chip_open_by_name("gpiochip0");
  if(gpiochip == NULL)
      {
           printf("unable to open GPIO\n");
           return false;
      }
}

// handler for ctrl-c
static volatile int keepRunning = 1;

void intHandler(int dummy) {
    keepRunning = 0;
}

int main(int argc, char **argv)
{
  int value=0;
  int gpioPin;

  if(argc!=2)
  {
    printf("Usage:  blink  GPIOPin\n");
    return -1;
  }

   // intercept ctrl-c
   signal(SIGINT, intHandler);

   // init gpiod
   init_gpiod();

   // select pin
   gpioPin = atoi(argv[1]);
   gpioline = gpiod_chip_get_line(gpiochip,gpioPin);

   // set  gpio pin to OUTPUT
   gpiod_line_request_output(gpioline,"MyBlink",GPIOD_LINE_REQUEST_DIRECTION_OUTPUT);

  while(keepRunning)
   {
      gpiod_line_set_value(gpioline,(value++)&1);
      usleep(500000);
   }
  gpiod_line_release(gpioline);
  gpiod_chip_close(gpiochip);
  return 0;
} // main


set the led to GPIO21 and it should pulse every second.

Code: Select all

sudo apt-get install gpiod libgpiod-dev libgpiod-doc
gcc -o blink blink.c -lgpiod
./blink 21

hippy
Posts: 15820
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Pi 5 GPIO programming with C

Mon Jan 01, 2024 3:18 pm

This is my simplest, standalone, hard-wired, example with no error checking -

Code: Select all

#include <gpiod.h>
#include <stdio.h>
#include <unistd.h>

#define CHIP_NAME "gpiochip0"
#define LED_PIN   0

int main(void) {

  printf("Using <gpiod.h> version %s\n", gpiod_version_string());

  struct gpiod_chip *chip;
  struct gpiod_line *led;

  chip = gpiod_chip_open_by_name(CHIP_NAME);
  led  = gpiod_chip_get_line(chip, LED_PIN);

  gpiod_line_request_output(led, "flash_libgpiod.c", 0);

  while (true) {
    gpiod_line_set_value(led, 1); sleep(1);
    gpiod_line_set_value(led, 0); sleep(1);
  }
}
Not tested on a Pi 5.

danjperron
Posts: 4667
Joined: Thu Dec 27, 2012 4:05 am
Location: Québec, Canada

Re: Raspberry Pi 5 GPIO programming with C

Mon Jan 01, 2024 4:44 pm

@Hippy,

it doesn't work. for the Pi5 you need "gpiochip4".

This is why in my code I try "gpiochip4" and then "gpiochip0"

lurk101
Posts: 2552
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Raspberry Pi 5 GPIO programming with C

Tue Jan 02, 2024 1:14 pm

libgpiod provides a portable API for toggling and reading GPIO pins. I don't know if there are similar APIs for controlling other pin functions like PWM for example. There are always the traditional sysfs interfaces but those seem to be falling out of fashion.

danjperron
Posts: 4667
Joined: Thu Dec 27, 2012 4:05 am
Location: Québec, Canada

Re: Raspberry Pi 5 GPIO programming with C

Tue Jan 02, 2024 1:46 pm

@lurk101

if you look at my code and Hippy code you will see that this what we were using . libgpiod!

lurk101
Posts: 2552
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Raspberry Pi 5 GPIO programming with C

Tue Jan 02, 2024 2:57 pm

danjperron wrote:
Tue Jan 02, 2024 1:46 pm
@lurk101

if you look at my code and Hippy code you will see that this what we were using . libgpiod!
Yes, I know. I was merely asking if there were similar portable APIs for pin related access to functions such as PWM, allowing us to move away from non-portable or sysfs based interfaces.

hippy
Posts: 15820
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Pi 5 GPIO programming with C

Tue Jan 02, 2024 5:21 pm

It appears the kernel provides a standard API for interacting with PWM and other devices which I presume everyone should be using, for example - https://docs.kernel.org/driver-api/pwm.html

There are also 'pinctrl' and 'pinmux' subsystems which I believe come into play.

As to how any of those API should actively be used I have no idea, I am only just getting to grips with 'libgpiod'.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 15837
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspberry Pi 5 GPIO programming with C

Tue Jan 02, 2024 6:09 pm

The only userspace PWM API is via sysfs - https://docs.kernel.org/driver-api/pwm. ... -interface
Whilst I've heard nothing about any projects to move to a character device controlling PWMs, I wouldn't say it will never happen.

As with GPIOs, PWM is generally viewed as an interface that should be controlled by kernel drivers, not hacked around by userspace. Userspace access is for test purposes.

libgpio is handling pinmux as well as GPIO subsystems as they are closely linked.

I2C obviously has the fairly well defined character device API (or read/write).
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

danjperron
Posts: 4667
Joined: Thu Dec 27, 2012 4:05 am
Location: Québec, Canada

Re: Raspberry Pi 5 GPIO programming with C

Tue Jan 02, 2024 6:29 pm

Is the PWM available on the Pi5?

I see C code for pwm-rp1.c in the drivers kernel.
https://github.com/raspberrypi/linux/bl ... /pwm-rp1.c

I see 4 possibles PWM GPIO from RP1 datasheet page 15,16
https://datasheets.raspberrypi.com/rp1/ ... herals.pdf

On one post there is a PWM for fan speed on GPIO 43. but the peripheral document shows only up to gpio27. So what is about?

The /boot/overlays show pwm stuff but I don't see anything about rp1-pwm! Which ones we should use?

And now the PWMs sysfs with generic documentation without any example.

Do you have any example on how to implement this on the PI5?

hippy
Posts: 15820
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Pi 5 GPIO programming with C

Tue Jan 02, 2024 6:39 pm

6by9 wrote:
Tue Jan 02, 2024 6:09 pm
As with GPIOs, PWM is generally viewed as an interface that should be controlled by kernel drivers, not hacked around by userspace. Userspace access is for test purposes.
This seems to be a familiar Linux-Maker conundrum. Makers want to control things and Linux wants to manage that control, but the bridge from one to the other is often tortuous, poorly documented and without practical examples.

It seems ironic that 'sysfs' remains the official interface for PWM while that has long been deprecated for GPIO and why we are now all being dragged into figuring out how 'libgpiod' works and how to use it.

warthog618
Posts: 53
Joined: Sat Jan 06, 2024 12:55 am
Location: Australia

Re: Raspberry Pi 5 GPIO programming with C

Sat Jan 06, 2024 2:07 am

hippy wrote:
Tue Jan 02, 2024 6:39 pm
This seems to be a familiar Linux-Maker conundrum. Makers want to control things and Linux wants to manage that control, but the bridge from one to the other is often tortuous, poorly documented and without practical examples.

It seems ironic that 'sysfs' remains the official interface for PWM while that has long been deprecated for GPIO and why we are now all being dragged into figuring out how 'libgpiod' works and how to use it.
Yeah, the OS wants to manage resources. Funny - that is its primary reason for existing. :o

My take is that you makers aren't looking hard enough. :roll:

The GPIO character device API (which libgpiod uses) has long been the standard way to access GPIO from userspace in Linux, and you have been ignoring that at your peril. You have probably been using a solution that goes direct to the Pi registers and that only works on the Pi. That doesn't work any more for the RPi5 due to the change of architecture, so now you are in the same boat as everyone else. So your little island has gone under and you have been "dragged" into the lifeboat?

The current libgpiod (v2)(docs) provides examples in both C and all the other languages it provides bindings for. If those are confusing or there is a specific use case that isn't already covered, let us know (we do want to make it as easy to use as possible, but to be blunt the input from the community during development of libgpiod v2 was SFA - probably cos you are all happy using wiringPi or similar). I would personally recommend compiling libgpiod v2 for your platform rather than using the older libgpiod v1. That uses an older version of the kernel interface that has its own problems and will eventually be retired, and the v2 API is simpler, so save yourself some anguish and move to libgpiod v2 as soon as possible (or switch to a library that supports both like my Go or Rust libraries - sorry not aware of a C library that does that).

PWM is output only, so it doesn't have to deal with high speed inputs over sysfs. I don't know of any move away from the PWM sysfs interface, but then I'm not involved with PWM. The GPIO sysfs interface is slow and does not deal well with interrupts (it very happily loses them). The GPIO character device API does a much better job there. It will never be as fast as twiddling with registers directly, but it is much faster than sysfs and is safe and portable.

dsyleixa123
Posts: 2268
Joined: Mon Jun 11, 2018 11:22 am

Re: Raspberry Pi 5 GPIO programming with C

Sat Jan 06, 2024 10:16 am

good old days of wiringPi... :? :roll:
hobby programming retiree, ♂, GER
"A programming language that needs left side whitespace or tabs for code block structuring and nesting is ridiculous."

lurk101
Posts: 2552
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Raspberry Pi 5 GPIO programming with C

Sat Jan 06, 2024 2:04 pm

dsyleixa123 wrote:
Sat Jan 06, 2024 10:16 am
good old days of wiringPi... :? :roll:
Those good ol' days are over it seems. To build and install libgpiod version 2.0.2 on Pi 5, I did:

Code: Select all

sudo apt install autoconf-archive
mkdir build
cd build
wget https://kernel.googlesource.com/pub/scm/libs/libgpiod/libgpiod/+archive/refs/tags/v2.0.2.tar.gz
./autogen.sh --enable-tools=yes --prefix=/usr
make -j4
sudo make install
sudo mv /usr/lib/libgpiod.* /usr/lib/aarch64-linux-gnu/
I got the source code from Google archives. There's likely a better source.

hippy
Posts: 15820
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Pi 5 GPIO programming with C

Sat Jan 06, 2024 4:01 pm

warthog618 wrote:
Sat Jan 06, 2024 2:07 am
The GPIO character device API (which libgpiod uses) has long been the standard way to access GPIO from userspace in Linux, and you have been ignoring that at your peril. You have probably been using a solution that goes direct to the Pi registers and that only works on the Pi. That doesn't work any more for the RPi5 due to the change of architecture, so now you are in the same boat as everyone else. So your little island has gone under and you have been "dragged" into the lifeboat?
Seems a reasonable summary to me. But I would point out that most Pi makers have been using the '/dev/mem' and 'sysfs-gpio' mechanisms, directly or indirectly, because that is what Raspberry Pi and others have encouraged Pi users to use for the last decade. It's only with the introduction of Bookworm that makers have found they don't work, Pi 5 or other Pi.
warthog618 wrote:
Sat Jan 06, 2024 2:07 am
The current libgpiod (v2)(docs) provides examples in both C and all the other languages it provides bindings for. If those are confusing or there is a specific use case that isn't already covered, let us know (we do want to make it as easy to use as possible, but to be blunt the input from the community during development of libgpiod v2 was SFA - probably cos you are all happy using wiringPi or similar).
I am not sure who this 'we' is you speak on behalf of. Are you part of the 'libgpiod' development team ? It would be great if you are and Pi makers have someone from the team to directly communicate with.

I suspect you are right; everyone ignored 'libgpiod' because they were using 'WiringPi' or some other mechanism which had worked for a decade and they didn't realise those mechanisms would be pulled out from under their feet with the introduction of Bookworm.

If there had been more "the way we told you to do things is wrong" there might have been more interest in 'libgpiod', the way it worked, and its shortcomings. But it is what it is; we are in the lifeboat and need to deal with it.

One specific use case I have concern over is being able to control a Pi 4B output from the command line. With a LED on GPIO24, using Raspberry Pi OS Bookworm with 'libgpiod' 1.6.3 I can turn that on and off as I choose from the command line, via 'cron', within scripts, etc, by using -

Code: Select all

gpioset gpiochip0 24=1
gpioset gpiochip0 24=0
With 'libgpiod' 2.1 installed I can do the same using -

Code: Select all

gpioset -t0 -c gpiochip0 24=1
gpioset -t0 -c gpiochip0 24=0
That works because what I set GPIO24 to persists when the 'gpioset' command exits. But the output only persists because of a Raspberry PI patch, which puts Raspberry Pi OS behaviour at odds with how 'libgpiod' is documented, and it's a patch which may be revoked so Raspberry Pi OS does behave as 'libgpiod' is documented.

If the patch is revoked, persistence of output will disappear, and many Pi makers will consider that as making 'gpioset' no longer fit for purpose.

What would you suggest Pi makers do if 'gpioset' behaviour, which is currently fit for purpose, becomes not fit for purpose ?

dsyleixa123
Posts: 2268
Joined: Mon Jun 11, 2018 11:22 am

Re: Raspberry Pi 5 GPIO programming with C

Sat Jan 06, 2024 9:44 pm

all far too complicated now,
as stated here: viewtopic.php?p=2177223#p2177223
hobby programming retiree, ♂, GER
"A programming language that needs left side whitespace or tabs for code block structuring and nesting is ridiculous."

hippy
Posts: 15820
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Pi 5 GPIO programming with C

Sat Jan 06, 2024 11:19 pm

dsyleixa123 wrote:
Sat Jan 06, 2024 9:44 pm
all far too complicated now,
as stated here: viewtopic.php?p=2177223#p2177223
Or maybe all resolved and there's little to worry about as here : viewtopic.php?p=2177215#p2177215

My bottom line is that Raspberry Pi OS Bookworm running 'libgpiod' with the Raspberry Pi patch included is fit for purpose on all Raspberry Pi, Pi 5 and others.

That's to say that everything a Pi maker wants to do with any single GPIO line can be done using 'libgpiod' from the command line or through framework libraries which interface to that.

That is predicated on Raspberry Pi OS moving to 'libgpiod' 2.1 and keeping their patch in place. But current 'libgpiod' 1.6.3 is fit for purpose except in the specific case of reading how an output pin has been set and that can be worked round using 'pinctrl'.

It may also require some frameworks to have additional functionality added to ensure they can be fully used how Pi makers desire but there seems to be no reason such functionality couldn't be added.

warthog618
Posts: 53
Joined: Sat Jan 06, 2024 12:55 am
Location: Australia

Re: Raspberry Pi 5 GPIO programming with C

Sun Jan 07, 2024 1:11 am

hippy wrote:
Sat Jan 06, 2024 4:01 pm
Seems a reasonable summary to me. But I would point out that most Pi makers have been using the '/dev/mem' and 'sysfs-gpio' mechanisms, directly or indirectly, because that is what Raspberry Pi and others have encouraged Pi users to use for the last decade. It's only with the introduction of Bookworm that makers have found they don't work, Pi 5 or other Pi.
I know, I started my journey writing directly gpiomem as that was the way. But it is non-portable, so I moved. libgpiod was the standard, but at the time couldn't do biasing. So I added that. Then I needed debounce. But there was no was to add that to the existing API, so I re-wrote the whole API to make it more flexible, and that is the current GPIO character device API.

The fact you've been sold on something else is not the fault of libgpiod. The GPIO character device API has been the standard way to access GPIO from userspace on Linux for years, and we've been encouraging users to move to it, though users frequently take that as having something new forced on them and ignore it rather than contributing to making it better. It never will be as fast and convenient as writing directly to the registers like gpiomem, but it is safe and portable.

It is the current standard, and hopefully this time we've made it flexible enough that we wont need to do another complete re-write to add new features.
hippy wrote:
Sat Jan 06, 2024 4:01 pm
I am not sure who this 'we' is you speak on behalf of. Are you part of the 'libgpiod' development team ? It would be great if you are and Pi makers have someone from the team to directly communicate with.
As noted above, I'm a kernel developer, I wrote the latest GPIO character device API that libgpiod v2 uses. I also contributed to libgpiod, both v1 and v2. And I one of the reasons I'm here is to try to help you guys transition now the RPi5 has pulled the rug on you, and see what we can do to make things easier. But there are a host of forums out there and monitoring takes work so if you want to contact us the best way is to mail the mailing list as described in the CONTRIBUTING section of the libgpiod README.
hippy wrote:
Sat Jan 06, 2024 4:01 pm
I suspect you are right; everyone ignored 'libgpiod' because they were using 'WiringPi' or some other mechanism which had worked for a decade and they didn't realise those mechanisms would be pulled out from under their feet with the introduction of Bookworm.

If there had been more "the way we told you to do things is wrong" there might have been more interest in 'libgpiod', the way it worked, and its shortcomings. But it is what it is; we are in the lifeboat and need to deal with it.
Historically we would tend to get shit dumped on us when we suggested migrating, so you lose enthusiasm for that approach pretty quickly.
hippy wrote:
Sat Jan 06, 2024 4:01 pm
One specific use case I have concern over is being able to control a Pi 4B output from the command line. With a LED on GPIO24, using Raspberry Pi OS Bookworm with 'libgpiod' 1.6.3 I can turn that on and off as I choose from the command line, via 'cron', within scripts, etc, by using -

Code: Select all

gpioset gpiochip0 24=1
gpioset gpiochip0 24=0
With 'libgpiod' 2.1 installed I can do the same using -

Code: Select all

gpioset -t0 -c gpiochip0 24=1
gpioset -t0 -c gpiochip0 24=0
I tend to use

Code: Select all

gpioset -t0 GPIO24=1
cos I'm lazy, but the `-c` form is a bit faster as it doesn't have to search for the named line.
Btw `-c0` should work too.
hippy wrote:
Sat Jan 06, 2024 4:01 pm
That works because what I set GPIO24 to persists when the 'gpioset' command exits. But the output only persists because of a Raspberry PI patch, which puts Raspberry Pi OS behaviour at odds with how 'libgpiod' is documented, and it's a patch which may be revoked so Raspberry Pi OS does behave as 'libgpiod' is documented.

If the patch is revoked, persistence of output will disappear, and many Pi makers will consider that as making 'gpioset' no longer fit for purpose.

What would you suggest Pi makers do if 'gpioset' behaviour, which is currently fit for purpose, becomes not fit for purpose ?
Indeed, the libgpiod documentation was based on the behaviour of typical mainline kernel drivers, so strictly speaking the documentation is wrong.

There is already a patch in libgpiod master to reword the documentation to indicate what happens when gpioset exits is beyond our control. So that will be in the next libgpiod release.

And again, due the to way the interfaces are defined within the kernel, there is currently no way for us to guarantee behaviour once the line is released - it is up to the device driver. There has been some discussion of extending the driver API to allow that behaviour to be specified, but even if there is sufficient interest in going in that direction there are a lot of drivers out there so getting consistent support would be a drawn out process.

The safer bet would be to make sure the Pi kernel devs don't remove the persistence behaviour that they have added. Worst case you have to patch the kernel yourself.

hippy
Posts: 15820
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Pi 5 GPIO programming with C

Sun Jan 07, 2024 8:07 am

warthog618 wrote:
Sun Jan 07, 2024 1:11 am
the libgpiod documentation was based on the behaviour of typical mainline kernel drivers, so strictly speaking the documentation is wrong.
That does explain a lot.
warthog618 wrote:
Sun Jan 07, 2024 1:11 am
There is already a patch in libgpiod master to reword the documentation to indicate what happens when gpioset exits is beyond our control. So that will be in the next libgpiod release.
That is very welcome, thanks, and we will be keeping our fingers crossed that Raspberry Pi OS keeps the 'libgpiod' packages and utilities updated and we aren't stuck on the 1.6.3 version which is the current default from upstream.

Return to “C/C++”