Suppose a button on your prototype should turn a light on, then turn it off on the next press. That sounds complete until someone holds the button down. Should the light change once, keep changing, or do something different after a longer hold?
This is a product decision, and it shows up even in a very small circuit. In a December 2021 museum-game discussion, the builder's real difficulty was handling children pressing buttons in unexpected orders. The useful starting point was to describe those situations before writing more code.
We looked at the same issue at a smaller scale on our bench: a button module and an LED module wired to a Raspberry Pi Pico-based controller board, programmed with blocks in BIPES, a browser-based editor for MicroPython. The block program was short, it worked in a quick demo, and it still left the press rule undefined.
Read the action behind the light
The program reads GPIO9 with the internal pull-up enabled, so a press pulls the input low. A low reading enters the button branch. It prints a message, waits 200 milliseconds, writes the opposite of GPIO7's current readback to the LED, and waits another 200 milliseconds.
As a reading guide, not replacement firmware:
repeat:
if the button input is low:
print the trigger message
wait 200 ms
write the inverse of the output readback
wait 200 ms
Nothing in that branch waits for release. If the input stays low, the next loop enters the branch again. The waits space the changes out, but they do not turn a held button into a single completed press. The console showed repeated trigger messages, which by themselves do not demonstrate one toggle per physical press.
Separate a held state from a new press
A button has a current state: pressed or released. A new press is a transition between those states. Arduino's state-change detection example shows the idea: compare the current input with its previous value and act only on the change. The principle carries over, although its wiring and code are not a drop-in replacement for this board.
For a simple on/off control, a sensible next revision is to keep the output state in a variable and change it once when a valid new press is recognized. Also decide how to handle the rapid electrical changes a mechanical contact makes around a press. A time delay and a release rule solve different parts of the problem; you usually need both.
It is easy to confuse this with a related behavior. A different input, such as an infrared presence sensor, can drive an LED directly: light on while the input is active, off otherwise. That follows an input level. A toggle remembers a state between presses. They are two different behaviors, and a program that looks like one can quietly be the other.
Give the prototype a short, testable promise
Write the intended behavior in ordinary language, for example: "The light starts off. Each press switches it to the opposite state. Holding the button does not cause another change. Releasing it prepares the next press." If a long press should reset something, add that as a separate rule with a chosen duration.
Then check it:
- a brief press;
- a long hold;
- two deliberate presses in quick succession;
- release after a hold;
- disconnecting and reconnecting power, to confirm the startup state.
Record the light and the console together for each case. These are acceptance checks for the next revision; the first program's repeated console messages do not show that any of them pass.
Keep the first block file with the record, and give each revised program a new version. If a result changes, you will be able to tell whether the behavior was changed on purpose or the demonstration used a different file.
Why this matters before the panel exists
The point is to make the control predictable before it goes behind a finished panel. Once the rules are clear, choices about button size, feedback and mounting have something concrete to support. A button that "mostly works" in a demo tends to become a support question once someone outside the team holds it down, presses it twice quickly or powers the device back on.
When you pass the prototype to someone else, send the written rules, the version of the program that implements them and a short video of the five checks above. That gives the next engineer something to verify instead of a feeling to reproduce.