Debounce routine not working

[rems]

PIC16F887 //EDIT--The code I am trying is actually in the 3rd post. The following will not return a value as it is marked as "void" my mistake
I have a very bouncy switch in dire need of debouncing. I am trying the following to remedy it with out success.

[PCM programmer]

[rems]

You are absolutely correct. I copied the wrong code out. The following is what I use and does in fact compile with no errors. I added a bitset to it.

[PCM programmer]

My comments are placed above each section of code.

[rems]

I can't believe I forgot my exclamation mark
"if(!input(pin_B2)==1)"

I know the code is probably needlessly complex. I don't know enough to make it simple. I figured I didn't need the "bitset" but when it wasn't working, I thought I'd better try something that I have seen work before. Meanwhile, I had made a silly mistake the whole time.

Thank you for pointing out my blunders. I learned a lot. I will go back to the original and try again. I just wasn't sure if the "break" would go back to where I wanted it to. So I took it out and tried using the "return" Now, I realize it will contradict the "while".

I will keep trying. Thank you so much for your time and advice.

[ckielstra]

[rems]

I appreciate the advice.
I have my debounce to where I think it really should be working but it isn't.

Does anyone have any thoughts or suggestions. The following is an excerpt from my code.

[jeremiah]

I don't expect wait_for_keypress_1() to work well the way you have it. Prior to calling it, you check:

[rems]

It still doesn't work. I am concerned it may be due to how I think the "break;" will perform. Will it break to where I think?

void wait_for_keypress_1(void)
{
char count=0;


while(1)
{
if(input(pin_B2)==0)
{
count++;
}
else{
count=0;
}

if(count == DEBOUNCE_COUNT)
break;


delay_ms(DEBOUNCE_PERIOD_IN_MS);

}


}
void wait_for_keypress_2(void)
{
char count=0;


while(1)
{
if(input(pin_B3)==0)
{
count++;
}
else{
count=0;
}

if(count == DEBOUNCE_COUNT)
break;


delay_ms(DEBOUNCE_PERIOD_IN_MS);

}


}

int8 scanfaces(void)
{
int led_output=0;
int face;

// ************************************Configuring cage to sense faces

output_low(PIN_B1);

//************************************ Checking Face 1

if(input(PIN_B2)==0) {
wait_for_keypress_1();
bit_set(led_output,0); // will it break to here?

}
else {
bit_clear(led_output,0);
}

//************************************ Checking Face 5
if(input(PIN_B3)==0) {
wait_for_keypress_2();
bit_set(led_output,1); // will it break to here?


}
else{

bit_clear(led_output,1);
}
Thank you for your help

[jeremiah]

All break does is take you out of the most current loop or switch statement. So it will simply jump to right outside your loop and continue from there.

[rems]

Okay, Great...I get it...So no wonder it isn't working...So it would just start "scanfaces" again and go back to the "keypress" function. Just a big loop.
Maybe I should have the "wait_for_keypress" function return a value and then check for that value in my "scanfaces" function? But then I couldn't loop my _wait_for_keypress" function with the "while(1)". Would a "for" loop be better in my "wait_for_keypress" function to work with some sort of "return"?

[jeremiah]

The benefit of how you did it is that you skip the last delay_ms() call when you have a good number.

Just for clarity's sake, this is a visual of what break does:

[rems]

I have a very bouncy switch. It is homeade and literally has a ball within a cage that has 6 possible positions to be in. I need to debounce each of those positions. When the ball is in position, an i/p is sensed "LOW" and the debounce should start. In the debounce, I want to check and recheck that the i/p is still low. I may need to do this several times or just increment the delay between checks. Like I said it's a very bouncy switch.

Here is my complete code.

[RF_Developer]

The basic idea is that your main while loop just goes round and round. It checks if things need doing: it checks buttons, it checks for incoming data that needs to be processed, it measures, it outputs stuff and so on. None of these things should ever wait anything other than a few tens of us or so. Instead they check and if nothing to do they do nothing in that loop.

Most of the time your main loop does nothing much. Only if something needs servicing: display needs updating, someones pressed a button, a message had been receved, a timed event has been flagged up and so on; does your main loop actually do any processing. That means you'll check (or poll) everything on every loop.

So. you never "wait for a key press". You note a key has been pressed; if so do stuff and set a counter so that the keys will be ignored for say 50ms worth of loops before looking at the keys again. Longer for your caged ball switch. Using a timer, or clock tick based software timer will help there.

With debouncing there actually isn't much point in checking the contact is still where you first detected it after a time. The bounce happens when a contact is first made or broken and then for a while un-makes or un-breaks repeatedly. So only the first detection is relevant, then hold off from making further detections for at least the longest time you'll get bounce, which for some switches (and it varies from switch to switch of one type and from one type of switch to another) may be longer than 100ms.

Your caged ball will be tricky as normal switches work with some form of spring arrangement that biases them in to on position or another. The ball however relies on gravity alone, and it may get dirty and not make good contact. Have you designed the ball switch to be break-before-make? If so then you should be able to check it goes to a "none connected" state between one face and another and so, if it does go into the "none" state and back then nothing has really happened... or has it? How you interpret that is dependant on your application. You almost ceratainly can't do that if you are multiplexing the pins with another function.

This is the simplest form of "co-operative multitasking". Where each thing that has to be done: e.g. detect keys, update display, read serial, measure voltages, send formatted data, is regarded as a seperate task and your loop is the most simple form of round-robin scheduler. No "task" should ever wait if it can help it, and certainly not if it has nothing to do. Even ADC reads can, if required, be started on on loop and read back on the next, eliminating the need to wait for the ADC to convert. I have one simple app that does this. Though I confess on my others waiting for the ADC typically forms the greatest single time in the overall loop execution time.

RF Developer

[rems]

A lot to think about...That is some great stuff for me consider. With a lot of hard work and dedication to this stuff, I will eventually understand and appreciate everything you wrote.
I will keep at it.
Thank you for your insight.