AVR Freaks

        if(bit_is_clear(PINB,0)) //when button one  is pressed
        {
            PRESSED_CONFIDENTIAL_LEVEL++;
            if(PRESSED_CONFIDENTIAL_LEVEL > 80)
            {
                if(PRESSED == 0 && c >=0 && c < 999)
                {
                    c++;
                    if(PRESSED_CONFIDENTIAL_LEVEL > 400)
                    {
                        ++c;

                    }

                }
                PRESSED_CONFIDENTIAL_LEVEL = 0;
            }
        }

     if(bit_is_clear(PINB,1)) //when button one  is pressed
        {
            PRESSED_CONFIDENTIAL_LEVEL++;
            if(PRESSED_CONFIDENTIAL_LEVEL > 80)
            {
                if(PRESSED == 0 && c <= 999 && c > 0)
                {
                    c++;
                    if(PRESSED_CONFIDENTIAL_LEVEL > 400)
                    {
                        ++c;

                    }

                }
                PRESSED_CONFIDENTIAL_LEVEL = 0;
            }
        }

This code is clearly just "cut and paste". You have duplicated the same block and only changed PINB,0 to PINB,1 so a few things:

1) at least change the comment. They can't BOTH be handling "button one" !!

2) more seriously you just re-use c. Surely c is an ongoing counter as the while(1) loop runs that allows you to sample the button state multiple times until you are confident it is pushed. Well you can't use the same c for both the PINB,0 and PINB,1 cases !

3) same true for PRESSED_CONFIDENTIAL_LEVEL (and isn't it "CONFIDENCE" not "CONFIDENTIAL"??)

4) also do NOT use all upper case for C variable names. Reserve the use of all upper case for pre-processor defined macros. Just call the variable pressed_confidence_level_button_0 or something.

Oh I see "c" (bad name for a variable) is actually some kind of "display counter" and you want the buttons to either increment it or decrement it?

But you are still using PRESSED_CONFIDENTIAL_LEVEL for both buttons. Surely you need a counter for each.

Also the rate at which c increments or decrements seems to be dependent on when that confidence counter exceeds 80. Surely if you want faster increment/decrement you reduce the "> 80" limit ?

Well you can't have your cake and eat it!

Either you need a very long debounce period so you can't get that many presses or you want a fast update rate (in which case you need buttons that bounce less)

In the code that follows the button checking (apart from the other things it does) you have three calls to _delay_ms(1) so one loop round the while(1) is a little over 3ms. If you are counting to 80 to register a button press that suggests a settling period of about 240ms. So the best you can hope for is 4 or 5 counter updates per second.

240ms(+) does seem a VERY long time for button debounce. Most bouncing happens well within 50ms or less. So I'd say your debounce loops could be 4 or 5 times shorter so replace 80 with 20 or even 16 and it should still debounce.

Another approach is to take the button handling out of the software delayed while(1) loop all together. Instead run a ticker interrupt at something like 5ms or 10ms and consider buttons "Stable" after 5..10 interrupts where they are seen to have the same state.

As I say bounce normally settles in 10's of ms. Very unusual to be 240ms as your 3 * 80 would suggest.

One possibility is to use external components (R & C) to debounce the button so software doesn't have to if you want a "!"quick" resolution.

Otherwise look at timer based horizontal or vertical counters for an interrupt based debounce solution.