I guess you can call me spoiled...I just drag & drop a de-bounce macro onto the schematic, connect it to the pin open the dialog box make a few settings (the default settings work most of the time) and move on.

(PSoC)

 

That's great for limited HID interaction but button presses are not all human in a benign environment. Mechanical quadrature waveform encoders on noisy electrical motors are a classic example.

That is a very different problem!

 

That is a very different problem!

No really. It's just switch debounce that can't be sloppy in the presence of noise. Several MCU types built for motor control duty have switch input debounce functions that operate on the same principles as software debouncing with timers and counters but they use internal dedicated hardware.

http://ww1.microchip.com/downloads/en/DeviceDoc/60001346A.pdf

The QEI module uses digital noise filters to reject noise on the incoming index and quadrature phase signals. These filters reject low-level noise and large, short duration noise spikes that typically occur in motor systems. The filtered output signals can change only after an input level has the same value for three consecutive rising clock edges. The result is that short noise spikes between rising clock edges are ignored, and pulses shorter than two clock periods are rejected. The filter clocks rate determines the low passband of the filter. A slower filter clock results in a passband rejecting lower frequencies. The digital filter is enabled by setting the FLTREN bit (QEIxIOC<14>). The QFDIV<2:0> bits (QEIxIOC<13:11>) select the filter clock divider ratio for the clock signal. Figure 43-9 illustrates the simplified block diagram of the digital noise filter.

 

That's great for limited HID interaction but button presses are not all human in a benign environment. Mechanical quadrature waveform encoders on noisy electrical motors are a classic example.
https://www.allaboutcircuits.com/projects/how-to-use-a-rotary-encoder-in-a-mcu-based-project/
https://www.bourns.com/docs/technic...nical-notes/Bourns_enc_sgnl_cond_technote.pdf

With a good quadrature decoder you don't need to worry about bounce here either.

 

With a good quadrature decoder you don't need to worry about bounce here either.

@AlbertHall,
You are right in that if one puts enough money into a quad decoder, then debounce is very much less needed,

But with rotary encoders being used as human interface, as in say your scope, these are not your many 10 of dollars encoders, but probably less than a dollar, and they do bounce.


In general,
IMHO,

all signals from the outside into the logic ( be that processor or digital logic ) the designer needs to be aware of the type of input, its "features" and its outcome.

For instance, take a digital clock ,
the same switch type could be used to increment / decrement the display
and another of the same type could be used to turn on a back light when pressed.

Now if the one that turned on the back light when pressed bounced, who cares.
But if the button that changed the display bounced, then numbers would jump by random amounts when pressed unless de bounced.

At the end of the day, its all down to engineering.
and the design compromise you make,

to go back to the clock example,
If you have plenty of space / resources, I'd put same de bounce on all switches,
If I was running into limits, One option I have is I could sacrifice the de bounce on the light switch if it made the design fit

If it was alrady in production, I might do the later, but if it was a new design, I'd try to put a more capable bit of logic in place,

its all engineering.

 

People keep wasting their time, I mean their valuable human time, with this. You don't need to debounce pushbuttons at all. Just set up an interrupt running at some rate like 25Hz and read the button state at every pass. That's fast enough that a human user won't notice a delay, but slow enough that any bouncing can die out between readings. If you don't want to set up an interrupt, you can poll a timer flag instead.

I have been watching videos, reading tutorial on switch bouncing But it's all over my head. I understood What happens if we press the buttons. When we press push button down, it wont make immediate contact, it will shift around a little bit! Like button is pressed multiple times. Button may make contact on and off for a few milliseconds before settling down to the state we want.

When working with microcontrollers,
I see in many place programmers do not care much about bouncing switches and just add a 50ms delay after the first bounce. Adding a delay force the controller to stop for a particular time period,


View attachment 237037


I don't understand PIC program given in tutorial https://www.allaboutcircuits.com/technical-articles/switch-bounce-how-to-deal-with-it/


In while loop, first we check the button if the button is pressed, increment BTN_press

I don't understand the logic of the rest of the code,

Did you get the answer you needed in the end ?

 

With a good quadrature decoder you don't need to worry about bounce here either.

I worry about everything on devices designed to interface with 20-30 yo equipment. Never tempt Murphy. Engineer devices to accept the worst possible signal and to output the best possible signal. This means you do worry about bad signals even from good encoders.

 

Did you get the answer you needed in the end ?

Yes I got explanation in post # 16

 

People keep wasting their time, I mean their valuable human time, with this. You don't need to debounce pushbuttons at all. Just set up an interrupt running at some rate like 25Hz and read the button state at every pass. That's fast enough that a human user won't notice a delay, but slow enough that any bouncing can die out between readings. If you don't want to set up an interrupt, you can poll a timer flag instead.

Don't be silly. 25Hz is a check every 40ms. A human can press a button and release it in 10ms. This is fundamentally why, if you're doing something like this, you should understand heuristics. You an stab at things and throw something that seems to work but can be made to fail, or you can understand the problem, all the parameters, and design something that is robust.

 

Can we have less of the personal stuff please.

I found this online article based on actual measurements, and the author ended up just as silly as I am:
https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-4/

But there's still a claim that some kind of software or hardware is needed for debouncing. The article's over a year old, but I thought of sending in a comment to suggest just reading the input at a particular rate like 50/sec, but you have to subscribe to do that. I wonder if there's some kind of superstition involved here, where people think it has to have some complexity or it can't work!

 

Here is one tutorial for Pic's
Page #6

 

I thought of sending in a comment to suggest just reading the input at a particular rate like 50/sec, but you have to subscribe to do that.

If you look now you will discover that someone has.

 

Can we have less of the personal stuff please.

I found this online article based on actual measurements, and the author ended up just as silly as I am:
https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-4/

But there's still a claim that some kind of software or hardware is needed for debouncing. The article's over a year old, but I thought of sending in a comment to suggest just reading the input at a particular rate like 50/sec, but you have to subscribe to do that. I wonder if there's some kind of superstition involved here, where people think it has to have some complexity or it can't work!

Wisdom is not making the same mistake twice and it's usually gained in a trial by fire. Many of us have been burned by debounce problems over the years. A preemptive hardware nuclear strike on the critical input debounce problem is what I usually do so I don't make the same mistake twice and need a software fix..

Good stuff, that debounce link was referenced here.
https://forum.allaboutcircuits.com/threads/software-debouncing.178625/post-1624535