Searching \ for '[PIC] C18 ISRs calling other functions?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'C18 ISRs calling other functions?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] C18 ISRs calling other functions?'
2010\07\27@045019 by Matt Rhys-Roberts

flavicon
face
As far as I can tell, the C18 compiler automatically takes care of the two different context saving methods for WREG, BSR and STATUS, depending on whether the interrupt priority is high (i.e. use shadow regs & fast return) or low (i.e. use stack). Great!

Since ISRs use a temporary data section kept separate from normal C functions, does this create any issues with ISRs calling functions elsewhere in program memory? The C18 Compiler User's Guide (DS51288J-page 28) says the following, but I can't conclude much from it:

"...

Interrupt service routines use a temporary data section that is distinct from that used
by normal C functions. Any temporary data required during the evaluation of
expressions in the interrupt service routine is allocated in this section and is not
overlaid with the temporary locations of other functions, including other interrupt
functions. The interrupt pragmas allow the interrupt temporary data section to be
named. If this section is not named, the compiler temporary variables are created in a
udata section named fname_tmp. For example:
void foo(void);
....
#pragma interrupt foo
void foo(void)
{
/* perform interrupt function here */
}
The compiler temporary variables for interrupt service routine foo will be placed in the
udata section foo_tmp.

...."

In other words, do I have to name or move this ISR temporary area somehow to enable 'normal' execution of arbitrary functions?

Thoughts welcome,
Matt

2010\07\27@080840 by Olin Lathrop

face picon face
Matt Rhys-Roberts wrote:
> In other words, do I have to name or move this ISR temporary area
> somehow to enable 'normal' execution of arbitrary functions?

The part of the manual you quoted gives no hint this is even a issue.
Manually placing a relocatable section is usually a bad idea, and giving it
a name only means it won't have its default name.  But in any case, I can't
see any reason you should think the name or placement of the section will
matter to runtime operation.

Step back and think about what is going on.  The location and name of the
temporary data used by the interrupt routine doesn't matter from that point
of view either.  The compiler is merely making sure that temporary RAM
locations used during interrupt are not reused anywhere else, since it has
to assume a interrupt could happen when in any of the other routines.  This
also means you can't call any of these other routines from the interrupt
routine unless those other routines are compiled in such a way as to not use
static temporary variables.  In other words, any routine called during
interrupt must be reenterable.  That means static temporary variables are
out.  All temporary variables need to be dynamically allocated, probably by
using the stack (although there are other ways).  Most likely your compiler
defines a particular way of waving a dead fish over a routine (often called
a pragma) to indicate it must be reenterable, or maybe that's the default
when no dead fish is waved.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\07\27@144651 by John Temples

flavicon
face
On Tue, 27 Jul 2010, Matt Rhys-Roberts wrote:

> Since ISRs use a temporary data section kept separate from normal C
> functions, does this create any issues with ISRs calling functions
> elsewhere in program memory?

> In other words, do I have to name or move this ISR temporary area
> somehow to enable 'normal' execution of arbitrary functions?

No, you don't have to do anything special to call functions from ISRs.
However, doing so will cause the ISR to save all of the .tmpdata
section unconditionally, which can add hundreds of instruction cycles
to your interrupt context save/restore time.  There is a way to
prevent this, but the easiest way is to not call functions from the
ISR.

--
John W. Temples, II

2010\07\28@065529 by Matt Rhys-Roberts

flavicon
face
 Thanks to Olin and John for the above clarifications.

(NB If it's not acceptable list etiquette to thank people for their assistance so much, somebody please put me right!)

Mat

2010\07\28@074556 by RussellMc

face picon face
> (NB If it's not acceptable list etiquette to thank people for their
> assistance so much, somebody please put me right!)

Feel free to thank people - people appreciate being appreciated!

(There is no official policy on thanking people - but if there was I
think that it would be something like the above).



           Russell

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...