AVR Freaks

printf() still won't work

What do you mean "does not work"?

Re-read the datasheet section on external interrupts.  Pin-change interrupts trigger on both edges.  EICR has nothing to do with pin-change interrupts, does it?

Also, if using a button to test, buttons bounce so you will get typically several pin-change "hits" every time you press the button.

As others have said I think you really do need to take a step back and do some datasheet reading before jut throwing some random bits of C into your text editor. Good programs start with good design. That means reading and researching the background of what you wan to achieve. Then sketching out some strategy of how you are going to achieve that. Then adding more detail to that until you know the exact sequence of steps you need. Finally you start you text editor and write some C that matches the design/specification you have come up with.

The opposite technique of "grapeshot C" where you throw a few lines of C into an editor, build/try that. It doesn't work. You go back and remove that stuff and throw some more random lines of C into your editor is not a great approach. It's said that an infinite number of chimps at an infinite number of typewriters may eventually end up typing the works of Shakespeare - but it could take a while!

As I review this thread it seems you are pretty intent on using PA7 as your "input". While I would question the choice of that if you really do mean PA7 then the datasheet tells you that the only uses of PA7 (apart from the obvious one as GPIO) are either ADC channel 7 or Pin Change  interrupt 7. I'll assume you intend to use it as the latter. So next you would find out about pin change interrupts. In my copy of the 164/324/644/1284 data that is in chapter 13 under "External Interrupts". That chapter is possibly a little confusing as it talks about two different kinds of external interrupt. The INTn type and the PCINTn type. As PA7 is only PCINT7 then anything relating to INTn is irrelevant and that includes anything you read about "rising edge", "falling edge", "level interrupts". A PCINT signal is not that sophisticated. In fact it is very simple indeed. You can turn it on for one or more pins and then if the signal input to those pin(s) changes from 1 to 0 or 0 to 1 you are notified. Nothing more, nothing less.

When you read about PCINTn (not INTn) you find that they are grouped in 8's. Singals PCINT0..PCINT7 are related to PORTA, PCINT8..PCINT15 for PORTB, PCINT16..PCINT23 for C and PCINT24..PCINT31 for port D.

Unfortunately Atmel also made a very unwise choice of also using PCINT0..PCINT3 to be the names of these four groups of 8. So sometimes PCINT2 (say) will refer to the 3 pin of PORTA and sometimes it means "the complete group of pins for PORTC". So you have to watch for this!

Now when you read section 13.2 about "Register Description" you will see mention of EICRA, EIMSK and EIFR. You should ignore these - they are only involved with INTn, nt PCINTn. All the registers that relate to the PC (Pin Change) interrupts start with the letters PC - those are PCICR, PCFR, PCMSK0, PCMSK1, PCMSK2, PCMSK3. The first two of those have control for all four groups of PC ints (Ports A, B, C and D) while the PCMSK registers each relate to a single port. PCMSK0 for A, PCMSK1 for B, PCMSK2 for C and PCMSK3 for D. So if you are only interested in PA7 then the only three of these registers you need concern yourself with are PCICR, PCMSK0 and PCFR (though you may never read/write the latter at all in fact!). In PCICR there are four active bits PCIE0..PCIE3. Because it is PA7 on PORTA you are interested in then of these it is only PCIE0 that will concern you. By setting it to 1 you arrange to potentially get a pin change interrupt from any pin on PORTA as it "turns on" the signals from PORTA. However if you set that alone nothing would happen. As well as turning on A as a source you have to say which of the pins in A you are interested in hearing about changes from and you do that with bits 0..7 in PCMSK0. As it's just PA7 then the only bit there you want to set is bit 7 (that the datasheet calls PCINT7). So to use pin change interrupts on PA7 you now know your C is going to be:

int main(void) {
    PCICR = (1 << PCIEO); // switch on "A"
    PCMSK0 = (1 << PCINT7); // just get interrupts for pin 7 in A
...

And that is pretty much it. Now when PA7 changes the PCIF0 bit in PCFR will be set. So without using interrupts you could use:

int main(void) {
    PCICR = (1 << PCIEO); // switch on "A"
    PCMSK0 = (1 << PCINT7); // just get interrupts for pin 7 in A
    while(1) {
        if (PCFR & (1 << PCIF0)) {
            // pin has changed: do something
            PCFR = (1 << PCIF0); // clear the flag
        }
    }

but usually you want to do something else in the while(1) and get notified about the pin change separately (in which case you can ignore PCIFR all together as bits getting set in it automatically trigger a switch to your ISR code). So you would use something like:

int main(void) {
    PCICR = (1 << PCIEO); // switch on "A"
    PCMSK0 = (1 << PCINT7); // just get interrupts for pin 7 in A
    sei()
    while(1) {
    }
}

ISR(PCINT0_vect) {
    // could get here for any of 0..7 on A but as only 7 is enabled
    // it must be a change on PA7 if we get here
}

Notice that the interrupts (there are potentially 4) are called PCINT0_vect, PCINT1_vect, PCINT2_vect and PCINT3_vect. Each one relates to a whole port. Not a single pin. So changes on PA0..PA7 might trigger PCINT0_vect. changes on PB0..PB7 might trigger PCINT1_vect and so on. This is where that choice of Atmel's to use PCINT0..PCINT3 to mean two different things can be confusing.

So, did you see what I did in all that? I read the datasheet. I figured out what were the salient details and what were the details to be ignored. I then determined that for that salient stuff what I would need to put into each register and finally I created some C code that put actions into words.

Having said all this I am not sure if it is PA7 and PCINT0 you really want to use. As I say this can only give interrupts for a CHANGE. It won't tell you what kind of change (0->1 or 1->0) - you would have to work that out yourself (by reading PINA after the interrupt occurs). A "more powerful" form of external interrupt is the INTn ones. They can give you interrupts for different conditions like only 1 to 0 transitions (falling) or only 0 to 1 transitions (rising) or the pin being held in a low or high state (level)

Your most recent code mentions "rising edge". If you really are going to be specifically looking for rising edge changes then forget PCINTn and PCICR, PCIFR, PCMSKn completely. You need to switch to focus on EICRA, EIFR and EIMSK but if you do that you need to relaise that the 324 chip only has three of them. They are on pins PD2, PD3 and PB2. So if you are going to use one of them you have to arrange for your input signal to route to one of those 3 pins. This is a decision you should be making early in the design process - not while you are already typing C code into your text editor.

Johan, not sure of the point you are making? My post was a response to #6 (and indirectly #1).

in #6 I see him providing an ISR for PCINT0 but then messing with (the totally unrelated) EIFR within it. Equally in hw_setup() I see it messing with register relating to PA7 (which could be right) but also EICRA (which seems wrong - especially since EIMSK is then never touched).

I see you and Lee "discussing" the actual intent of the pin reading (wake from sleep or something else) but that seems to be a tangent to the core intention of simply getting ISR()s for pin activity.

My main point was not even the actual mechanism to achieve this (pin reading) but the importance of a methodical approach to design and avoiding "grapeshot".

OK. It looked as if you where misinterpreting my post as being done by the OP. (I was in a narrow browser at the time where one can not see the avatars, and just had the gut reaction that you saw it the same way. Stupid me..)

I actually like it - on the rare occasions I access freaks on the 'droid phone. There would be very little room left for anything else if the avatars where there. I agree that the limit for when they occur/disappear seems to have been set a wee bit conservatively.

If you're really plagued I could see if this can be fixed by injecting some CSS to override what is being fed from the server. What browser on your tablet?

What I really miss is that I don't get to see the "n new" links in listings. Grrrrr...

Try a few Ctrl-minus, or whatever your browser command for "zoom out", until the print doesn't get any smaller.  Do you get avatars then?  In my Firefox, they disappear when I "zoom in" far enough...