Debounce routine not working

[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.