Hi Bill

Thanks much.
I wanted to reply to everyone that has helped me sooner but I'm not allowed
my laptop in meetings anymore...they keep blathering on some nonsense about
me not paying attention.

1) Have you declared your interrupt routines in whatever way
    is necessary for the compiler to know that it cannot use
    the "fast return" from interrupt for the low priority
    interrupt?

There are pragma statements that are supposed to take care of that stuff
according to Microchip tech support and what I can tell from the
documentation.
If there is anyone out there can tell if my ducks are lined up or not  I'd
be very grateful.
I posted the ISR declaration code below it is from their(Microchip) example
that comes with the compiler.

2) How is you stack usage?  If you've got high and low prior
    interrupts, and are calling C functions of unknown stack
    usage from your high prior interrupt, it seems to me you
    could be getting close to the 31 entry limit, especially
    if the compiler uses the hw stack for anything more than
    just return addresses.  Do you have the stack overflow
    resets enabled?

I'm only using two function calls in my serial ISR.
The first is a getcUSART1 function for Microchip.  (I'm not sure why or if
you think I am near the 31 entry limit but I'd sure like to find out so I
can avoid any run ins in the future)
getcUSART1 is only a few lines in assembler(I could certainly could copy it
and put it inline and get rid of the calling over head )
The other function is my own and there is not that much to it either it just
pushes a command into a circular buffer.
The rest of the ISR looks at the char and if it is the right character it
pushes a CMD into a circular buffer or if a special character has been
received it builds a string by pushing the next few characters into a
buffer.
When it sees a terminating character a command is pushed into the circular
buffer.
(When the main loop sees the CMD it knows to go fetch the string and how to
use it.)  If any of the chars are wrong/it gets too long/etc then the string
is dropped and all it starts all over. 
The thing could be made a little skinnier but I think a little extra lard
here is worth it in the maintenance and readability sense....obviously that
could soon change. 
  


I will check the STKPTR as things progress and see how close it is to the
end of its limit.
BTW I think figured out how to increase my stack size (there is an error in
the user's guide) but I don't want to go there just yet.
I am not sure if I have stack overflow resets enabled.
I will look into that but I have yet another meeting (five in the last two
days) about bar coding products and storing test/ performance data.
Later we are sure to have a meeting to see why I'm not getting anything done









 // High priority interrupt routine
#pragma code InterruptVectorHigh = 0x08 
void InterruptVectorHigh (void)
{  
  // Inline assembly that will jump to the ISR.   
  _asm GOTO InterruptHandlerHigh _endasm
}
#pragma code
#pragma interrupt InterruptHandlerHigh 


void InterruptHandlerHigh ()
{
  if (PIR1bits.RC1IF)                                      {
     PIE1bits.RC1IE = 0;                              //I can put this here
or in the first or the first line 
     handle_chars();
     PIE1bits.RC1IE = 1;                             //This is not needed
the retfie resets the flag I plan on putting the second serial port's ISR
here
    }
   return;
}

#pragma code InterruptVectorLow = 0x18

void InterruptVectorLow (void)
{
  //Inline assembly that will jump to the ISR.  
  _asm GOTO InterruptHandlerLow _endasm
}
 // Returns the compiler to the default code section.

//--------------------------------------------------------------------------
--
// Low priority interrupt routine

#pragma code
#pragma interrupt InterruptHandlerLow 
void InterruptHandlerLow ()
{

  if (PIR1bits.TMR1IF)                                  // Timer1 is used
for blinking the green LED on portB bit 0   Timer 1 is not currently enabled

   {                                                   
    blink_green_ISR();                                 //this is a debugging
aide some thing else will eventually blink the green or red LED in the fore
ground
    }
  if (PIR2bits.TMR3IF)                                       
    {
     detect_button_push_ISR();                         // scan the
switches/buttons for a closure or open after a closure etc 
    }
 return;
}
 
 Thnaks again
 
Phillip
Things should be as simple as possible but no simpler
 
 
 
Phillip Coiner
CTO, GPS Source, Inc.
 
 
Your source for quality GNSS Networking Solutions and Design Services, Now!

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
William Chops Westfield
Sent: Thursday, June 29, 2006 12:21 AM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] C18 resource remaining metric/test


On Jun 28, 2006, at 9:16 PM, Phillip wrote:

> It appeared to work for the most part but every once in a
> while the ultoa function would return a value that not
> that was garbage or out side the [expected range]

I'm not very familiar with any of what you're doing or
using, but...

1) Have you declared your interrupt routines in whatever way
    is necessary for the compiler to know that it cannot use
    the "fast return" from interrupt for the low priority
    interrupt?
2) How is you stack usage?  If you've got high and low prior
    interrupts, and are calling C functions of unknown stack
    usage from your high prior interrupt, it seems to me you
    could be getting close to the 31 entry limit, especially
    if the compiler uses the hw stack for anything more than
    just return addresses.  Do you have the stack overflow
    resets enabled?

ISRs should be as tiny as possible.

BillW
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist