C/C++ • Re: Raspberry Pi 5 GPIO programming with C

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.

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.

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.

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:

gpioset gpiochip0 24=1gpioset gpiochip0 24=0

With 'libgpiod' 2.1 installed I can do the same using -

Code:

gpioset -t0 -c gpiochip0 24=1gpioset -t0 -c gpiochip0 24=0

I tend to use
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.

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.

Statistics: Posted by warthog618 — Sun Jan 07, 2024 1:11 am

---