Hi Olin
I was not disabling interrupts during my ISR.
Now that interrupts are off and I'm not calling my c routine recursively
things are much better behaved.
I had more difficulty trying to send using interrupts but I gave up and
polled the busy bit of the UART and now sending characters appears to work
fine also.

I'm not sure why calling the getcUSART1 from my ISR is such a bad idea.
(Of course I do agree not disabling interrupts whilst in my ISR is bad.
What amazes me is that it worked at all.)
All getcUSART1 does is get the character from the USART's buffer.
I suppose life would be better without the overhead of a function call but
my ISR is not that busy.
I reckon that if it does get larded up enough calls I could start to drop
characters. 
  

Mucho Thanks again I always appreciate the clear thinking.

 
 
 
 
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
Olin Lathrop
Sent: Tuesday, June 27, 2006 12:22 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] C18 resource remaining metric/test

Phillip wrote:
> My reasoning goes like this as I call getcUSART1 again and again if I
> don't allow the last getcUSART1 to finish before my next ISR happens
> eventually I'll over flow the stack and strange things will start to
> happen.

First, calling a C routine in the interrupt handler just to get a byte from
the UART sounds like bad idea.  Why not just do a normal interrupt driven
UART with FIFO, and drop the byte if the FIFO is full?

But the real issue is that your statement makes no sense.  If you are
calling the C GET routine from the ISR, then how can it be called
recursively since interrupts are off?  If you're calling it from outside the
ISR then how can it be called recursively at all?


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products
-- 
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