I have read that whenever we write program for push button we need debounce period. But in this program LED toggle without debounce time
Code:
#include <reg51.h>
sbit SW = P2^1; //Connect switch to P2.1
sbit LED = P1^7; //Connect LED to p1.7
void main (void) {
while(1)
{
while(SW==1); //switch is not pressed
LED = ~ LED; //Toggle LED Status
while(SW==0); //switch is not released
}
}
When should I use debounce time for the Push button
Code:
#include <reg51.h>
sbit SW = P2^1; //Connect switch to P2.1
sbit LED = P1^7; //Connect LED to p1.7
void Deboune(unsigned int x);
void main (void) {
while(1)
{
while(SW==1); //switch is not pressed
Deboune(30000);
LED = ~ LED; //Toggle LED Status
while(SW==0); //switch is not released
Deboune(30000);
}
}
void Deboune(unsigned int x)
{
unsigned int k ;
for ( k = 0; k < x; k++);
}
Contact bounce is a mechanical effect caused by the elasticity of the switch contact material. There is also a similar phenomenon caused when switch contacts exhibit resistance when partially closed and an indeterminate voltage is dropped across them.
Either way, a far better solution than just adding a delay is to read the switch several times and only proceed when it's state hasn't changed for long enough. I have no idea how long your "Deboune(30000);" delay lasts but my guess is it is far longer than necessary. Reading several times with a short delay between them will let the program continue as soon as the switch is stable instead of using a fixed long period every time.
far better solution than just adding a delay is to read the switch several times and only proceed when it's state hasn't changed for long enough. I have no idea how long your "Deboune(30000);" delay lasts but my guess is it is far longer than necessary.
One problem you will encounter (in the future if not now) is that your delay function can very easily be optimised by the compiler to a 'nop'. You are far better off to use any delay functions/macros that your compiler will supply or to write your own based on a timer.
The advantage of a timer approach is that you can use it to drive an interrupt that will do the input pin sampling and debounce, setting an internal variable to the debounced pin state and you can then just sample that from within your program.
The reason you might think your original program is working without the need to debounce is that debouncing can take the length of time you say to complete but the bounces themselves can be microseconds apart. As you eye can respond to flashing images down to about 30Hz or 33msec. Therefore your eye will smooth out the very high speed flashes and you will see the toggling that you do with the switch only. However, if you used a scope on the LED (or the button) then you would see it responding to the higher speed bounces.
Susan
Expanding on what Susan advises, how do you know "Deboune(30000);" is 30mS?
A software delay loop is just a repeated sequence of instructions to waste time, how long it takes will depend on many factors. The main one is the clock frequency but consider that your routine also contains code to allocate memory for the variable 'k' and some 16-bit math routines. Even if the compiler doesn't optimize the code or even remove it, you could find that the math produces a longer delay for 29999 than 30000 for example.
A timer is a far better solution and polling the switch to check it has stopped bouncing will give reliable results. If you can use interrupts to detect the switch state, thats even better.