Go Down

Topic: Interrupt programming (Read 979 times) previous topic - next topic

adamatcooranbong

Hi Guys,

After an interrupt has been executed, does the program go back to the line of code it was executing before it was interrupted or after the attach interrupt line?

CrossRoads

It goes to the next line in my experience.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

James C4S

It returns to where the interrupt occurred, executes one more instruction (machine code instruction, not "line of C"), and then either services the next (queued) interrupt or continues running from that point.

Capacitor Expert By Day, Enginerd by night.  ||  Personal Blog: www.baldengineer.com  || Electronics Tutorials for Beginners:  www.addohms.com

adamatcooranbong

Thanks guys.

Do you guys know if interrupts will affect time critical code if you use a scheduler library (Arduino Due) to run multiple loops?

I need to run four tachometers while collecting vibration data which is the time critical part.

haturi

Since you wrote "or after the attach interrupt line?" , I think you are expecting interrupt immediately after the attachInterrupt() call.  That can happen if either of following is true:
1.  Before attaching, you did not clear any pending interrupt at NVIC (Nested Vector Int Controller) AND there was an interrupt pending,  So, it makes sense to clear such stray ints beforehand.
2.  You programmed your device to interrupt before issuing attachInterrupt().

As far as where it resumes after interrupt, remember the rule James C4S said.

For time critical apps you need to compare timings of different things.  The DUE runs at 84 MHz => Cycle Time = 11.905 nanoseconds (worst case w/o considering pipeline, pre-fetch, etc.).  Most assembly instructions (machine codes) on DUE executes in 1 to 2 cycles.  So, in 1 microsecond, the cpu executes roughly 55 such assembly codes.

The moment your device raises the interrupt, it will not register to the cpu at that same femtosecond!  I suspect a bunch of nanoseconds would pass before your first line of ISR (interrupt service routine) executes EVEN IF THE CPU WAS NOT EXECUTING ANY HIGHER PRIORITY ISR.  That is interrupt latency.  Not sure what it is for DUE.  Needs a scope, a test program and some well-placed wires between DUE, scope and your device.

So, if your vibes are spaced microseconds apart and that's what you want to capture using ISR, the DUE may not cut it.  You need much faster cpu.  A typical compiler would produce 3-15 assembly instructions per C line.  So, a 10 line C-level ISR can amount to 2 microseconds of execution time.

You can take a look into the scheduler code.  Everything is open source in Arduino.  Then the timing details would emerge.
Hope this helps.

Go Up