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,





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,

 

All I do is read the button every 50ms and take that reading as the button state. If, at that time, it is bouncing, then you may read the previous state or the next state. In either case it all be correct after the next read 50ms later. Just don't read it every 1ms or something like that or you can read multiple state changes.

That's all you need. No extra hardware. No complicated (ish) software. Just a 50ms timer.

 

As a mod to the 50ms read above, i use when the last 2 reads are the same, use that.

 

I usually just read each button, in the appropriate place in the software, once each time around the loop and branch accordingly. I don't worry about de-bouncing the result. The time taken to normally complete the loop takes care of that.

 

I usually just read each button, in the appropriate place in the software, once each time around the loop and branch accordingly. I don't worry about de-bouncing the result. The time taken to normally complete the loop takes care of that.

Yes, providing the loop is longer than the bounce.

 

Yes, providing the loop is longer than the bounce.

If the action required on actuation of a switch is momentary, as in incrementing a value, then a suitable delay between steps is needed. If it is selecting a steady state then no delay is required.

 

http://www.ganssle.com/debouncing-pt2.htm
A Guide to Debouncing - Part 2, or, How to Debounce a Contact in Two Easy Pages, by Jack Ganssle

https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-6/

I know this is about software debounce but for controller circuits built for industrial duty I would recommend a hardware debouncer chip on critical I/O designed to remove contact bounce from the controller inputs. Chips like the MAX6818 octal switch debouncer are designed to interface 8 debounced inputs with a single IOC interrupt that helps to simplify event based processing and eliminates timer-based polling delays.
https://www.mouser.com/datasheet/2/256/MAX6816-1514440.pdf

A chip I need to look at for I/O duty.
https://www.ti.com/lit/ds/symlink/tic12400-q1.pdf

 

If it helps.. I sound a buzzer... Keypress... Buzzer This does two things, tells the operator that the button was pressed and the buzzer sounds for 250mS which caters for any rubbish switch mechanism..

 

I am trying to figure out what happens in inside while loop

while (1)
    {
        // If BTN is pressed
        if (BTN == 1)
        {
            // Bouncing has started so increment BTN_press with 1, for each "high" bounce
            BTN_press++;
            // "reset" BTN_release
            BTN_release = 0;
            // If it bounces so much that BTN_press is greater than Bouncevalue
            // then button must be pressed
            if (BTN_press > Bouncevalue)
            {
                // This is initial value of BTN_pressed.
                // If program gets here, button must be pressed
                if (BTN_pressed == 0)
                {
                    // Toggle the LEDs
                    LED1 ^= 1;
                    LED2 ^= 1;
                    // Setting BTN_pressed to 1, ensuring that we will
                    // not enter this code block again
                    BTN_pressed = 1;
                }
                // LEDs toggled, set BTN_pressed to 0, so we can enter
                // toggle code block again
                BTN_press = 0;
            }
        }
        else
        {
            // Increment the "low" in the bouncing
            BTN_release++;
            BTN_press = 0;
            // If BTN_release is greater than Bouncevalue, we do not have a
            // pressed button
            if (BTN_release > Bouncevalue)
            {
                BTN_pressed = 0;
                BTN_release = 0;
            }
        }
        
    }
    return (EXIT_SUCCESS);
}

We wait for button pressed if button pressed Increment variable BTN_press++; and clear variable BTN_release = 0;

Why compare conditions (BTN_press > Bouncevalue)
How do you decide Bouncevalue?

 

You say " Adding a delay force the controller to stop for a particular time period, "
that is not true as such.

Its only true if you code it that way.

If the switch comes in via an interrupt,
or is read via a timer interrupt every n ms,
then the CPU does not stop.

 

I simplified my life by doing this:

When detecting a button / key pressed down, I start a (non blocking) counter. When the counter comes down to zero after 25 ms, I read that key / button again. If still pressed down, I count it as valid.

To be sure my soft was good, I used the worst keyboard I could find and it always worked with 20 ms. Just in case I added 5 ms and moved on.

 

I am trying to figure out what happens in inside while loop

For debounce routine you need two variables -one for button and debonce status and another for debounce counter. Then you can debounce the button in non-blocking manner in fast loops.

 

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,

Debouncing in software is easy- You need to change your perspective. The idea of a debounce is to ensure you have a stable reading. This by definition means 'over time'. What you need to do is:

1. identify how much time max that you have to determine if a signal is stable at a level, or not
2. Break that time up into 6 chunks
3. Those 6 chunks become 3 attempts to read the value

For example- you have 1/10th second to read the switch. That is 100ms. 100ms / 6 = ~16ms.

4. Read the voltage level and then wait 16ms. If when you read it, the level is high, increase a counter If not, don't.
5. Repeat step #4 three times.
6. If at the end of the 3 reads you have counted to 3, then the signal has been stable for a long enough time that you may assume it's good at state X (on or off). If your counter never got to 3, the signal is just spurious noise.

This gives you a basic, tried and true roadmap. Used in everything from nuclear fuel handling robotics to simple matrix keypad reading.

Hope that helps-

 

http://www.ganssle.com/debouncing-pt2.htm
A Guide to Debouncing - Part 2, or, How to Debounce a Contact in Two Easy Pages, by Jack Ganssle

https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-6/

I know this is about software debounce but for controller circuits built for industrial duty I would recommend a hardware debouncer chip on critical I/O designed to remove contact bounce from the controller inputs. Chips like the MAX6818 octal switch debouncer are designed to interface 8 debounced inputs with a single IOC interrupt that helps to simplify event based processing and eliminates timer-based polling delays.
https://www.mouser.com/datasheet/2/256/MAX6816-1514440.pdf

A chip I need to look at for I/O duty.
https://www.ti.com/lit/ds/symlink/tic12400-q1.pdf

Have you ever used the old 74C922? I did once.

 

This gives you a basic,
Hope that helps-

Bob Yes it is exactly what i was looking.
read the switch every 16mS.
Counter incremented if switch is pressed. When the counter reached a predefined value, in this case, 6, the button press was considered valid state.

I still haven't understood it completely because the code is confusing me.

I do not understand code if the button is not pressed then why decremented counter and why compare count with predefined value

 

Bob Yes it is exactly what i was looking.
read the switch every 16mS.
Counter incremented if switch is pressed. When the counter reached a predefined value, in this case, 6, the button press was considered valid state.

I still haven't understood it completely because the code is confusing me.

I do not understand code if the button is not pressed then why decremented counter and why compare count with predefined value

No.... to clarify, you only need to test for 3, not 6.

You debounce either way. button up or button down.

Here is a very crude flow-chart explaining the process. When you can't understand code, you need to flow-chart it, so the logic becomes clear. Anybody who is actually serious about programming will use such tools:



This is also the basic process for interrupt driven keyboard/keypad debounces (with another routine), and can be extended to support repeat-key, holding keys down, etc. If done with interrupts, no delay box would be in the flow-chart that would be handled by the interrupt timing.

 

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.

 

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.

Quite.
What a load of unecessary faff.

 

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.

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

 

You say " Adding a delay force the controller to stop for a particular time period, "
that is not true as such.

Its only true if you code it that way.

If the switch comes in via an interrupt,
or is read via a timer interrupt every n ms,
then the CPU does not stop.

Or if you time the delays by calculating the end delay time from the current microseconds plus the delay time and checking that the subsequent current microseconds is greater than the end delay time. By coding this test, your code can continue doing other tasks.