AVR Freaks

I think you could use a set of 8-bit variables for each port.

incrementing 3 bit counter

0 0 0

0 0 1

0 1 0

0 1 1

1 0 0

1 0 1

1 1 0

1 1 1

0 0 0

bit2 toggles when both bit0 and bit1 are 1, else it stays the same.

On that basis, my first attempt would be

cnt2 = cnt2 ^ (cnt1 & cnt0)

But I haven't worked it all through.

FWIW, I often use a 3 stage debounce.  It's fast and simple.  This is for 8 buttons, but extending to 16 or 32 is just a matter of changing the variable sizes.

// u8 is uint8_t
// call every debounce period, e.g. every 10 ms

u8 get_debounced_buttons(void)
{
    static u8 last1 = 0;
    static u8 last2 = 0;
    u8 raw, buttons;

    raw = ~PINB;    // or wherever your buttons are located
    buttons = raw & last1 & last2;
    last2 = last1;
    last1 = raw;
    return buttons;
}

This just gives the debounced buttons.  A tiny bit of extra code will give button push and release edges as needed.

Debounce should do more than just deal with the bouncing of the switch - there are other disturbances that should be filtered out. EMI and ESD can also find their way into the input and these can be a bit more tricky to filter out from a simple delay. 

For those of us that have put designs through the European CE tests will understand the problem. The average hobbyist doesn't need to comply with these requirements, so why bother with extra filtering? The reasons these tests were conceived still exist.

Just about everyone has a cell phone - these generate bursts of rf that can easily find their way into an unprotected input. 

How many posts do we see from people using interrupts for button or switch inputs complaining about random inputs?

If you want to build a robust device, it would make sense to follow industry norms. The old computing maxim - garbage in,garbage out applies. Any external input should be filtered and rejected if it is not what is expected. Be that a switch input, analog input, serial data etc. If the input is a switch, then that has physical limitations on how fast the state is expected to change. Debouncing/filtering should ensure these expectations are met.

If you're confident that the only way the reading can change is if the button is pressed or released (no weird gliches or noise), a single reading at an interval > bounce time is reasonable.

Say button can bounce for up to 10ms.

Take a reading once every 50ms.

If button was pressed just before a reading, you might read as pressed or unpressed as it's still bouncing.

If you catch it reading as pressed, fine, it's now pressed.

If you catch it as unpressed, fine, you will catch it as pressed on the next reading (assuming user holds it down long enough, not generally a problem).

Either way, it will have stopped bouncing by next read.

I am submitting the state machine code that I came up with years ago.  This state machine will debounce both the key press and key release.  I typically insert it into a timer isr that samples the buttons every 5-10 mS.  It has never failed me and I've debounced oodles of switches/buttons over the years.  Maybe someone will find it useful.

Take care - Jim

 //***********************************************
 //
 //  debounce state machine
 //  * execute in a 5 or 10 mSec timer interrupt
 //  * pb_deb is global variable
 //  * For Reference:
 //	8 push buttons on Port A
 //	(config as input w/internal pull-ups)
 //
 //***********************************************
void debounce(void)
{
     static uint8_t pb_last;
            uint8_t pb_now;

    //read the current button state (PORTA used as reference in this example)
    pb_now = ~PINA;

    //process the debounce filtering algorithm
    pb_deb = ( pb_last & pb_now)|
	     ( pb_last & pb_deb)|
	     (~pb_last & pb_now & pb_deb);

    //save the button state for the next sample period
    pb_last = pb_now;
}

Well yes, clearly it requires reading the input periodically.

The point is, with this most basic method, the state is determined solely from the current reading, rather than from a sequence of previous readings.

That is what is meant by 'a single reading'.

Clearly there is a risk if there is a 'glitch' at just the point you make the reading you could misinterpret that as a button press (or release).

That's why i said

Whether it counts as debouncing or not, depends on definition, OK it's probably better described as 'avoiding bounce issues by simply not reading the input fast enough to notice'.

A shift register means saving past states.  Were those states used in deriving button pushes e.g. through an AND gate?