This is a very good app note and recommend anyone who uses interrupts in their project to read it.

The Interrupt Type parameter of the interrupt component seems a little misleading to me.  It appeared to me that setting it to "derived" was sort of an "auto" setting where the builder would automatically select either edge or level triggering as appropriate.  According to this app note, that is completely incorrect and that, for example, if I set my interrupt to "derived" that is based on my UART, it won't even work.  I'm glad that this app note clarifies this issue, but I think that it would be very helpful to reword the descriptions when setting the interrupt type in the component parameter window or even call the "derived" option something else like "fixed-function".

In the "My First Interrupt Project" example, i noticed that the global variable was not declared as "volatile".  Should not any variable that is being accessed by more than one process be "volatile"?

The storage-class "voilatile" tells the compiler to skip optimizations for this variable, because it may change its value from the outside (as pin-variables frequently do) This often happens when within a loop a variable is "read" (its value stored into another var, tested etc.) and the compiler comes to the conclusion that this access can be optimized-out which means that the access is not performed within the loop but once before the loop starts (which is not always what the programmer (we) would like to have).

Not only variables which are accessed concurrently from different processes/threads do need to have the special storage-class voilatile, but functiond accessed from different processes/threads must be declared as "reentrant" additionally, especially in the world of PSoC3 due to the limitations the 8051 processor comes with.

Bob