Exact match. Not showing close matches.
PICList
Thread
'[PIC] C18 ISRs calling other functions?'
2010\07\27@045019
by
Matt Rhys-Roberts
|
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
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
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
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
> (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...