Go Down

Topic: About interrupts ... (Read 978 times) previous topic - next topic

Jack Christensen


Great, that is the info I was missing.  Nick, it would be great if you could add that stuff about the masking to your writeup. 


Good deal. All Things Are In The Datasheet XD  Nick might want to stop somewhere short of replicating the whole thing though. I could see maybe a general discussion of interrupt mask and flag registers because they are a recurring theme, but I'm not sure he wanted to get down to the bit-biting level. OTOH it can be difficult not to do that when playing with interrupts. Not sure which way is best.

Quote

I don't really have a problem ... (which is to say, I haven't tried it yet ...)


Haha, I like that!  Might have one of those t-shirts around here somewhere!
MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Udo Klein

Great work. 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


The interrupt event queues will hold at most 1 event per eventsource


ISRs will be much slower to start if processor has to wake up from deep sleep - because the oscillator needs to stabilize.




Check out my experiments http://blog.blinkenlight.net

Nick Gammon


Good deal. All Things Are In The Datasheet XD 


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:

Quote

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. :)

kf2qd

Interrupts VS polling - SPEED

For a routine that has to run NOW like an encoder input.

If anyone has experience programing other devices or computers - Interrupts are like events in Windows and other operating systems. The program doesn't have to wait for the interrupt event to happen but can continue doing whatever, and the interrupt routine will do its thing when the interrupt condition (HIGH, RISING, FALLING, LOW, CHANGE) is met.

Msquare

Oh, I wanted to write that... just skimmed it now, certainly seems comprehensive (when is it too large and when is it the essentials?). I happened across one part at the end: Yes the Arduino 1.0 DOES use interrupts to handle Serial output as a background activity. (checked the core code). So you comment about believing it, can be less relgious :)

Great work.

Go Up