Earlier quoted context omitted.
> Which is why when folks nowadays say "you cannot use XYZ for embedded", given what most embedded systems look like, and what many of us used to code on 8 and 16 bit home computers, I can only assert they have no idea how powerful modern embedded systems have become. Yet, I still need to wait about 1 second (!) after each key press when buying a parking ticket and the machine wants me to enter my license plate numbe…
My first guess was debouncing. They assume that the switches are worn out, deeply weathered, and cheaply made. Each press will cause the signal to oscillate and they're taking their sweet time to register it. When the device is new this is an absurd amount of time to wait. As the device degrades over 10, 20 years, that programming will keep it working the same. Awful the entire time, yes, but the same as the day it w…
At Kroger-brand gas stations near me, I get to interact with the buttons on gas pumps to select options and enter a loyalty ID.
Those buttons have visible feedback on a screen, and also audible feedback consisting of a loud beep. And there's always delays between button press and feedback.
Some combination of debounce and wear might explain that easily enough.
Except... the delay between pushing a button and getting feedback is variable by seemingly-random amounts. The delay also consistently increases if a person on the other side of the pump island is also pushing buttons to do their own thing.
It's maddening. Push button, wait indeterminate time for beep, and repeat for something like 12 or 13 button presses -- and wait longer if someone else is also using the machine.
I can't rationally explain any of that variability with debounce.