You need to see if you can shorten that interrupt routine- they need to be as short as possible, because other interrupts may be waiting, or even missed- you should just get the data you need and let your main code deal with any data manipulation.

When you read a port "PORTC", you should instead read "PINC" (see section 13.2.4 of the datasheet)

I think that all the states should be volitile global variables, so that the main code can take some functionality from that interrupt routine.

Sorry if I sound unconstructive from time to time - this is due to some needed comic relief :-)

What is bouncing? When a switch is closed, it will shortly reopen after that due to mechanical elasticity, this is the same as if you let go a ball to the floor which will bounce many times until it rests. The length of this bouncing phase differs greatly between switches, not only between brands but also between specimen, and also depends on age and wear.A "last bounce" can even happen 100ms after the switch is pressed.

Note that there can be no bouncing when a switch is re-opend, but there is a similar though much shorter electrical effect.

It is considered good practice in software debouncing not to wait until the bouncing is over, but to immediately act at the first edge because you know that the key has been pressed!

Now after some internal activities are over you are wait.ing again that the key has been pressed. You can be in of three situations:- The key is still bouncing- The key is still pressed- The key is already open

How to handle this depends on whether you look at a rising edge - often leading to an interrupt - or if you are polling looking at the level.

The solution of BetterSense is excellent, if the time of "do stuff" is long enough to have left the bouncing phase.

Generally there will be no advantage whith interupts. At the place where you check the dummyVar-flag you can as well read digitalInput(). (Except the key press is very short and you are in danger to miss it!)

The tricky thing comes when the processing of the keypress event is over. Now you have to look for an open key phase, long enough so it cannot be confused with a bounce spike (those spikes are very short btw and in fact difficult to probe without edge sensitive hardware...)

In cases when you can poll regularly, you can use a state variable openCounts to know that a resonably open time has passed

Well debouncing a switch contact efficently inside a ISR is kind of tricky, as there could still be a lot of useless interrupts being generated from the switch bounces. If it could be debounced with a external filter components it might make for a simpler more reliable system, just saying....

It is considered good practice in software debouncing not to wait until the bouncing is over, but to immediately act at the first edge because you know that the key has been pressed!

It is considered good practice in electronics to make sure that the circuit is not experiencing Impulse noise and giving a false reading. You don't know that the first edge is due to the button being pushed: Instead, you should recheck a short time later to see if the input is still high.

Generally speaking, debouncing applies to many places, other than switches.At this stage I may explain (taking the risk to bring some confusion) that my personnal approach to Arduino is to try to challenge it using the minimal number of external components. In the case of the rotary encoder, I did not even use the recommanded filter (RC, 10 k + 10 nF wired to ground)! So that I tried to apply a software only solution to the bouncing problem. And it works fine. I would not obviously recommend that for military/medical devices )Back to bouncing in general, I remember very well a very nicely written paper in Measure (the internal newspaper at HP) dealing with pulse recognition from magnetic heads in 10 Mb disk drives (which were as big as washing machines ): this was the starting point of my interest to signal recognition. Since then I paid strong interest to that, applied to other purposes (I am actually lecturing this science from times to times at university). But the techniques in use for such debouncing techniques require a lot of real time analysis and high tech ressources. Thus my choice for having a little fun with a minimalist approach (Way back to Occam razor)

It is considered good practice in electronics to make sure that the circuit is not experiencing Impulse noise and giving a false reading. You don't know that the first edge is due to the button being pushed: Instead, you should recheck a short time later to see if the input is still high.

You said that just to be funny, right?If you expect noise or spikes of TTL level in your line, we are no longer talking about "de-bouncing", but about "de-glitching" or how you want to name it. There are of course techniques to address both at the same time.