Mechanical input devices are far from obsolete, and an IC like the BD3376MUV-M can help you with the interface details.

Despite the growing popularity of capacitive touch sense and other non-mechanical means of gathering user input, mechanical buttons and switches are still common components in everything from hobby projects to sophisticated electronic systems.

However, mechanical switches are examples of the paradoxical nature that is surprisingly common in scientific and engineering disciplines. Science has acquired a staggering quantity of information about exceedingly complex aspects of the physical world; and yet, it cannot adequately answer questions that we might hear from a seven-year-old child: Why is grass green? (Black would theoretically be more efficient because it absorbs more solar energy.) What is the universe made of? (We know almost nothing about dark matter and dark energy.) Why do I have to go to bed? And why do I get nightmares? (Researchers still don’t really understand why we sleep and dream.)


The Pushbutton Paradox

And then we have the less profound but by no means irrelevant paradox of the pushbutton. What component could be simpler than a pushbutton? You push the button, the voltage changes, the microcontroller detects the change, done deal—you have a user interface. Well, it turns out that lots of things are simpler than a pushbutton; let’s take a look at the challenges:

  • Switch bounce. You can ignore it, but it’s still there. Always there. When two conductors come into abrupt contact, the electrical connection makes and breaks a few times before settling into a steady state. Thus, one actuation turns into several actuations.



  • A typical open/close type of switch or button is exactly that—either an open circuit or a closed circuit. Thus, you can’t simply connect one side of the button to logic high and then connect the other side to a microcontroller GPIO. That works fine when the switch is closed, but when it’s open, you have a floating input, and that is always, always bad—unless the pin has an internal pull-up resistor, of course. And we’re assuming CMOS here; theoretically TTL doesn’t have the same problem, but as far as I can tell TTL doesn’t really exist anymore, despite the (in my opinion) bizarre tendency to use “TTL” when referring to normal logic-level signals as opposed to, say, USB or LVDS.
  • Despite their simplicity, pushbuttons can be a burden on firmware. Designers are expected to get more and more performance out of tiny microcontrollers, and thus it’s not a great idea to waste processor cycles constantly checking input pins to see if the pushbutton has been pressed. This problem becomes more severe if you have multiple buttons, or if you are implementing debouncing via firmware instead of hardware. It certainly helps if you can use interrupts instead of polling, but pin interrupts are limited, and you might prefer to use them for something else.


The IC Approach

The BD3376MUV-M from ROHM Semiconductor is described as a “multiple input switch monitor.” Here’s the typical application circuit:


Diagram taken from the datasheet.


The idea here is to move the irksome switch-interface details to an external chip. The BD3376MUV-M monitors the switch inputs, and when actuation is detected, the microcontroller is notified via SPI.

Overall I think this is a great idea. The BD3376MUV-M can monitor 10 pushbuttons, and a similar part (the BD3375MUV-M) can handle 22! This approach allows you to monitor numerous buttons without wasting processor bandwidth, and it also effectively serves as I/O expansion. My guess is that many embedded systems don’t have 22 or even 10 available GPIOs, but with these ROHM parts, all you need is an SPI bus.


Two Out of Three

The BD3376MUV-M addresses two of the three difficulties mentioned above. The processor is freed from excessive pin-checking, regardless of the availability of GPIO interrupts, and the switch inputs have internal pull-ups (they’re actually pull-up current sources, not pull-up resistors):


Diagram taken from the datasheet.


You will still have to implement your own debouncing circuitry. However, I would argue that the BD3376MUV-M indirectly resolves the switch-bounce problem because it explicitly includes debouncing circuitry in the typical application circuit found on the first page of the datasheet—and they even include component values!


Diagram taken from the datasheet.


So right there on page one we have a reminder and enough design information to eliminate almost all intellectual effort on the part of the engineer.



Have you ever designed a system that needed 22 pushbuttons? If not . . . what have you been doing with your life?