On Thu, Jun 24, 2004 at 04:48:34AM -0700, Emrah Bozkurt wrote:
> Hello,
>
> How can I make debunce in the code? And what is it
> exactly?

Let's talk about bounce. As must as designers would like for mechanical
switches to cleanly transition from one state to the other, due to simple
physics, it doesn't happen that way. When you switch a switch, the metal
will make contact, then separate, then make contact again, then separate
again until eventually the contacts finally settle together. This transistion
period will generate a lot of make/break transistions. So instead of a clean:


00000000001111111111111111

Where 0 is the previous state of the switch and 1 is the new state you get
instead

00000000000X1010011000110011001111111111Y11111111

The intermediate state is called bounce.

Now if your software is tracking that switch and doesn't take bounce into
account, it'll look like you pressed the switch a bunch of times when in fact
it has only been pressed (or switched) once with bounce.

The vast majority of tools to get rid of bounce, called debouncing, relies
on the fact that it is transitory and that bounce will eventually stop. The
simplest and most effect way to debounce is to simply wait after the 1st
transistion and check the switch again after it should be stable. It involves
creating a delay between first contact detection and actual checking. So
in the sample above the delay would start at point X and the switch would
be checked at point Y when it's clear that any bounce has cleared.

A second way which I use mostly, is to act upon the first transistion, but
then create a timeout where the switch won't be checked again until the timeout
has elasped. I like this way because then switch response is instanteaneous.
The problem is that this way is a bit more susceptable to noise. But a good
stiff pullup/pulldown usually will hold the input pin stable until the actual
switch is manipulated. So my code will act at point X but set a timeout
such that the switch cannot be checked again until point Y. So again the bounce
is skipped and only on transistion is seen.

Now delays and timeout can be a challenge. The naive way of handling it is
to actually delay and have the PIC do nothing else. However a slight more
sophisticated way to do it is to have a big main loop that checks everything
that you're tracking (switches, displays, sensors, etc.) run by a timer
that ticks. When a certain number of ticks elapse go through the loop and
check everything. But for the switches (and other items) if there is a timeout
in play, don't do the check and decrease the timeout. Eventually the timeout
goes to zero, and you can check again.

I used this technique in my sunrise/sunset outdoor light controller here:

http://www.finitesite.com/d3jsys/clock.asm

Check out the settick/main/dodisplay section which defines the main tick
loop attached to timer 1 (32768 Hz crystal driven with a 16 second timeout)
The loop runs every 4 ticks of the timer which ends up being very close to
1ms. When the switch transistions, switchdelay is set to 64 counts which
means that the switch won't be checked for 64 ms after a transistion.

I hope this gives you some insight into the process.

>
> And where will I exactly put
>      org 3ffh
>      retlw 80h
> instructions in my code ? Thanks a lot.

Just before the END and the END will be fine.

BAJ

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu