>>
As far as I have learned
( the hard way :) ) messing with PCLATH at one place in Your program
can break havoc on other portions. Therefore to be safe set PCLATH
to high($) after the call to this routine and see what happens.
<<

It helps to have a consistant strategy for dealing with PCLATH throughout
your whole program.  I use the following rules, which seem to work well for
me:

1 - Individual modules aren't allowed to cross page boundaries.  I make sure
this happens automatically by creating a separate linker section for each
page.  There are occasional exceptions which so far have all been large data
module (tables, etc.).

2 - The high bits of PCLATH are always set to the page of the current
module.  This means CALLs and GOTOs within a module can always be done in
one instruction without setting PCLATH first.

3 - PCLATH is always set before a CALL or GOTO to a label outside the
current module.

4 - PCLATH is always reset to the current address after return from an
external subroutine.

This method is made easier by using macros for external subroutine CALLs and
GOTOs.  I have GCALL (global call) for calling an external subroutine.  This
sets PCLATH, calls the routine, then resets PCLATH.  The GJUMP macro works
similarly for jumping to an external label.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olin@cognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads