Searching \ for 'Page boundaries and PCLATH ???' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=page+boundaries
Search entire site for: 'Page boundaries and PCLATH ???'.

Truncated match.
PICList Thread
'Page boundaries and PCLATH ???'
1997\02\18@161701 by Bob Segrest

picon face
<x-rich>Greetings,


I managed to get my program coded and fed it into the MAPLAB for
simulation.  Things started branching about erratically and I went back
to the books to read about the PCL, PCLATH and page boundaries.  I also
read AN556, "Implementing a Table Read".


The app note suggests loading the PCLATH with the high order bits of the
destination address before doing a CALL or GOTO.  I think I understand
the general idea, but there are still a couple points where I am
confused...


For example....


<paraindent><param>left</param>         org   0010

               movlw HIGH dest

               movwf PCLATH

               movfw offset

               call  dest


               org   0200

dest    addwf PCL

               goto  Asub

               goto  Bsub

               goto  Csub


               org   0300

Asub    ....

               ....

               RETURN

</paraindent>

Now as I understand it you need to preload the PCL before the CALL
because 'dest' is NOT in the same 256 byte page of memory.  As it turns
out, this was in fact what was happening to my program...


What confuses me is that the GOTO Asub in the 'dest' table worked without
any problems...  and it is not in the same 8 bit page of memory
either...


The RETURN from Asub seems to work ok and I found a terse note somewhere
that says this is because the entire 13 bit original address of CALL was
saved... However, I noticed that the PCLATH still shows the high order
bits for 'dest' after the RETURN.  Is this something I am supposed to
change back to zero ???  If not, why doesn't this mess something else up
after I continue following the RETURN ???


Surely someone has something posted on the net that can clarify this for
me... Anyone have a pointer ???  Anyone care to put me on the straight
and narrow...


Bob Segrest


PS: Every time I send mail to the PICLIST, the mail bounces back as
undeliverable and I never see a copy of the messages I post come back
from the mailing list.  However my posts appear to be going out because I
see the responses coming back to the mailing list.  Is this normal ???
</x-rich>

1997\02\19@065910 by Marc Schmaeche

flavicon
face
Dear Bob,

>Now as I understand it you need to preload the PCL before the CALL
>because 'dest' is NOT in the same 256 byte page of memory.

You should preload PCLATH (not PCL) before any instruction which changes the
PCL register (unless you are sure that you remain in the same "page").

Depending on the PIC processor you are using the CALL and GOTO opcodes are
containing a different number of releveant bits for calculation of the
destination adress. So the size of a "page" depends on the command as well
as on the PIC itself (see below).

>What confuses me is that the GOTO Asub in the 'dest' table worked without
>any problems...  and it is not in the same 8 bit page of memory
>either...

For example a PIC16C5x uses 12 bit opcode which contains the least 8
significant bits of the destination address in a CALL and the 9 (!) least
significant bits in a GOTO statement. So the label Asub and the GOTO Asub are
in the same "9 bit page".

As another example the PIC16C71 uses 14 bit opcode which contains the least
11 significant bits both in a CALL and  a GOTO statement. Due to the fact that
the PIC16C71 has only 1K ROM you need not preload PCLATH before any CALL or
GOTO (unless you want to use the same code in a device with more than 2 K ROM
later!)

>The RETURN from Asub seems to work ok and I found a terse note somewhere
>that says this is because the entire 13 bit original address of CALL was
>saved... However, I noticed that the PCLATH still shows the high order
>bits for 'dest' after the RETURN.  Is this something I am supposed to
>change back to zero ???  If not, why doesn't this mess something else up
>after I continue following the RETURN ???

You're right, the stack always contains the whole program counter, so for a
return statement the contents of PCLATH is irrelevant.

Regards,
Marc Schmaeche

ZAM-AZN
Am Weichselgarten 7
91058 Erlangen (Germany)
E-mail: spam_OUTmsTakeThisOuTspamzam.nf.fh-nuernberg.de (Ger/Eng/Spa welcome)

1997\02\19@072405 by Andy Kunz

flavicon
face
At 04:14 PM 2/18/97 -0500, you wrote:
>I managed to get my program coded and fed it into the MAPLAB for
simulation.  Things started branching about erratically and I went back to
the books to read about the PCL, PCLATH and page boundaries.  I also read
AN556, "Implementing a Table Read".

This is the one reason that the Parallax assembler is a little better then
Microchip's.

>What confuses me is that the GOTO Asub in the 'dest' table worked without
any problems...  and it is not in the same 8 bit page of memory either...

But if you _know_ the state of the PCLAT bits, you don't need to change
them.  It is not uncommon to have something of the like:

       org     200h
Rtn1
       ...
       return

       org     400h
; set bits appropriately using Parallax's lcall
       lcall   Rtn1
       movwf   temp1
       call    Rtn1
       movwf   temp1
       ljmp    Rtn2            ; set bits back to this page to continue
processing.
       ...

Rtn2    ...

Once the bits have been set, they remain set until you change them.  The
full 13-bit PC was stored on the call, but the return does NOT change them
back to what you think they were before.

>PS: Every time I send mail to the PICLIST, the mail bounces back as
undeliverable and I never see a copy of the messages I post come back from
the mailing list.  However my posts appear to be going out because I see the
responses coming back to the mailing list.  Is this normal ???

I get the message for my postings as well, and they always come from
Administrator at Microchip.com, addressed to some woman there.

My guess is that her e-mail address changed, and the list tries to send her
a message, but because her account was deleted, the unix machine just sends
you a message to let you know.

Parallax has a neat "Boing" utility to delete these automatically.  Perhaps
they can be persuaded to share it with the rest of the net world.

Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\02\19@115223 by Gennady Palitsky

flavicon
face
Trying to implement methods from AN556 I found few interesting things:
1. Code in example5 - should take care of both table location and page
boundary crossing. For controllers with over 2K of memory (I am working
with 16C63) it's nesessary to set PCLATH[3] if table is located on
page1. Code takes care of this. But, what they don't mention (as well as
16Cxx datasheet)is that you have to clear PCLATH[3] when return from
table read to page 0.
2. It looks like instruction addwf PCL in table read gives correct
location in table for the given offset. But instruction movwf PCL (as in
example 5) reads data for (offset - 1). And if offset=0, it will loop on
instruction movwf PCL forever.
Am I missing something ?

.....gennadypKILLspamspam@spam@javs.com

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...