Go Down

Topic: Debouncing switches connected to PCF8575 (Read 759 times) previous topic - next topic

adwsystems

Does any bother debouncing switches connected as inputs to the PCF8575 I2C I/O expansion chips? I have written a generic routine to debounce each, any, and all digital input pins directly connected to the ATMEGA328 chip. I'm debating if I need to go so far as to expand or create one from the inputs on the PCF8575 I2C I/O expansion chips.

Grumpy_Mike

About 90% of the time in real programs you do not need any debounce at all, it is a mistake to always include it.

The rest of the time a simple 20mS delay after a contact closure is detected is good enough. Note you only get a bounce on a contact closure and not a contact release.

adwsystems

#2
Sep 06, 2017, 04:59 pm Last Edit: Sep 06, 2017, 05:00 pm by adwsystems
About 90% of the time in real programs you do not need any debounce at all, it is a mistake to always include it.

The rest of the time a simple 20mS delay after a contact closure is detected is good enough. Note you only get a bounce on a contact closure and not a contact release.
I have found that 90% of the time 90% of switches and/or relays need to be debounced. It is not true that only contact closure needs to be debounced. Unfortunately there is no rule of thumb unless you are an expert on the internal mechanical of the switches and/or relays you are using and have the design drawings from the manufacturer. It is based on the type and/or design of the switch or relay and you usually don't find out about it until it is too late. Rotary switches are particularly susceptible to "bounce" on contact release. According to C&K, this is due to the internal design and the human interaction. "If they the switch is not rotated sharply" (their words; ie., rotated slowly) bouncing contacts on release is possible and likely. Similarly for slide and momentary pushbutton switches.

That's all the debounce subroutine is, a delay after initial change in value. But the current one I have written only works on the ATMEGA328 pins and would have to be adapted to work on the PCF8575 pins.

Grumpy_Mike

Please yourself, you are wrong of course but their you are. Also you drag in much more detail about the actual switches in that post than you ever did in the origional one. I guess you must be a mind reader but not a good enough mind reader to know I am not one.

What makes a delay call work for a 328 processor pin but not an 8575 pin? Don't bother telling me you will be wrong again.
Good bye.

adwsystems

#4
Sep 06, 2017, 05:51 pm Last Edit: Sep 06, 2017, 06:17 pm by adwsystems
The OP was in an inquiry for opinions on whether the dry contact inputs to a PCF8575 should also be debounced. Based on the purpose of the thread it wasn't necessary to muddy the question with talk of the details on the differences between how switches are made. I am simply looking for a variety of opinions on whether or not I should bother to write a debounce subroutine for inputs to the PCF8575 chips.

I agree a simple timer 20-100 milliseconds (personal preference) is enough to debounce a dry contact input. As for the difference between the ATMEGA 328 pin and a PCF8575 pin as related to a timer, as you ask, nothing. (since you noted I my answer is wrong, what is the correct answer). The difference is matter of reading a "pin" versus reading a "port" The ATMEGA328 pins are read as pins (yes I know they can be read as a port, but my routine works on pins) where as the PCF8575 pins are read as a port and have no option (I know of) to be read as a pin, therefore requiring me to rewrite my debounce routine to work with a port instead of a pin. Not really a issue, just more work.

There was detail in the response not relevant to the OP that is incorrect, most notably
About 90% of the time in real programs you do not need any debounce at all
and
Note you only get a bounce on a contact closure and not a contact release.
I'm not sure what aspect I'm wrong about. Perhaps the percentages and we can debate your and my 90%, maybe 75%, maybe 98%. The need to debounce a dry contact input largely depends on the switch mechanicals, the purpose of the switch, and the effect of catching the bouncing/changing signal will have on the system. In combining those factors, in my experience, results in the need to debounce almost every switch.

Wawa

#5
Sep 06, 2017, 11:24 pm Last Edit: Sep 06, 2017, 11:27 pm by Wawa
Needed or not needed depends what the code does with that button press.

A 100n cap across the switch could also fix bouncing.
And a cap also doubles as RF pickup suppressor.
Leo..

Go Up