Your professor is either wrong or is doing a poor job at explaining the concept. A debounce isn't just a delay. If it were just a delay then we'd call it a delay. There is a difference between a debounce and a delay and that's why they have different names.

A simple debounce can be thought of as a delay during which time you verify that the signal has stabilized. If at any time during your debounce delay your software detects that the signal has changed then you assume that the signal hasn't stabilized and reject it as a false reading--you immediately exit the debounce delay and go back to your main loop that waits for a keypress. You only accept a signal as being valid if it remains stable for the entire length of your debounce delay.

This page has a nice discussion on debouncing which says pretty much the same thing I say in this post. Feel free to refer to it if anything I say in this post doesn't make sense.



The delay only needs to be long enough to allow for the signal to stabilize. I believe I've seen 50ms mentioned here on the site recently. 1 second would be extremely large. I can't imagine you'd need to go beyond 100ms or 200ms.

But, again, the delay itself will not serve any purpose unless the code within the delay is verifying that the signal status does not change during the delay period.

One other thing worth mentioning is the question of what will happen if you press and hold down the button? As your code is written now your LED will turn on and off every 250ms or every second, or however long you have your delay set to. Normally when you read a button there are essentially two debounces: One is the hardware debounce which makes sure the keypress you received is real and not just electrical noise--this is what we've been talking about and is consistent with the idea of the "signal stabilizing." The other is the the human debounce or "throttle" which prevents the program from detecting a button press and treating it as two, five, or twenty button presses. Since the program is going to run much faster than you can press and release the button it's entirely probable that a single button press can cause the program to toggle your LED many times. Maybe that's what's happening now? You press the button and the program is toggling the LED so quickly that when you let go of the button and it stops toggling it may have ended up back in its original state or may end up in the opposite state. Thus you may have the illusion of the LED doing weird things when really it's just toggling faster than you can see.

When it comes to debouncing the human or "throttling" the input what you can do is first wait for a valid signal. That means you debounce for 50-100ms and if the signal indicates the button was pressed the whole time then you assume you have a valid input. Once you have a valid input you toggle your LED. Then you execute a loop which does nothing more than wait for the button to be released. As long as the button is still pressed you keep looping. As soon as the button is released you go back to your main "DELAY" section of the code which will wait for the next keypress.



I'm not much into flowcharts myself, but here's what you're looking for in English.

1. Did you detect a key press? If not, repeat this step.
2. Clear time counter.
3. Is the key still pressed? If not, go back to step 1.
4. Has the debounce time (100ms) passed? If not, go back to step 3.
5. Now we have a valid keypress. Toggle the LED.
6. Is the key still pressed? If so, repeat this step.
7. The key has now been released so go back to step 1.



In the interest of your grade be careful not to offend or insult him in the process. :)



Thanks for stopping by and keeping us posted. We get a lot of people here who ask questions, lots of people respond, and the person never comes back and we're left thinking we wasted our time responding. It's refreshing having someone making an effort to understand this stuff and who keeps coming back.

Please keep us posted!

Regards,
Craig Steiner