interrupt routine code length

[dave.t]

Hi all,

I have a 8 level switch statement in a interrupt service routine
which completes 8 tasks in 8 interrupts and so on. I noticed in a previous Question (not mine) Hans commented on to much code being in an interrupt routine. Does this matter? After all - the program jumps to the interrupt address and completes the routine - then back to the main program. I am a bit worried now that i am going to have problems whith my code - which does function well - and have had no problems. I would appreciate any comments as I am self taught and somtimes miss things!

Dave
___________________________
This message was ported from CCS's old forum
Original Post ID: 12334

[Neutone]

:=
:=Hi all,
:=
:=I have a 8 level switch statement in a interrupt service routine
:=which completes 8 tasks in 8 interrupts and so on. I noticed in a previous Question (not mine) Hans commented on to much code being in an interrupt routine. Does this matter? After all - the program jumps to the interrupt address and completes the routine - then back to the main program. I am a bit worried now that i am going to have problems whith my code - which does function well - and have had no problems. I would appreciate any comments as I am self taught and somtimes miss things!
:=
:=Dave

A more robust and foward planning method would be to set a flag in your interupt routine. Then during your main loop check for the flag and run your switch statement. This lets you get into and out of your interupts ASAP. Assume you have a timer performing this switch and you decide you want to add serial communication to do some debugging. You could miss an incomming byte while servicing the timer interupt. This sort of problem only occures when you want to use more than a single interupt. For these reasons the time spent within interupts should be kept to a minimum.
___________________________
This message was ported from CCS's old forum
Original Post ID: 12335

[Mark]

In general, you should keep the interrupt service routines as short as possible. This is code that is actually executed. You state that you have 8 tasks, so long as these tasks are small or only one is executed per isr (and it is small) you should not have any problems. If the timing of these tasks is not that critical, a better approach would be to set flags and execute the tasks from the main loop.

Regards,
Mark

:=
:=Hi all,
:=
:=I have a 8 level switch statement in a interrupt service routine
:=which completes 8 tasks in 8 interrupts and so on. I noticed in a previous Question (not mine) Hans commented on to much code being in an interrupt routine. Does this matter? After all - the program jumps to the interrupt address and completes the routine - then back to the main program. I am a bit worried now that i am going to have problems whith my code - which does function well - and have had no problems. I would appreciate any comments as I am self taught and somtimes miss things!
:=
:=Dave
___________________________
This message was ported from CCS's old forum
Original Post ID: 12336

[Paul_B]

:=
:=Hi all,
:=
:=I have a 8 level switch statement in a interrupt service routine
:=which completes 8 tasks in 8 interrupts and so on. I noticed in a previous Question (not mine) Hans commented on to much code being in an interrupt routine. Does this matter? After all - the program jumps to the interrupt address and completes the routine - then back to the main program. I am a bit worried now that i am going to have problems whith my code - which does function well - and have had no problems. I would appreciate any comments as I am self taught and somtimes miss things!
:=
:=Dave

Hi dave

There may be a limit on how much code can be executed within an interrupt, but i'm not sure exactly how much. You may be pleased to know that it wasn't the amount of instructions executed that was my problem as in previous message posted but a simple program flow error. Bad programming , eh. Its the simple things that catch you out.

In terms of code executed within an interrupt, as long as the microcontroller has enough time to carry these instructions out and still do all the other executions in hand, then i can't see a problem. But don't take my word for it, i am not very experienced.

The overall impression i seem to get is that it is bad practice to execute many instructions within an interrupt, but as long as the processor can handle it then what the hell.

Constructive critism appreciated, and i don't mind getting slated if i'm wrong by you other forum users.

Regards

Paul_B
___________________________
This message was ported from CCS's old forum
Original Post ID: 12348

[R.J.Hamlett]

:=
:=Hi all,
:=
:=I have a 8 level switch statement in a interrupt service routine
:=which completes 8 tasks in 8 interrupts and so on. I noticed in a previous Question (not mine) Hans commented on to much code being in an interrupt routine. Does this matter? After all - the program jumps to the interrupt address and completes the routine - then back to the main program. I am a bit worried now that i am going to have problems whith my code - which does function well - and have had no problems. I would appreciate any comments as I am self taught and somtimes miss things!
:=
:=Dave
There are two seperate issues.
The first is that the whole point of interrupts normally, is to get reasonably quick responses to an event. Now if there is more than one interrupt source, the worst case 'latency' (time taken to respond to an interrupt), will be the hardware latency time, plus twice the int_global handler time (which is several tens on instructions in some cases), plus the time taken in your other interrupt handler, in the case when the second interrupt occurs just after the other one has triggered. This can degrade interrupt responses to the point where using interrupts becomes pointless...
The second issue, is that because the combination of the PIC, and the CCS compiler, does not support 're-entrancy', _every_ bit of code that falls inside your interrupt handler, will result in any code outside the handler that uses the same subroutines, having the interrupts disabled. This includes such 'non obvious' things, as internal table reads, which are used in array accesses, and also in some cases in switch statements. This has a similar degrading effect on the interrupt response.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12350

[PCM programmer]

:=
:=I have a 8 level switch statement in a interrupt service routine
:=which completes 8 tasks in 8 interrupts and so on. I noticed in a previous Question (not mine) Hans commented on to much code being in an interrupt routine. Does this matter?
--------------------------------------------------

In addition to the already mentioned issue of increased
interrupt latency, there are a couple more reasons:

A long isr will insert essentially random delays into
your foreground code. (ie., code in main(), and routines
that are called by main() ). If you're using time-sensitive
code to talk to a hardware device, this random delay could
cause problems. You may respond by disabling interrupts
around your critical driver code. But now you have increased
your interrupt latency.

Another reason, just associated with coding and debugging,
is given here, in the section called "Keep ISRs short":
<a href="http://www.embedded.com/2000/0010/0010br.htm" TARGET="_blank">http://www.embedded.com/2000/0010/0010br.htm</a>
___________________________
This message was ported from CCS's old forum
Original Post ID: 12351

[Hans Wedemeyer]

Dave
The good advice given in other posts is exacly what I was referring to.

Just a quick point about the switch()
The switch() is fast. CCS produces a jump table and reduces a large switch to almost the same as if()

So, as large switch in the ISR may look like a lot of code but if it only executes once it's fast. The actual number of bytes in the ISR is not important, it's only the time taken to execute the actual statements.

I prefer the "set a flag in the ISR" and do the work in your main() loop.
___________________________
This message was ported from CCS's old forum
Original Post ID: 12353

[mark r. hahn]

Actually Mr or Ms Hamlett raises an interesting question (well interesting to me :-) ), don't you have to disable ints in any routine that could get called by your mainline code and your interrupt service routine (ISR)? I don't think CCS does this automatically.

And since CCS generates subroutines for operations like multiply, you probably need to be very careful about even doing math in an ISR (though simple adds, etc. should be OK).

This is making the set a flag and do the processing in the mainline look better and better.

Mark



:=:=
:=:=Hi all,
:=:=
:=:=I have a 8 level switch statement in a interrupt service routine
:=:=which completes 8 tasks in 8 interrupts and so on. I noticed in a previous Question (not mine) Hans commented on to much code being in an interrupt routine. Does this matter? After all - the program jumps to the interrupt address and completes the routine - then back to the main program. I am a bit worried now that i am going to have problems whith my code - which does function well - and have had no problems. I would appreciate any comments as I am self taught and somtimes miss things!
:=:=
:=:=Dave
:=There are two seperate issues.
:=The first is that the whole point of interrupts normally, is to get reasonably quick responses to an event. Now if there is more than one interrupt source, the worst case 'latency' (time taken to respond to an interrupt), will be the hardware latency time, plus twice the int_global handler time (which is several tens on instructions in some cases), plus the time taken in your other interrupt handler, in the case when the second interrupt occurs just after the other one has triggered. This can degrade interrupt responses to the point where using interrupts becomes pointless...
:=The second issue, is that because the combination of the PIC, and the CCS compiler, does not support 're-entrancy', _every_ bit of code that falls inside your interrupt handler, will result in any code outside the handler that uses the same subroutines, having the interrupts disabled. This includes such 'non obvious' things, as internal table reads, which are used in array accesses, and also in some cases in switch statements. This has a similar degrading effect on the interrupt response.
:=
:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12356

[R.J.Hamlett]

:=Actually Mr or Ms Hamlett raises an interesting question (well interesting to me :-) ), don't you have to disable ints in any routine that could get called by your mainline code and your interrupt service routine (ISR)? I don't think CCS does this automatically.
:=
Mr.
Yes, it does it automatically. Some things don't need it (the floating point stack is saved by the int_global handler), so parts of the arithmetic (for instance, where coded 'inline'), can work without interrupts disabled. However a lot of code will end up with the interrupts disabled. In the past, there was a problem on the 18F family, with some sections that did need the interrupts disabled, having them left enabled, but the current versions do disable the inetrrupts, but with the 'downside', that there are often large sections of code in the main routines, where an interrupt response will be delayed...

:=And since CCS generates subroutines for operations like multiply, you probably need to be very careful about even doing math in an ISR (though simple adds, etc. should be OK).
:=
Yes. Generally simple operations, generate 'inline' code, but things like sin/cos etc., are both very slow, and will result in large areas of 'disabled' code.

:=This is making the set a flag and do the processing in the mainline look better and better.
:=
:=Mark
It is the safest way.
The other solution, is to generate your own code for these routines, that uses it's own storage, and takes great care to put the changed registers back 'as they were'. You can then call these inside the interrupt handler if necessary, and have normal interrupt response in the main. It is an alternative if this is the type of response needed.
Generally, the 'clean' way to work, is to use buffers, and flags, so that response can be in the main routine as much as possible.

Best Wishes

:=:=:=
:=:=:=Hi all,
:=:=:=
:=:=:=I have a 8 level switch statement in a interrupt service routine
:=:=:=which completes 8 tasks in 8 interrupts and so on. I noticed in a previous Question (not mine) Hans commented on to much code being in an interrupt routine. Does this matter? After all - the program jumps to the interrupt address and completes the routine - then back to the main program. I am a bit worried now that i am going to have problems whith my code - which does function well - and have had no problems. I would appreciate any comments as I am self taught and somtimes miss things!
:=:=:=
:=:=:=Dave
:=:=There are two seperate issues.
:=:=The first is that the whole point of interrupts normally, is to get reasonably quick responses to an event. Now if there is more than one interrupt source, the worst case 'latency' (time taken to respond to an interrupt), will be the hardware latency time, plus twice the int_global handler time (which is several tens on instructions in some cases), plus the time taken in your other interrupt handler, in the case when the second interrupt occurs just after the other one has triggered. This can degrade interrupt responses to the point where using interrupts becomes pointless...
:=:=The second issue, is that because the combination of the PIC, and the CCS compiler, does not support 're-entrancy', _every_ bit of code that falls inside your interrupt handler, will result in any code outside the handler that uses the same subroutines, having the interrupts disabled. This includes such 'non obvious' things, as internal table reads, which are used in array accesses, and also in some cases in switch statements. This has a similar degrading effect on the interrupt response.
:=:=
:=:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12359