You're right, Olin, I did confuse those.

Sorry, guys.

In my macros below, the intent was to not lose the W going into the call,
NOT coming out, which is only rarely useful.

At 08:03 AM 8/11/2003 -0400, you wrote:
> > When you want to set the PCLATH to the right bank point, you invoke
> >
> > BANKSEL  MYVARIABLE
>
>No, you are confusing several concepts.  First, PCLATH indicates the code
>memory *page*, not the RAM *bank*.  You don't care what PCLATH is set to
>to access MYVARIABLE.  Second, to set PCLATH to the 256 word chunk
>containing a particular address, you use PAGESEL.
>
> > what MPLAB will do is invoke A MACRO
> >
> > MOVLW HIGH MYVARIABLE
> > MOVWF PCLATH
> >
> > So you have to be aware that 'W' will be altered.
>
>This is consused again, but PAGESEL can alter W in some cases.
>
> > ;*********************************************************************
> > ;            macro to create an errorless LONG CALL
> > ;                   W & Bank Unchanged
> > ;*********************************************************************
> > longcall macro  arg1
> >          movwf   saveW
> >          movlw high arg1
> >          movwf   PCLATH
> >          movf    saveW,W
> >          call    arg1
> >         endm
>
>Note that this leaves PCLATH pointing to the subroutine's page on return.
>Local CALLs and GOTOs will be messed up until PCLATH is fixed.
>
>On processors with exactly two code pages (4K words), only one bit in
>PCLATH is relevant when doing a CALL or GOTO.  An optimization on those
>processors is to BCF/BSF the single bit.  This is what PAGESEL does,
>although early versions had a bug in this case, that was fixed a few years
>ago.  Of course on processors with only one code page, you don't need to
>mess with PCLATH at all on a global call.
>
>Since W may be used to set PCLATH, it may not be the best choice for
>passing arguments to subroutines.  I use a set of "general registers" in
>global RAM for such things.  This alleviates the need to save/restore W on
>a global call whether it is needed or not.
>
>My GCALL macro in STD.INS.ASPIC at http://www.embedinc.com takes all these
>issues into account.
>
>
>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, http://www.embedinc.com
>
>--
>http://www.piclist.com hint: The list server can filter out subtopics
>(like ads or off topics) for you. See http://www.piclist.com/#topics

    --------------------------
www.micro-firmware.com
PIC Firmware & Hardware
      1-866-755-2853

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics