I have done software debounce logic with 2/3 voter logic and kindly verify the coding i don't no whether it is correct or not. Please help me
Coding:
void inputRoutine() { uint16_t temp; InputP1_Temp=P1&0x00; for(Index1=0;Index1<MAXINPUTS;Index1++) { temp=debounce(Index1); if(temp==1) { Input_TableP1[Index1]=1; } else if(temp==0) { Input_TableP1[Index1]=0; } } } /***************** -- Debounce Port P1 -- *****************/ bit debounce(uint16_t IN_INDEX) { uint16_t INDEX2,ONE=0,ZERO=0; char TEMP,SHIFT_RESULT[3]=0x00; for(INDEX2=0;INDEX2<3;INDEX2++) { TEMP= P1; SHIFT_RESULT[INDEX2]=(TEMP>>IN_INDEX)& 0x01; delay_10micro_sec(); } /* Comparision of 3 values retreived from same pin*/ for(INDEX2=0;INDEX2<3;INDEX2++) { if(SHIFT_RESULT[INDEX2]==1) ONE++; else if(SHIFT_RESULT[INDEX2]==0) ZERO++; } return (ONE>ZERO); }
With Thanks, G.Karthik Ragunath
A resistor and a cap will change the behaviour. But if the input pin doesn't have schmitt-trigger, then the bounces can still get the filtered signal to vary enough to make the input signal toggle multiple times between low and high.
As a matter of fact - all uses of external RC filters should be avoided unless the input has hysterese. Not only can you get multiple toggles, you can also get the input to consume a lot of power when floating in the dead zone between a logic high and a logic low.
Besides: A software bug can be corrected by a firmware update. A hw problem - such as too high/low value on a component - is very hard to compensate for. You may have to send the unit in for modification.
The important thing here is that most mechanical switches are quite easy to debounce since the bounce time is short in relation to the expected number of switch activations/second. And since the debounce is so easy to do in software, there is no real need to figure out ways to let the hardware help.
As a matter of fact - all uses of external RC filters should be avoided unless the input has hysterese. one more reason to avoid RC filters is that it slows down the input. Many moons ago (before the micro, with a mini) I did some investigation on RC filtering and found that (for this particular app, how general I do not know) sufficient RC filtering made the thingy fail to respnd to the "fastest fingers"
And since the debounce is so easy to do in software, there is no real need to figure out ways to let the hardware help. I second that opinion
Erik