Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to ask a question that has been on my head for a while

I have done coding small ISR's for pic and AVR controllers and i have successfully tested them on board.And i have just learned some days ago that you need to keep ISR short.

So I have this ISR that runs each 2 ms from timer.

Well the doubt I have is If I have an I2c communication running parallel and then the interrupt occurs, What will happen to the I2C communication.

Will the data transmission gets damaged?.

If The ISR takes 2ms to execute, what will happen to the I2C communication meanwhile.

Can it cope with such delays? Or is it my lack of understanding.

share|improve this question
Correctly-implemented I2C is forgiving of timing delays (see: clock stretching). If your CPU supports interrupt priorities/levels, then you should configure them so that the higher priority task is not interrupted by the lower one, assuring it will finish what it's doing. – John U Feb 25 '14 at 18:28
Can you clarify - is your ISR taking 2ms to execute or is it being serviced every 2ms? If it's both then you have a problem. – Josh Feb 26 '14 at 0:05
up vote 5 down vote accepted

The processor won't execute any foreground code during the interrupt. If the IIC is strictly handled in hardware, then that won't matter. If this processor is the IIC master, then it won't matter either since you own the clock and can go as slow as you want (most slaves allow this).

However, a interrupt routine taking 2 ms with other things going on, like IIC communication, at the same time sounds like bad overall architecture. The right answer is to step back and understand what all the processor needs to accomplish, what limited set of things really are low-latency that it must react to, and re-architect the firmware from there. Propagating a bad design by working around previous mistakes just makes things even worse.

share|improve this answer
+1. You've beat me to it. I was about to post a very similar text. – Nick Alexeev Feb 25 '14 at 17:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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