mholgatem
commented
2 years ago GPIOnext is multithreaded, so each time that a key is pressed, a new thread is created to handle whatever needs to be done, then it destroys itself upon completion (usually key release). So that is what you are seeing in HTOP.
As for the actual problem, it's a known issue that can't be avoided, but it can be mitigated. Unfortunately, due to the nature of python and the Linux kernel, GPIO polling is not suitable for real-time applications. Which means that sometimes events (like key release) gets missed. Here are some ways to mitigate the problems:
- set combo_delay to 0 using the following command:
gpionext set combo_delay 0- combo_delay slows the read rate to give the user the chance to press combos to enable a different command
- set debounce to 50 using the following command:
gpionext set debounce 50(may need to go as high as 250 depending on quality of your buttons)- debounce is the number of milliseconds that the system stops reading that pin to account for the debounce period of your momentary switch.
- Momentary switches can have a small internal 'bounce' that will cause them to 'double tap' the GPIO pin. Thus creating a 2nd thread before the first thread has a chance to react.
Hopefully this helps!
I'm running Retropie on a Raspberry Pi 4 and have joysticks and buttons wired to the GPIO pins. If a key is pressed multiple times in rapid succession sometimes the key sticks and acts as though it is held down until you press it again, I can get this to happen on multiple keys at the same time. I checked Htop and there are several more copies of the script running for each stuck key, but they go away after I press the key again and it becomes unstuck.