There are three main reasons one might not want to initiate a call from
an ISR:

1. Interrupts are (should be) disabled for the duration of the ISR -
otherwise you may interrupt your own interrupt, causing stack overflows
(which the processor does NOT catch or warn you of) and you will end up
delaying interrupt handling for other pending interrupts.

2. If you already are inside several nested calls then the interrupt
itself uses another stack position, and any call you make after that
uses another.  If that function is only used inside the interrupt, then
there's really no reason to make it into its own function (use a macro
if you want to seperate it), if other functions depend on it then you
may find yourself modifying it later - maybe making it call another
function.  In short, when you do this you must have a really good grasp
of how deep your stack is, and how deep your calls could possibly get.

3. Many people consider it bad programming practise (ie, the interrupt
is for time critical tasks and should only be disabled for the briefest
time to service the pending interrupt(s)) and when you go into other
processor architectures such a practice may bite you.  Others reading
your code may have a difficult time modifying it as normal changes (to a
display routine, for instance) may abnormally affect your interrupt routine.

That being said, the PIC is an exceptionally small processor with only
so much speed and code space.  It is not untolerably difficult to track
the stack usage, and many times you'll find yourself using functions
inside interrupts simply to aid in program understanding and component
reusablility.  The third problem above can be alleviated (if not
eliminated) with good coding/commenting practises.  Start each function
with a  description, list of inputs/outputs, ranges of inputs/outputs,
what happens when it is given something it can't handle, and a list of
dependancies.  Be sure to clearly describe if the interrupt routine
calls it.

You can eliminate function calling from interrupts by using inline code,
macros, or flags.

A case where a function call is appropiate is display refresh.  The
refresh must start at even intervals or flickering will be perceived
even at moderately high frequencies.

I know that _you_ know all this, Andrew, but you did ask  ;-)

-Adam

Drew Vassallo wrote:

>> ok Just remember that a call from an ISR is not a good option ...
>
>
> If you're going to make this statement, you'd better explain why it's
> "not a
> good option."  I've been doing it for years without difficulty and it
> seems
> to be just as good an "option" as anything else.
>
> --Andrew
>
> _________________________________________________________________
> Join the world s largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>
>
>
>
>

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.