@alter_kaker The basic theory is, an interrupt can happen in the middle of other calculation, and change variables that the compiler didn't know might change, and optimised your code with the assumption that they wouldn't. If you mark the variable as volatile, then the compiler will refrain from such an assumption, and translate every reference to the variable into an independent fetch.There's also the concern that the environment you get to run your interrupt handler in might be harder to understand, or more limited, than most. A very common issue is, you might not have a lot of stack remaining in an interrupt handler. Similarly, your outer data structures might be in the middle of manipulation, in an incompletely updated state, during the interrupt. So, the general recommendation is to do as little work in the interrupt handler as you can reasonably get away with, and instead, just raise a flag suggesting that the work needs to be done, and then processing that flag later. This sort of flags are the canonical example of variables that must be marked volatile.I wouldn't rely on being able to register a dynamically bound method as an interrupt handler, at least without checking whether the specific framework specifically promises to support this. Interrupts are kind of inherently global things, so if you rely on this, it must be looked up somehow, and naïve implementations might just lose it, leading to weird crashes. Interrupts have some similarities with things like, say, JavaScript events, but they're a lot more primitive inside.Sorry if I missed it — what is it that you're doing?@project1enigma
