The world has gotten much fancier with capacitive and resistance touch input on displays, buttons that don’t give tactile feedback, or buttons that do but bounce the input signal on occasion. Buttons are everywhere. They’re on microwaves, refrigerators, garage door openers, smartphones, and inhabit the soul of the electric start/stop for modern automobiles. For designers, developers, experimenters, hobbyists, programmers, and plain old engineers, the designs surrounding buttons have gotten more complicated. The consequences of button behavior are up to us. For example, using a garage door remote can be tricky. The first press of the button and you might not be in range. The second time you press it, you might not realize that it’s already begun and press it a third time, causing it to reverse direction.

The electric start/stop on my new-ish hybrid Toyota is another example. After nearly two years of driving it, I still cannot determine what the series of beeps mean when I press the start/stop button, especially when I leave the car. Sometimes it’s telling me that I pushed it too few times and the car is still on but in accessory mode. At other times, it seems to be trying to tell me that the fob is still in the car when it’s actually in my pocket and on the way out of the car. But I have to stop and check the touchscreen display, which is sometimes difficult to read in bright sunlight. It’s even more fun when my spouse is driving the car and I forget that the fob is in my pocket. I usually dash off before it starts beeping in very much the same way as the “your car door is open” warning.  (Turns out you can still drive the car without the fob, but you cannot restart it once you turn it off.) However, it’s annoying to have to stop what you’re doing and determine what beeping means when a simple ignition switch is a definite known state when leaving a car.

In defense of the humble toggle switch, once it’s flipped, it’s real status is visible and dependable.

You can send button status and the input from many devices over communications busses like SPI and I2C, or over plain old I/O pins, but regardless of the distance traveled, communications over SPI and I2C is not 100% error free. If you have an input device that uses SPI or I2C, such as a DAC or an ADC, the best scenario is to have a way to check the reliability of the signal, such as with a checksum in the protocol. Or a DAC could have a serial output pin so you can verify the data that it’s receiving and digitizing.

If these methods for ensuring ongoing reliability are not available, you will have an error at some point, albeit infrequently (depending on how many times the MCU communicates with the connected ADC/DAC/other device). The error can last for as long as it takes to overwrite the erroneous data, which can be milliseconds or days. You do need to consider the consequences of the rare but possible incidence of incorrect data if you do not have some means to read back or check the data sent over a communications protocol that could be susceptible to noise, dirty power, or what-have-you. If you have bounce in an input device, you can end up with a repeated input. If you do not have any tactile feedback, it’s possible that someone could hit the button twice. In some design cases, duplicate input may not matter. Some duplicate input can cause a redo of a process that is expensive to re-do.

The glory days of toggle switches, such as what populated early space travel the Gemini capsules, are over. Toggle switches are just not as sleek and elegant as capacitive touch input or buttons with a membrane cover, but in some cases, buttons are still used for critical functions, especially in areas like space flight.