>>
So if you look at jumping into the next page of 2K code space on a 16F874,
it
requires that any goto has the following :

        bcf     PCLATH,4
        bsf     PCLATH,3

This allows the upper bits of the address to be indexed and makes perfect
sense to me but does not seem to want to work. It appears to hang or branch
off to some unkown location (I base this on what the LCD display has on
it...my initial branch should display something and it does not)

Also, any CALL should push/pop the entire address right? I even placed all
my
called subroutines in the second page and still didnt want to behave.

Once I set bit 3, does it get overwritten? In other words, if I have an
automatic and manual mode to my my controller, and make it such that all
manual operations occur in the second page, I should never have to touch the
PCLATH bits until I go back to automatic mode (first page). Unless something
is writing over and nailing these bits.  I suppose I might have to break
down
and buy an ICD to see what is going on?
<<

You seem to have the right idea, but probably missed a few CALLs or GOTOs
somewhere.  You shouldn't need an ICD (although it can be useful in general)
to find this problem, the simulator should do for this.  Yes, CALLs push the
entire address onto the stack and RETURN pops it -- but.  The subroutine
will return to right after the call, but PCLATH is not restored.

My personal opinion is that all the manual methods of managing PCLATH will
get you into trouble.  You might have a division between "automatic" and
"manual" code now, but I wouldn't use that for deciding how to use PCLATH.
What if one of these overflows a page or you need to move routines around
between pages?  You would have to go back and examine every call in the
whole program.

I prefer a general convention for managing PCLATH.  The convention I use is
that PCLATH is always set for the current code page, and that individual
modules don't cross page boundaries.  I make a separate linker section for
each page so that each module is completely within a page.  This scheme
allows local GOTOs (GOTOs within a module) to not require PCLATH diddling.
This is convenient since GOTOs often go right after SKIP instructions and
need to be single instructions in that case.  On the flip side, it requires
setting PCLATH immediately before each global (external to the module) GOTO
or CALL, and it requires restoring PCLATH immediately after the return from
any global call.  I've used this convention successfully over dozens of PIC
projects.  Note that the linker can move modules around between pages any
time without you needing to care.

I've created a set of macros that simplifies adhering to this convention.
For example, the GCALL (Global CALL) macro sets PCLATH appropriately for an
external routine, calls the routine, then restores PCLATH to the current
page.  It is also clever enough to not bother on machines that only have one
code page.  You can find GCALL and lots of other macros in STD.INS.ASPIC at
http://www.embedinc.com/pic.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olin@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body