0
\$\begingroup\$

I am using a timer interrupt for multiplexing however my question relates more closely to interrupt service routines.

If I set the prescaler and turn on a timer, using the below code I can run code asynchronous to the main loop at a certain interval depending on the prescaler. Or at least this is my understanding of it.

ISR(TIMER1_OVF_vect) { //code to run asynchronously at a certain interval }

Now if for example I set my timer to interrupt every millisecond (16000 cycles on at 16Mhz AVR) and the code I run takes for example 2 milliseconds to execute; is the code completely executed by the second timer interrupt. That is, does the next timer interrupt depend on the previous one completing and could having slow code slow down an interrupt?

I am using an Atmega328P-PU with an external 16Mhz crystal as clock.

\$\endgroup\$
  • \$\begingroup\$ Your question needs more context. For instance, what AVR chip are you using? However, regardless of what chip you're using, it should be indicated in its instructions manual on how to utilize the ISR and its recommendations of setting it up. \$\endgroup\$ – KingDuken Jun 13 '18 at 3:54
  • 1
    \$\begingroup\$ Despite the good general advice so far in the comments, there is a glaring unaddressed problem in your question: You can't cram \$2\:\text{ms}\$ of work into every \$1\:\text{ms}\$ of time. Period. Can't be done. (Of course, if you only need to do that much on rare occasions and can afford the price of delaying and/or missing the next event that's supposed to happen \$1\:\text{ms}\$ and \$2\:\text{ms}\$ later, then perhaps. But that's not how you wrote your question.) \$\endgroup\$ – jonk Jun 13 '18 at 4:40
  • 1
    \$\begingroup\$ @JackCreasey The OP wrote "..set my timer to interrupt every millisecond ... and the code I run takes for example 2 milliseconds to execute." Doesn't fit. Of course, there are nuances. But I parenthetically waved a hand at those already. \$\endgroup\$ – jonk Jun 13 '18 at 7:11
  • 1
    \$\begingroup\$ @Maple Where was a pre-emptive O/S mentioned? I may have missed that context. \$\endgroup\$ – jonk Jun 13 '18 at 8:41
  • 1
    \$\begingroup\$ @jonk Nothing as complex as that. I supply software for a company making custom AT devices. When you have a dozen 200W servos and as many other sensors working simultaneously you are bound to face task management problem eventually. \$\endgroup\$ – Maple Jun 13 '18 at 9:53
3
\$\begingroup\$

The next interrupt code will not execute until the previous one has finished. If you generate interrupts every 1ms and your handler takes 2ms to execute then your main function will not run at all. Long ISR execution times are usually an indication of very bad code.

\$\endgroup\$
3
\$\begingroup\$

To answer your actual question, the next interrupt will not happen until you execute RETI instruction, because global interrupt flag was cleared in hardware before entering your code.

So, yes, the next interrupt depends on the code in your ISR.

Having said that, the question like this should not have happened because there is something fundamentally wrong with the code which makes it possible.

\$\endgroup\$
0
\$\begingroup\$

If you are using standard optimalization (for size) and dont set any special flag about interrupt (for example ISR_NAKED), compiler after jump to ISR save registers with processor state and prevent to jump to any other interrupt routine (globaly disable interrupt). You may write ur own code (for example as insert asm volatile ("asm code"); to do nested interrupt. After code is execute in isr routine compiler store processor register state, enable interrupts and do "reti" (return from interrupt). If interrupt controller achive signal with new interrupt when processor execute other isr, interrupt controller wait to processor end and rise new isr after old was done. If for example timer0 rise interrupt flag twice or more while other isr routine is pending, isr for timer0 will be execute once after old was complet. Last state is when isr routine is pending and two other source singals rise simultaneously, then firstly will be execute isr for signal with lower id (0 is for reset).

PS: sorry for my english, i try to be better.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.