Good deal. All Things Are In The Datasheet
To be honest I didn't want to get too bogged down in detail, although interrupts can be complex enough. Also, I haven't done much with pin change interrupts. I regard them as a bit of a "fallback" if you can't use the dedicated interrupt pins. There are a few pin change libraries around, it could be helpful to check them out. A problem, if it is a problem, is that libraries tend to hide what is really happening from you. So a library can be great if you want a quick solution, but not so great if you want to understand what is really happening.
Some details I would add:
Other reasons to use interrupts:
- to wake up from sleep mode (you mention it but not so prominently).
- super agressive performance optimization, not checking loop conditions but using timer interrupts to terminate loops thus allowing to optimize the check condition out of the code into the hardware
I've amended the page a bit to incorporate both of your suggestions (Udo and Jack), that is, the pin changes, and the waking etc.
The interrupt event queues will hold at most 1 event per eventsource
The page currently mentions that, as follows:
The ones that set a flag could be regarded as being queued, as the interrupt flag remains set until such time as the interrupt routine is entered, at which time the processor clears the flag. Of course, since there is only one flag, if the same interrupt condition occurs again before the first one is processed, it won't be serviced twice.
Thanks for the feedback.