try:
        pagesel <label>
        call    <label>
        pagesel $

The solution is to make PCLATH point back to the current page.  If and only
if the current page is 0 will:
        clrf    PCLATH
do the job.

I don't think the pagesel directive works unless you are linking.
Personally, I have found the linker to be pretty disfunctional, and always
assemble directly (i.e. without the linking step).

With only 2 pages on a 16C63A, I use the following macro:


fcall macro t
 If((t & 0x800) == ($ & 0x800))
 MESSG   fcall not actually needed at #v($).
 EndIf
   If (t & 0x800)
      bsf   PCLATH,3
   Else
      bcf   PCLATH,3
   EndIf

   errorlevel -306
   call  t
   errorlevel +306

   If ($ & 0x800)
      bsf   PCLATH,3
   Else
      bcf   PCLATH,3
   EndIf
 endm

This eliminates the worst gotcha of the pagesel, which is that on a 14-bit
machine like 16F876, your macro will expand to:

        movlw   high <label>
        movwf   PCLATH
        call    <label>

which will silently and invisibly destroy any contents of the W register,
such as an argument you are passing to the subroutine.  Adding a pagesel to
restore PCLATH will also destroy any result passed back by the subroutine.

With a little more work, my macro can be expanded to accomodate a machine
with more than two pages by adding some more lines something like:

   If (t & 0x1000)
      bsf   PCLATH,2
   Else
      bcf   PCLATH,2
   EndIf

The paging and banking are without a doubt the ugliest, nastiest,
bug-waiting-to-happen-est flaws of the PIC architecture.  A whole lot of my
programming time is devoted to finding and fixing or trying to avoid those
bugs.

My biggest disappointment with the 18Cxx family is that they didn't get
relative addressing and lose the bank- and page- switching.

Somehow the Atmel guys seem to have found the extra silicon to add the
adders in the addressing paths, so why can't the Microchip guys do it?  If
you look at the pretty posters of chips, the part labeled "CPU" amounts to
about 10% or so of the chip, what with all the nice peripherals and memory.
So 10% more stuff in the CPU would be about 1% more stuff on the chip.

It feels like I'm losing 10-20% programming productivity to save that little
silicon, and wind up always worrying that that one instruction I added will
push something past one of those low-visibility boundaries and cause the
once-in-a-blue-moon error code to blow up, which means full regression
testing for the most trivial of changes.

> -----Original Message-----
> From: Andy Stubbins [mailto:andy@STUBBINSR.FREESERVE.CO.UK]
> Sent: Thursday, August 17, 2000 10:43 AM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: [PIC]:Paging Issues
>
>
> Hi All
>
> I am working on a project using the 16f876 (assembler)and
> have come up against crossing page boundaries. I have
> implemented the macro
>
> pagesel <label>
> call    <label>
> ;do something
> return
>
> to overcome these issues. The problem is that the format for
> this procedure seems to suggest (according to the MPASM user
> guide) that when you return from the subroutine <label>, the
> PCLATH counter resets itself whilst returning to the address
> stored in the stack. This is not the case and I have tried
> several different ways to overcome this: 1. use pagesel for
> the next call/goto subroutine arises in the code. (no
> success) and 2. clrf PCLATH (again no success )
>
> I think it is probably something simple that I am not doing
> correctly that is causing my code to jump to random
> locations, i.e. anywhere but where it should. Any suggestions
> greatly received
>
> Regards
>     Andy
>
> --
> http://www.piclist.com hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu
>

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu