Post by thread:Page boundaries and PCLATH ???

<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>

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_OUTmsTakeThisOuTzam.nf.fh-nuernberg.de (Ger/Eng/Spa welcome)

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!" ==================================================================

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 ? .....gennadypKILLspam@spam@javs.com