GPIO.add_event_detect no longer works with the new kernel 6.60 #6037
Comments
|
I suspect this is because the rpi-6.6.y kernel no longer overrides an upstream kernel decision to force the base number of the main GPIO controller to be global GPIO 0. Running |
|
Okay, if that was the intention, then I know. Since many tutorials on the internet still use the RPi.GPIO library, this will definitely be painful for users. I also don't think that the RPi.GPIO library will receive an update or be adapted, as it has not received an update for the Raspberry Pi 5 either. What sensible alternative should users use? Especially with a trigger for events? Old Kernel on a other RPI: New Kernel on the RPI 4: |
Ok, what is the fix? Sorry for the basic question. Newbie at Rpi |
|
The fix is for someone to patch RPi.GPIO to locate the global GPIO number for GPIO0, and add that as an offset to the requested GPIO number. In this case it is likely to be 512. |
|
Thanks Phil. I guess I'll have to wait for 'someone'. Although I'd be
willing to do such a fix, I have zero experience in RPi for the time being.
Saludos, Greetings
*Jean-Robert STRELE*
COL: +57.321.414.6328
USA: +1.925.922.4231
***@***.***
ᐧ
…On Thu, 14 Mar 2024 at 11:23, Phil Elwell ***@***.***> wrote:
The fix is for someone to patch RPi.GPIO to locate the global GPIO number
for GPIO0, and add that as an offset to the requested GPIO number. In this
case it is likely to be 512.
—
Reply to this email directly, view it on GitHub
<#6037 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNRQQNV5XGCAMIPMWXDYYHFHTAVCNFSM6AAAAABEUTY3D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXHA2DENJWHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Ubuntu have already been down this path (GPIO via sysfs has totally gone there), and Dave Jones has written an RPi.GPIO shim on top of lgpio I thought we'd pulled that shim into Raspberry Pi OS, but we only appear to have python3-rpi.gpio and not python3-rpi-gpio. |
|
On Pi 5
In the past, now only first 5 values take effect for each line.... (Values adjusted for sure) |
|
Now you are really crossing the streams. The config.txt lines are interpreted by the firmware, which should then set default pull-ups on some pins and make others outputs. These changes may persist once the kernel has booted, but they may also be overwritten.
|
Off the top of my head, I'm not sure. Last time I looked at GPIO libraries, there was some uncertainty about what the right way forward is and what to focus on. I'll revisit when I'm back in April. |
|
@pelwell we can separate that, sure. Wasn't sure if it's also related here. But yes, it's new since the switch on 6.6. not sure what's the cause, kernel or other firmware/OS related changes. To me it looks like there's also a difference on the GPIO mapping (gpio 3 on Pi 4 on 515, Pi 5 on 574), is that true in general or depends on the kernel Version? |
|
597,598 and 595 are ignored.
|
|
The firmware still expects the GPIOs to be numbered from 0 (the firmware and kernel are completely different worlds), so: was correct. |
|
Hello,
If I understand the conversation correctly we are looking for a solution
sometime in April, correct?
Just so I can plan my project around this.
Have a good weekend
Saludos, Regards,
Jean-Robert STRELE
COL +57.321.414.6328
USA +1.925.922.4231
***@***.***
…On Fri, Mar 15, 2024, 09:26 Phil Elwell ***@***.***> wrote:
The firmware still expects the GPIOs to be numbered from 0 (the firmware
and kernel are completely different worlds), so:
gpio=5,6,7,8,16,17,20,21,22,26,27=pu
gpio=9,10,11,12,18,19,23,24,25=op
was correct.
—
Reply to this email directly, view it on GitHub
<#6037 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNSX64HXMA25HRHBWSLYYMAIZAVCNFSM6AAAAABEUTY3D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJZG44DENBTHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
You probably won't get an answer before April, but there is no timeframe for a solution. So we can understand your situation a bit better:
|
|
This is a local project for my pool chemistry. One time solution.
I don't have the knowledge to build/modify my own RPi.gpio.
So, yes, a local solution would be acceptable to me as an interim solution,
until a stock solution is available...
Keep in mind, I'm a newbie at RPi...
Thanks!
…On Fri, Mar 15, 2024, 12:50 Phil Elwell ***@***.***> wrote:
we are looking for a solution sometime in April, correct?
You probably won't get an answer before April, but there is no timeframe
for a solution.
So we can understand your situation a bit better:
1. Are you building RPi.GPIO yourself?
2. Are you shipping/going to ship it to your customers (if there are
customers)?
3. In other words, would a locally modified version of RPi.GPIO be a
workable solution?
—
Reply to this email directly, view it on GitHub
<#6037 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNSHM26OUXSW3M2WH4TYYMYHJAVCNFSM6AAAAABEUTY3D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBQGE2TONRXGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
First of all, I just wanted to thank you for your great work over the last few years. But now to the topic. In my humble opinion, letting die the RPi.GPIO library is one of the biggest mistakes of the Raspberry Pi Foundation. In my humble opinion, this has the following reasons:
Therefore, in my humble opinion, the library should be adapted for all models, even if the original developer no longer does this, the maintenance could be continued by the Raspberry Pi Foundation. |
|
There is a related discussion/ticket at https://sourceforge.net/p/raspberry-gpio-python/tickets/210/ |
|
I have been struggling with this issue for a couple of days and have just come across this thread. I have several clients who are using RPi4s who will have to stay on the Bullseye OS until a solution is found. To date RPi.GPIO has worked well It would be really helpful if the documentation https://www.raspberrypi.com/documentation/computers/os.html could be updated to cover the issues raised by @Blackbox-git . rpi-lgpio seems to work well on RPi5s running Bookworm. Perhaps this could be extended to provide at least an interim solution for RPi4s. |
Does it not work on all Pis? |
|
@pelwell , Unfortunately I don't think so. On RPi4s rpi-lgpio seems to mimic the behaviour of RPi.GPIO. Perhaps somebody has found a way to make it work. |
|
I use a workaround now I use gpiozero for the previous "Event_detect". The rest of the pin control still runs via RPi.GPIO. FOR EXAMPLE: This makes it possible to use the GPIO-PIN once with an event listener in program 1. In program 2 you can still read the state of the GPIO-PIN via the RPi.GPIO libary with the command GPIO.input("MY_PIN_NUMBER") without getting a "GPIO is busy" warning. |
I'm confused. It's meant to mimic the behaviour of RPi.GPIO. Running on a Pi4 with Bookworm here, rpi-lgpio installed via pip3, and interactively doing has just done the expected when each step was checked via I've not looked specifically at the add_event_detect hook. It is true that 2 different processes can not access the same GPIO as libgpiod enforces ownership, but different processes can access different GPIOs. |
|
@pelwell, yes, you are right but I was specifically looking at add_event_detect which I haven't been able to get working. |
|
Can you post a small sample program so we can take a look? |
|
If it's more than a page you could put it in a gist (see the + Create New button at the top of the page). |
|
@pelwell, Ooopps. My apologies there was an issue in my environment affecting RPi4s. It is working exactly as expected now! I wasn't seeing the wood for the trees. |
|
@Blackbox-git , "add_event_detect works" as expected on RPi4s running Bookworm when using the rpi-lgpio package |
Like most of the packages that are installed via the apt package manager RPi.GPIO wasn't written, and isn't maintained by, Raspberry Pi itself. I would expect the RPi.GPIO authors to support and maintain their own code.
I disagree with all of this. Certainly our own documentation, and the books published by Raspberry Pi Press, do no suggest using RPi.GPIO.
If you want RPi.GPIO fixed you should report the problem to the people that can fix it. The project seems to be hosted on Sourceforge. You could potentially file a ticket there https://sourceforge.net/p/raspberry-gpio-python/tickets/ and enquire about support. Unfortunately it does look like the developers are pretty unresponsive, there was a ticket opened back in November asking about Pi 5 support, https://sourceforge.net/p/raspberry-gpio-python/tickets/214/, which has not yet received a response. |
|
We also encountered this problem, but it can be solved by changing the example program to the libgpiod version, we provide an libgpiod example which can be found below: https://raw.githubusercontent.com/geekworm-com/x728-script/main/sample/x728-v2.x-plsd-gpiod.py |
Note that you need to provide a different gpiochip number on Pi 0,1,2,3,4 ( |
|
I'm in the same boat. Was running a small water flow sensor project coded in Python3 on a 3B+ with Bookwork 5.1. Updated to Bookworm 5.2 and I get the same edge detection error at the top of the thread. Yes, I'm using RPi.GPIO because it seems to be the best documented library, both on line and in paper books. Since the 3B+ is being used as a dedicated controller I suppose my only work around will be to reload with 5.1 or maybe go back to Bullseye. I agree with Blackbox-git - lots of folks use and like RPi.GPIO. Me too. |
Then you need to persuade the RPi.GPIO authors to update their library. It's not our code, so it's not something that Raspberry Pi can fix. |
|
Or switch to rpi-lgpio, which has the same API: https://github.com/waveform80/rpi-lgpio |
|
I've added rpi-lgpio to the repo. You should be able to replace rpi.gpio by running |
|
☝️ Is it worth mentioning that in the docs @aallan ? 🤷 (also ping @waveform80 as a heads-up that he might get more people using |
|
And to say thank you, obviously |
The documentation talks about using |
Yikes! As someone semi-connected/responsible for this state of affairs, it's probably time I waded in. I'm not going to respond to everything, but here's some important points:
It's not the Pi Foundation's library (they simply went with what the community leapt on as "the" GPIO library), and they're not "letting [it] die". This is a change that's being driven upstream from the Linux kernel. For the full story, I wrote a long and very boring blog post about it several years ago but the long and short is that the kernel really doesn't like processes bypassing it entirely and stomping on registers it thinks it has exclusive access to, and it's a minor miracle it's worked as well as it has for as long as it did. The abstraction also breaks the second the hardware changes fundamentally, as it's now had to with the Pi 5 (the GPIOs are no longer driven by the SoC but by the RP1 at the other end of a PCIe bus). All in all, this state of affairs was never going to last.
Yes, it's not an equivalent replacement. However, the complaint that GPIOs cannot be accessed simultaneously by separate processes is to do with the new kernel-based system of driving GPIOs. It's nothing to do with gpiozero (which will happily share pins between processes if the underlying driver, like RPi.GPIO, permits it, but when the underlying driver doesn't, like lgpio, there's nothing we can do about it). Frankly anything built on the new kernel-based system of driving GPIOs will not support this. If you are relying on it, you need to find a new way of doing things, like using threading instead of processes, or IPC between processes (having one process that handles your GPIOs and let your other processes talk to it).
Yes, and that's absolutely deliberate (there's a story behind this choice... I should write another blog post about that... hears the audience groaning). It's also arguable whether this is easier or harder for "beginners in the web area". It's only harder if you're using separate processes per request (in which case you're going to get bitten by processes sharing pins anyway). Switch to a threading or async model and you deal with both problems simultaneously. In the traditional Python http.server module, this is as simple as changing one keyword (
Again, it's not their library, they've never maintained it, and it's not a question of anyone maintaining it. The kernel interfaces it relies upon are going away, and the new ones do not permit things like sharing GPIOs between processes.
Argh, this is at least partially my fault, but should now be corrected. For a long time, lgpio's had a very out of date source package up on PyPI because joan, the author of lg (the project containing lgpio) isn't an expert on Python packaging which is a convoluted area in recent years, to say the least (ask me how I know...). I finally found a bit of time to dig into this and figure out how to build some pre-compiled wheels of lgpio for PyPI for a variety of Python versions. So, as of a couple of weeks ago there should be a decent variety of wheels for the two main architectures available from PyPI. If you've been struggling with getting lgpio (or rpi-lgpio, which I'll come onto shortly) running, please try again (or upgrade your venv to the current lgpio wheel versions) and hopefully things should go smoother this time. And sorry it's taken me so long to get around to this!
See section above.
Yes, rpi-lgpio is intended as a drop-in replacement for RPi.GPIO in the new kernel-based /dev/gpiochip world. If you're desperate to read more of my rambling there's yet another blog post that introduces that one, but for most users I would urge them to read the differences chapter in the documentation prior to usage. There will be some differences that I simply cannot paper over (like the aforementioned multiple-processes accessing one GPIO problem), and others that it's probably not worth papering over (see the Debounce section) because doing so would cause even more grief. The chapter should hopefully set your expectations for what's going to work and what's not. |
|
Thanks @dave Jones,
Yesterday I broke my SD Card while changing RPi cases and since I was
developing my project on PyCharm via SAMBA and SSH, and only was doing
commits instead of Pushes, I lost 8 weeks' worth of learning/coding! DUH!
But, silver lining, I get to re-evaluate my program structure and clean out
all the trial/errors that have been accumulating on the RPi and the code.
One of the findings was that when installing lgpio inside the venv, it
worked on the first try, drop-in compatible with the snippet of code I had
emailed to someone and as a result got preserved. So, thanks again @dave
Jones for fixing that part.
On a peripherally related topic: I'm using PyCharm's AI Assistant
extensively in my coding and it is he/she that recommended using RPi.GPIO
in the first place (about 8 weeks ago). So there is some truth to an
earlier comment about RPi.GPIO being the de-facto standard. Yesterday I
told AI Assistant that RPi.GPIO in its existing form was broken and what to
recommend instead: 'gpiozero' or 'RPi.GPIO2' came back the answer. I guess
more coders on PyCharm will need to update their code to lgpio for AI to
catch up.
Cheers.
ᐧ
…On Wed, 10 Apr 2024 at 08:06, Dave Jones ***@***.***> wrote:
☝️ Is it worth mentioning that in the docs @aallan
<https://github.com/aallan> ? 🤷
(also ping @waveform80 <https://github.com/waveform80> as a heads-up that
he might get more people using rpi-lgpio now 😃 )
Yikes! As someone semi-connected/responsible for this state of affairs,
it's probably time I waded in. I'm not going to respond to everything, but
here's some important points:
But now to the topic. In my humble opinion, letting die the RPi.GPIO
library is one of the biggest mistakes of the Raspberry Pi Foundation.
It's not the Pi Foundation's library (they simply went with what the
community leapt on as "the" GPIO library), and they're not "letting [it]
die". This is a change that's being driven upstream from the Linux kernel.
For the full story, I wrote a long and very boring blog post
<https://waldorf.waveform.org.uk/2021/the-pins-they-are-a-changin.html>
about it several years ago but the long and short is that the kernel really
doesn't like processes bypassing it entirely and stomping on registers it
thinks it has exclusive access to, and it's a minor miracle it's worked as
well as it has for as long as it did.
The abstraction also breaks the second the hardware changes fundamentally,
as it's now had to with the Pi 5 (the GPIOs are no longer driven by the SoC
but by the RP1 at the other end of a PCIe bus).
All in all, this state of affairs was *never* going to last.
2. the GPIOZERO library is not an equivalent replacement. First of
all, GPIOS cannot be accessed with several programs at the same time. The
new library may be suitable for beginners, but if you are an advanced
beginner, this is no longer the case. Not everyone is familiar with sockets
or named pipes. The leap is simply too big for many beginners. RPi.GPIO
could do this without any problems.
@Blackbox-git <https://github.com/Blackbox-git> , "add_event_detect
works" as expected on RPi4s running Bookworm when using the *rpi-lgpio*
package
Yes. But you cant access from another programm the gpio with this libary.
Yes, it's not an equivalent replacement. However, the complaint that GPIOs
cannot be accessed simultaneously by separate processes is to do with the
new kernel-based system of driving GPIOs. It's nothing to do with gpiozero
(which will happily share pins between processes *if* the underlying
driver, like RPi.GPIO, permits it, but when the underlying driver doesn't,
like lgpio, there's nothing we can do about it).
Frankly *anything* built on the new kernel-based system of driving GPIOs *will
not support this*
<https://rpi-lgpio.readthedocs.io/en/release-0.4/differences.html#simultaneous-access>.
If you are relying on it, you need to find a new way of doing things, like
using threading instead of processes, or IPC between processes (having one
process that handles your GPIOs and let your other processes talk to it).
3. if you terminate a program that uses the GPIOZERO library, the
current state of the GPIO is not retained after termination. This means
that no script can be programmed that changes the state of the pin and is
then terminated. Beginners in the web area will find this particularly
difficult.
Yes, and that's absolutely deliberate (there's a story behind this
choice... I should write another blog post about that... *hears the
audience groaning*).
It's also arguable whether this is easier or harder for "beginners in the
web area". It's only harder if you're using separate processes per request
(in which case you're going to get bitten by processes sharing pins anyway).
Switch to a threading or async model and you deal with both problems
simultaneously. In the traditional Python http.server module
<https://docs.python.org/3/library/http.server.html>, this is as simple
as changing one keyword (ForkingMixIn to ThreadingMixIn) -- I'm afraid
I'm rather out of date on other libraries, so I can't give recommendations
there.
Therefore, in my humble opinion, the library should be adapted for all
models, even if the original developer no longer does this, the maintenance
could be continued by the Raspberry Pi Foundation.
Again, it's not their library, they've never maintained it, and it's not a
question of anyone maintaining it. The kernel interfaces it relies upon *are
going away*, and the new ones do not permit things like sharing GPIOs
between processes.
good morning @TimW55 <https://github.com/TimW55>, So, I installed a new
venv and installed the rpi-lgpio package into it. Trying to run the
following program (copied from my other project. agreed that it might not
work as is):
[snip...]
Traceback (most recent call last): File
"/tmp/pycharm_project_14/testlgpio.py", line 2, in import RPi.GPIO as GPIO
File
"/home/Helios/.virtualenvs/TestLGPIO/lib/python3.11/site-packages/RPi/GPIO/
*init*.py", line 13, in import lgpio ModuleNotFoundError: No module named
'lgpio' ' ᐧ
Argh, this is at least partially my fault, but *should* now be corrected.
For a long time, lgpio's had a very out of date source package up on PyPI
because joan, the author of lg (the project containing lgpio) isn't an
expert on Python packaging <joan2937/lg#24>
which is a convoluted area in recent years, to say the least (ask me how
I know <https://piwheels.org/>...). I finally found a bit of time to dig
into this and figure out how to build some pre-compiled wheels of lgpio for
PyPI for a variety of Python versions. So, as of a couple of weeks ago
there should be a decent variety of wheels
<https://pypi.org/project/lgpio/#files> for the two main architectures
available from PyPI.
If you've been struggling with getting lgpio (or rpi-lgpio, which I'll
come onto shortly) running, please try again (or upgrade your venv to the
current lgpio wheel versions) and hopefully things should go smoother this
time. And sorry it's taken me so long to get around to this!
This is especially annoying as fixing this within (Docker) containers is
even more annoying. lgpio only has a very old version up on pypi which is
incompatible with gpiozero so I had to download a tar from a fork and
compile that (as it uses native C bindings) inside Docker :/
See section above.
Or switch to rpi-lgpio, which has the same API:
https://github.com/waveform80/rpi-lgpio
Yes, rpi-lgpio is intended as a drop-in replacement for RPi.GPIO in the
new kernel-based /dev/gpiochip world. If you're desperate to read more of
my rambling there's yet another blog post
<https://waldorf.waveform.org.uk/2022/the-one-where-dave-breaks-stuff.html>
that introduces that one, but for most users I would urge them to read the differences
chapter <https://rpi-lgpio.readthedocs.io/en/latest/differences.html> in
the documentation prior to usage.
There *will* be some differences that I simply cannot paper over (like
the aforementioned multiple-processes accessing one GPIO problem), and
others that it's probably not worth papering over (see the Debounce
section
<https://rpi-lgpio.readthedocs.io/en/release-0.4/differences.html#debounce>)
because doing so would cause even more grief. The chapter should hopefully
set your expectations for what's going to work and what's not.
—
Reply to this email directly, view it on GitHub
<#6037 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNVRLSDCNRMBDHZDTIDY4U2NDAVCNFSM6AAAAABEUTY3D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBXGQ4TIOJRHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@Trilife, perhaps you have missed an important lesson. AI is not always factually correct. In deed the more I use it, and I use it a lot in my VS Code environment, the less I rely on its responses. Nevertheless AI, and ChatGPT in particular, has improved my productivity and the quality of my coding considerably. |
|
@TimW55,
Indeed, I have come to the same conclusion, but my coding skills are not
quite where I can discern fact from fiction. And yes, having AI put down a
skeleton to work on has sped up quality and speed.
…On Wed, Apr 10, 2024, 10:13 TimW55 ***@***.***> wrote:
@Trilife <https://github.com/Trilife>, perhaps you have missed an
important lesson. AI is not always factually correct. In deed the more I
use it, and I use it a lot in my VS Code environment, the less I rely on
its responses. Nevertheless AI, and ChatGPT in particular, has improved my
productivity and the quality of my coding considerably.
My apologies for veering slightly off topic.
—
Reply to this email directly, view it on GitHub
<#6037 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQXPNX53YJEPLNHU6PBLYTY4VJIDAVCNFSM6AAAAABEUTY3D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBXHAZDGMRVGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I am using RPI 4B with Bullseye. I was able to fix this by rolling back the firmware update [rpi-update] to the stable version. After that update the software and reboot |
|
@DimuthuDKA |
|
Hi, i am using this function from pyscript. (https://hacs-pyscript.readthedocs.io/en/latest/) I tried to change the requirements.txt to use rpi-lgpio but got the error from above
As far as I know I cannot simply create a venv within pyscript, so how can I use lgpio? |
|
@Beiri22 What version of Python are you using, and what OS are you on (I'm guessing HAOS but I've no idea what version of Python is currently on there)? I've uploaded wheels for armhf, arm64, amd64 on Python versions 3.9 through 3.12, so if your environment matches that it shouldn't be attempting to compile the wheel from source. |
Until kernel version 6.6 the first gpio chip's offset started at 0 due to a downstream patch of RPi. This patch was removed with 6.6 and the kernel now follows the mainline behavior whereas the offset starts as 512 ([1]). Unfortunately we rely on indexed gpio access in revpi_flat.c for the relay and button, as there is no platform device we can query. Thus keep the current implementation at least for now and add a version macro, which takes care of the offset calculation. [1] raspberrypi/linux#6037 (comment) Signed-off-by: Nicolai Buchwitz <[email protected]>
Describe the bug
Since the update to the following kernel, the "add_event_detect" function from the RPi.GPIO library no longer works.
Linux outdoor enclosurePi 6.6.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/LinuxThe program crashes with the following error.
I use the following Raspberry
Raspberry Pi 4 Model B Rev 1.5Steps to reproduce the behaviour
Update to the actual kernel and try the RPi.GPIO library function "add_event_detect"
Device (s)
Raspberry Pi 4 Mod. B
System
Raspberry Pi reference 2023-10-10
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, fb56ad562991cf3ae5c96ab50983e1deeaefc7b6, stage2
Feb 29 2024 12:24:53
Copyright (c) 2012 Broadcom
version f4e2138c2adc8f3a92a3a65939e458f11d7298ba (clean) (release) (start)
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: