0
\$\begingroup\$

I'm using a hardware-based debouncing circuit to trigger an interrupt on a Particle Photon development board.

debounce circuit

I use a similar circuit with two buttons:

schematic

Sometimes when a button is pressed, the interrupt linked to the other button is also triggered. What is the reason for this behaviour? How to solve this issue?

\$\endgroup\$
  • 1
    \$\begingroup\$ 50/50 bet you have a single trace coming in from VCC to the capacitors? Is it long and/or winding? Also, drawing your schematic it is considered good form to draw your grounds low and supplies high. Your drawing is much harder to read than it has to be. \$\endgroup\$ – Asmyldof May 5 '16 at 0:24
  • 1
    \$\begingroup\$ Use GND instead VCC to turn on. It is better choice and common in projects around. \$\endgroup\$ – user19978 May 5 '16 at 0:37
1
\$\begingroup\$

It due to the charge in the capacitor.You connected the switch to VCC at time you pressed. Capacitor charged and after you released the capacitor discharged through the resistor.so the capacitor should discharged below VIL before you pressing another button. Better you follow the switching the Ground. For that you need to use pull up resistor.

\$\endgroup\$
  • \$\begingroup\$ (1) "... and after you released the capacitor discharged". Not correct. When the switch is pressed the capacitor is discharged. When the switch is released the capacitor charges again. (2) "So the capacitor should discharged below VIL before you pressing another button." Can you explain how one button interferes with the other? This is the original question. \$\endgroup\$ – Transistor May 5 '16 at 18:00
  • \$\begingroup\$ @Sathyanarayanan G, you have it backwards.... Like transistor says, the switch shorts and (violently) discharges the capacitor. Then the capacitor will hold the pin high until it is charged back up. That's when the pin goes low. Really, the better HW solution would be to use a SPDT switch and an RS latch. Forget this violently shorting out capacitor thing. Or use SW to solve this problem. \$\endgroup\$ – st2000 May 6 '16 at 1:37
  • \$\begingroup\$ i specified that "Better you follow the switching the Ground. For that you need to use pull up resistor". And if is not reached reached below VIL before you pressing another button the uC detect that both key pressed. \$\endgroup\$ – Sathyanarayanan G May 6 '16 at 4:53
0
\$\begingroup\$

What is this circuit supposed to do?

When 5V is applied with the switch open, the voltage at OUT is initially going to be 5V. Over some time the capacitor is going to charge to have 5V across it and OUT will be 0V. When the switch is closed, the capacitor is going to discharged instantly through the switch. Over time this will likely damage the switch and possibly the capacitor as well.

Perhaps something like this would be better:

schematic

simulate this circuit – Schematic created using CircuitLab

In this circuit the resistor between 5V and everything else, you can see right away that there is no possibility for large currents in/out of switches, capacitors or microcontroller gates.

UPDATE: Actually this is not true because the capacitor discharged instantly when the switch is closed so that will put stress on the switch and capacitor. So as described below I would remove the capacitor entirely and implement the debouncing in code.

Although I don't know how well the 100nF capacitor would work as a debouncing circuit. For one thing, when you start up, it will initially be 0V and take time to charge up. But otherwise it might work.

In practice I would leave out the capacitor and implement debouncing in software. Specifically, you get the time with millis() and compare that to the last time the button was pressed. If that time is not exceeded, you ignore that change in state. This is how it is done and there are numerous examples of how to write code that handles momentary button debouncing.

\$\endgroup\$
  • \$\begingroup\$ Short-circuiting the cap is not a good idea. \$\endgroup\$ – JimmyB May 5 '16 at 17:43
0
\$\begingroup\$

I prefer doing as much in software as possible. I think you can also debounce your switches only using software. And, by doing so, avoid the problems you are seeing (which, I think, are due to the high current involved when discharging the capacitor through a dead short).

I think you can get by with only a switch to ground and a pull up resistor to 3.3V all tied to the interrupt pin. As soon as there is a state change the interrupt gets called. That is, if the interrupt gets called on the falling edge. (If interrupts get called on the rising edge just flip the switch to 3.3V and the resistor to ground.) At that point I would test the Arduino millis() value. If very different I would execute the interrupt code and record the current Arduino millis() value. If the switch bounces and causes another interrupt, I am safe as I first check if millis() returns a value very different from that which I recorded last I serviced the interrupt. If it is not very different I know that not enough time has passed and I skip over running the code in the interrupt and skip over updating the saved millis() value from when I did run the code in the interrupt.

I do have to ask, however, why you are executing interrupts based on a human pushing a button. Interrupts take a bit of care to setup. And the payoff is your interrupt code gets executed (usually) with little delay. But, where people are concerned, a simple polling program is fast enough. And much simpler to implement. So why interrupts?

If you do go the path of polling, take a look at this debounce-button-software-solution.

\$\endgroup\$
  • \$\begingroup\$ How do you know how long his minimal delay between polls is? \$\endgroup\$ – Joel Wigton May 5 '16 at 17:26
  • \$\begingroup\$ That depends on how quickly you want to be able to press the momentary button and have it react. At some point the delay is short enough that a) you DONT want it to react and b) you can't hit the button twice fast enough. \$\endgroup\$ – squarewav May 5 '16 at 17:59
  • \$\begingroup\$ You need to pick a delay (and switch) that works for the application. Picking a switch that only bounces for a short amount of time is best. Picking a switch that slides into position (making many contacts) would be a terrible choice. If the switch settles out after a few mS then that is how long you wait until the software looks for the opposite switch action. \$\endgroup\$ – st2000 May 6 '16 at 1:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.