Using buttons in an automotive environment.
eagletalontim
Posts: 1,399
I have a project that requires the use of several buttons in a vehicle. Since switching from the SX28, I have had strange issues with buttons on the Prop. Using the SX, I would have 1 5v power output wire that would connect to all buttons, then one wire from each button feeding back to the circuit. To make things easier and use less wire, I have decided to go with a 10K pull up resistor attached to the "button pin" on the prop. Each "button pin" has it's own 10K resistor. All the resistors are connected to the 3.3V rail. This would enable the ability for the buttons to be wired to my circuit with 1 wire, then the other pin of the button tied to the vehicle chassis.
What I am having an issue with is occasionally, a random button circuit is triggered without a button being pressed. Would adding a small cap to the prop pin to ground help prevent this from happening? How could I determine the capacitor value? Would a non polarized ceramic cap work, or would I need to use a polarized cap?
What I am having an issue with is occasionally, a random button circuit is triggered without a button being pressed. Would adding a small cap to the prop pin to ground help prevent this from happening? How could I determine the capacitor value? Would a non polarized ceramic cap work, or would I need to use a polarized cap?
Comments
Or if you have an actual switch that needs debouncing, there are ways using simple logic chips.
Bean
If you can use two wires twist them and ground one besides the board while the other goes to the input pin.
There is some very nice stuff about that in the low level measurement handbook from keithley. The PDF is downloadable for free.
Massimo
I have seen debounce logic that only filters out repeated pulses from "ringing" but not the initial short duration pulse that is in fact noise.
A human pressing a button is typically of much longer duration anyways and we are still talking fractions of seconds so resonse is normally not an issue.
CogSaver
Here's an example of a routine (it blocks, so be aware of that) to debounce multiple inputs.
pub debounce(ms) | btns, t btns := %1111 ' "arm" inputs t := cnt repeat ms waitcnt(t += clkfreq/1000) ' wait 1ms btns &= !ina[BTN4..BTN1] ' invert for active-low return btnsIf ina[but] == 1 waitcnt(100_000 + cnt) If ina[but] == 1 do stuffAnother option could be to check for 0 in between the 1's:
If ina[but] == 1 waitcnt(50_000 + cnt) If ina[but] == 0 return 0 If ina[but] == 1 waitcnt(50_000 + cnt) If ina[but] == 0 return 0 If ina[but] == 1 return 1That is a good idea. I did not think about checking twice for a button press. Thanks for that tip!
That's what my debounce routine does; if there's a drop-out during the scan window the button is not counted as pressed/closed. This process seems to eliminate high-speed transients.
I don't think I've done a very good job of describing it but it works for me.
Sandy
Is there a recommended debounce time?
Here is the debounce code :
User_Setting3 := 100 ' I have tried everything between 10 and 100. Still not stable... if ina[upbutton] == 0 btndown := debounce(User_Setting3, upbutton) if btndown == 1 ' Do stuff here if ina[downbutton] == 0 btndown := debounce(User_Setting3, downbutton) if btndown == 1 ' Do stuff here PUB debounce(ms, button) | downcount downcount := 0 repeat ms pause(1) if ina[button] == 0 downcount++ if ms - downcount =< ms / 2 ' if button down count is at least 1/2 the debounce delay, return as good return 1 else return 0pub debounce(pin, ms) | dbtimer, t dbtimer := 0 t := cnt repeat ms waitcnt(t += clkfreq/1000) ifnot (ina[pin]) if (++dbtimer => ms/2) return 1 else dbtimer := 0Remember -- as I was recently reminded -- if you don't specify a return value a method will return 0, hence we don't have to spell this out.
My code looks for ms/2 consecutive button presses; your version does not hence may be allowing noise to pass.
This is the approach I use as well. It's easy to implement without blocking too.
(MC14490) that used counters for de-bouncing the buttons. Just as you guys are describing with software, it was very effective. It is a cool
chip with an internal clock that could be used for clocking other logic.
Power supply failure (cracked pcb traces, etc) can make your computer crash (blue screen of death) showing memory or parity error and it is not the memory. It is power supply.