You may be attracted by the idea of event handling. It is easy and this makes it great for beginners. Just write what you want to happen when a button is pressed or released and then get on with the rest of your program. No polling loop and no waiting. It is useful for the beginner, but it isn’t a good way to organize things in the long run. The problem is that it is the pin factories that are responsible for implementing the event handling and they do this in different ways. As already discussed in connection with general interrupts and events, this approach slows the overall system down and creates problems when events occur at too fast a rate. For example, the pressed event handler can be interrupted by a release event and the release function will run before the press function ends. If a new button press happens after the release, then the press function is run a second time, even if the first call to it is still running. However, the subsequent release function isn’t called until the first press function finishes. This is a mess! Exactly what happens when multiple events occur depends on the pin factory that is providing the service and this too is unsatisfactory in that you can’t know what will happen.
In conclusion, using event handling in GPIO Zero is an easy way to produce a demo or get started, but it isn’t a good way to implement anything beyond the very simple.
This is the big problem with asynchronous code that doesn’t use a queue to ensure that multiple events are handled correctly and in the correct order.
If events and asynchronous code aren’t the way to do the job what is? The simple answer is the polling loop, but putting order into the polling loop so that it is clean and easy to extend is difficult.
If you are happy with events and basic polling loops skip the next section, which describes a way to organize polling loops so that they are easier to work with.
In chapter but not in this extract
Finite State Machines
FSM Ring Counter
How Fast Can We Measure?
A Custom Simple Input
Threading
Summary
There is only one simple input device, Button, but it is easy to add custom input devices.
Exactly how Button works depends on how you set the pull_up property.
The simplest way of using Button is to wait_for_press or wait_for_release
Button has a simple debounce feature which sets a “dead” time in which it doesn’t respond to any changes.
Polling is the simplest and fastest way of handling input. It works by repeatedly testing the state of the button.
The alternative to polling is to use events or interrupts. Both seem to be attractive alternatives, but they have serious difficulties and tend to slow the system down.
Button and other input devices support asynchronous events via the when_pressed and when_released properties. These can be set to functions which are called when the event occurs.
Asynchronous events are a very good way to create simple demos and to get started, but they are not efficient and quickly become too complex to understand.
One way to organize polling so that it remains easy to understand in complex situations, is to use a finite state machine (FSM) approach.
You can read the state of a button state as quickly as 500Hz on a Pi Zero, 10kHz on a Pi 4 and 9kHz on a Pi 5.
If you try this out you will find that a Pi Zero is reasonable up to 5kHz, a Pi5 works to 100kHz and a Pi4 is reasonably reliable up to 200kHz
You can create custom input devices using DigitalInputDevice as a base class.
Python supports threading, which is used to implement GPIO Zero’s events.
Raspberry Pi IoT In Python Using GPIO Zero Second Edition
Despite being tagged as a minor upgrade, NET Aspire 9.2 has additions. Since the last major release, NET Aspire 9 has offered new control over the lifetime of containers on local developer enviro [ ... ]
The rise and rise of reliance on LLMs for code generation has resulted in a new threat to software supply chains. Dubbed "package hallucination", this occurs when LLMs generation references to non-exi [ ... ]
