John,

Thanks for the advise. I will look at using the low priority handler for
other interrupts. This is a good idea as it will isolate other code =
changes from=20
effecting the RX sampling.=20


Kind Regards

David Huisman


-----Original Message-----
From: piclist@XARGS.COM [mailto:piclist@XARGS.COM]
Sent: Friday, 26 September 2003 2:36 PM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: Bit-bashed UART, INT activated, PIC18F


On Fri, 26 Sep 2003, David Huisman wrote:

> It seems the Hi-Tech compiler saves all registers to be used in any
code called from the interrupt and it appears that at present 100
cycles latency is occurring.

How involved is the code in your ISR?  If it requires a lot of
temporary space (look at the assembly listing for "btemp" references),
this space will be saved and restored in the ISR.  If you call
functions that use btemp from the ISR, that also counts.

Consider using a low priority ISR for everything other than INT0.
This allows the low priority interrupts to use btemp without affecting
the context save/restore time of the high priority ISR.

Make sure you're using 8.30 which supports the fast register stack in
the high priority ISR.

As a last resort, if you're sure you know better than the compiler,
look at the regsused pragma.

--
John W. Temples, III

--
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.