As a general design principle the use of time delays within ISRs (interrupt service routines) should not be done. You should evaluate the design philosophy and come up with a way that you do not have to put delays inside of the ISRs. In particular if the supposed need for these delays is due to certain I/O timing requirements you should split up the I/O handling into a series of short task states that can be executed one at a time in sequence. Then allocate a global variable to act as a state variable that can tell you which is the next of these I/O timing tasks is the next one that needs executing. Finally setup a timer interrupt that has the job of invoking each of these I/O tasks in its turn. The timer interrupt can use the state variable in a switch statement to select which I/O task to run at the current timer interrupt and then increment the state variable as appropriate.

I use this scheme all the time in my code and set the timer interrupt at a basic 1 msec interrupt interval. If some of the I/O task states need greater than 1 msec interval between then I add another counter variable next to the state variable that is used to count down a series of 1 msec timer ticks before the next state I/O task is launched.

A goal should be to keep the actual work done by each I/O task state as short and simple as possible. Doing so the timer interrupt that processes this state machine can be be a very low percentage duty cycle load on your MCU. This eliminates the bandwidth that is burned up with current scheme by trying to put delay calls inside the Interrupt routines.

The implementation of the delay routines is another whole subject and I will comment on that in another posting.

Michael Karas