none of this will be news to you, but it's probably of interest to other people reading the discussion. you can do stuff inside the interrupt handler itself, and while what you do there does have to be an event-driven explicit state machine, interrupts introduce two key differences:

- the rest of your program doesn't have to be an explicit state machine; it can use structured control flow with nested loops and conditionals and subroutines

- the interaction between the interrupt handlers and the rest of the program is almost completely asynchronous, because as long as interrupts are enabled, the interrupt can fire between any two instructions of the rest of the program; if you look at it as multitasking, it's preemptive multitasking rather than cooperative multitasking. preemptive multitasking introduces a lot of hairy error cases, and this is only moderately simplified by the fact that the rest of the program can't preempt your interrupt handler, only vice versa. arguably that makes the problem worse rather than better because you can't solve the problem with locks (except by disabling interrupts as a sort of global lock)