Hi
need to do i software debounce
have a 16f1509, and input at timer0.
found this on the net.

// Service routine called by a timer interrupt
bool_t DebounceSwitch2()
{
static uint16_t State = 0; // Current debounce status
State=(State<<1) | !RawKeyPressed() | 0xe000;
if(State==0xf000)return TRUE;
return FALSE; 
}

Can someone explain how this Works, and how to implement it.

i will setup an interrupt routine, when a switch is pressed at pin to timer0.
but then what NeXT,
when key is pressed it shold just add 1 to a number,, that part i know how.

 

this looks like "smeared" debounce signal (i used it in FPGA).

you take a 'word' (any size, 8, 16, 32 bit) and keep shifting it periodically (maybe every 1ms or so). depending on shift direction, one of the bits (msb or lsb) will be lost on every shift. the idea is to feed input state into bit on the other side of the word (lsb or msb). this way bits in a word represent history of the bit-signal used as input.
signal with bounce at first has most variations which then decay into a steady state when bouncing stops. you can use mask to remove unwanted bits or simply look for particular value in the word. depending on wanted response time, sample frequency and if you look for on or off state of the input, you can decide on value to compare with to determine if input is on or off.
usually mechanical bounce of the contact is something that goes away in 5-15ms.
suppose you choose 10ms as good enough for your input and you sample at 1ms for example. lets say we use 16-bit word as buffer and input is fed into LSB. that means that MSB is the oldest sample (16ms old). then about 10ms after switch is "made" you would get something like:
0000010011011111
notice that at first we got bunch of zeroes, then mix (bounce) then steady stream of ones. if we wait long enough all bits will turn on when input is "on". you can choose bit pattern that works for you - for example 5 consecutive bits on or whatever you like.
in that case AND result with 0x01F and compare to 0x1F. if you want at least 10 consecutive bits to be on, you AND and compare with 0x03FF etc.
one can also simply check if word equals (or different from) zero (depending on level you try to detect).

that worked well on FPGA and may or may not be the most efficient implementation on a MCU (specially low powered ones).

 

There is another debounce thread currently active, it is here;
http://forum.allaboutcircuits.com/showthread.php?p=658646

 

have think of this.
can i enable an IOC on one PIN and then make an interrupt.
i the routine, it would start a timer, if not allready running,
the timer should be abouth 20 ms, i think,
when timer is finish, it Counts++.
should that not be possible. ?

 

have think of this.
can i enable an IOC on one PIN and then make an interrupt.
i the routine, it would start a timer, if not allready running,
the timer should be abouth 20 ms, i think,
when timer is finish, it Counts++.
should that not be possible. ?

Why count? What uses this count?

Besides, interrupts should be reserved for things that need immediate attention, unlike buttons that can be handled when you get around to it.

 

how, when should i deal with buttons, the inpus comes from an external switch, (rain gauge) so it's a quickly on/off. and if i can the inputs in main, i could be in that case that it not registrate the input, cause program is doing other Things.
that's why i think of doing it by interrupt,
Have done it by TMR0 as counter, but it Counts bad, (sometimes 10 Counts at a time, sometimes just 1, ) and chip sometimes reboots , think it is cause of overload, dont know why,
have a hardware debounce, but it does not seems to Work.

have the input with pull up 10k, and capatisitor across the switch,

 

It would be a good idea to post a diagram of the circuit and the power supply. There are other issues to deal with if the MCU is rebooting unexpectedly.

 

Here is the scematics, Powersupply is from 230v to a stable 5v.dc.
The powersupply Works ok, no problems when using 16f690, but that pic is to small now.

Edit forgot file

 

First off you need bypass caps for the PIC. One 0.1 uF minimum as close to the Vdd & Vss pins as you can. Same for the LCD but that is more to keep it from emitting junk the being sensitive to it. Also a nice big cap, 10uF, and tantalum if you can, but that's the belt to go along with the suspenders.

The cap may help with the random reset. That can happen from many sources, bad code among them.

It appears you have circuitry so you do not have to debounce the 4 button inputs. You could do this in code instead of with hardware (all you save are the caps) but I'd rather depend on that as I can change code faster then I can change caps.

Where is the rain gauge?

 

the rain gauge, is the "switch" to the left, input RA2.
have now searched the net, and have found that a resistor in serie with RA2 should prevent the reset,
I mounted a 10 k, in serie on RA2, and now i do not have any resets, and the rain gauge Count as it should, so problems should be fixed now.
btw, have no bounce problem with the four other switch, maybe cause good quality.

 

have now searched the net, and have found that a resistor in serie with RA2 should prevent the reset,
I mounted a 10 k, in serie on RA2, and now i do not have any resets, and the rain gauge Count as it should, so problems should be fixed now.

ORLY? I wonder why that would work as that line doesn't pass any current except for a fleeting instant.

btw, have no bounce problem with the four other switch, maybe cause good quality.

Or your code take long enough so it doesn't "see" the glitch, or the RC value eats the entire event, or...

ALL switches bounce. It's inherent in the physics. All. Final answer.