Recently .. arrhhmm actually its almost a year now, I jumped ship into ARM, TI M4F core to be exact, still slow in progress, and during learning, I was in awe with ARM's power, like when I understand NVIC for the 1st time, and was thinking why not just slap in everything using interrupt as its powerful (compared to 8 bit mcus), noob's journey I guess.
Now reading that thread I pointed, to experience fellows, please, enlighten us noobies like me on using interrupt at mcu, discuss please, like the pro, con, when, where etc .. or never ?
Where/when: if you need to react to some event immediately.
Pro: you can react immediately (well, maybe not, that depends).
Con: using too many interrupts enormously complicates things.
An interrupt can occur at any time. If e.g. your program is reading a variable larger than the processors wordsize (i.e. it needs more than one machine instruction to read it) than the value of that variable may change *while it is read*, if the ISR is changing it. Some hardware fiddling may be sensitive to timing, so you need to remember to disable interrupts for it.
ISRs may nest, with priorities, or they may not. Either way, predicting the worst case timing becomes "interesting", and with non-nesting ISR or priorities the "react immediately" thing may practically disappear.
Depending on the actual workings of the program nasty things like dead-locks and race conditions (the "variable changes while read" is an example of that) can occur.
So I say use interrupts when you really need to for hard technical reasons. Don't overuse them, that turns nasty, fast. The human mind just isn't built for dealing with multiple things (potentially) happening in parallel.
I also have hardware de-bounce so I don't have any debounce code slowing down the ISR.
Interrupts are very important and many times there's no alternative than to use them.
interrupts are hard to be debugged if you do not have a true ICE
The best thing about understanding and using interrupts is - event driven programming...
(look it up)
Once you've mastered when to use them, your code will make a lot more sense, and functions become called (usually) in a more logical strategy.
I guess it also prompts you to think more carefully about variable scope, factoring and use of functions in general...
i think 8,16 and 32 bit variable are written in 1 operation in 32 bit MCU, so it can't be interrupted and when on other processor try to read it , it will end up with a correct value not half old half new value. am using STM32 a lot, and been asked to prove that , i can't find any information on ST document.
You may find the answer in an ARM architecture reference manual. If the processor saves the return (from interrupt) address as the next instruction to be executed then that would indicate that the currently executing instruction when the interrupt occured will be completed before branching to execute the interrupt service routine.
If it were possible to get into a situation where a variable is only partially updated by an unfinished instruction execution then the architecture would have to provide a means to detect it. Otherwise it would be chaos. That doesn't happen.
The short answer is that all computers are interrupt driven, all the time.
-first i do know now that higher priority interrupt will be always be executed even if the processor is handling an other lower priority interrupt ( that explain for me some good unexpected behavior and some weird unexpected behavior )
-first i do know now that higher priority interrupt will be always be executed even if the processor is handling an other lower priority interrupt ( that explain for me some good unexpected behavior and some weird unexpected behavior )
Beginners often don't understand the causes (and ways to avoid) "priority inversion".
High reliability computers, very simple computers, and those with tight or predictable latency requirements tend to be based around polling.
Are there good examples or scenarios, that you just can NOT escape from using interrupt in your previous projects ?
assert(now<deadline);
won't hurt at ret.
Interrupts are very important and many times there's no alternative than to use them.
They can always be avoided, but your hardware might make it impractical.