Searching \ for '[PIC]: Memory paging question' 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/microchip/memory.htm?key=memory
Search entire site for: 'Memory paging question'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Memory paging question'
2003\03\26@040426 by WH Tan

flavicon
face
I have some question about memory paging.

I know there is no such issue if a program didn't cross 0x0800 address
(Page1).

To test the LCALL & LGOTO command, I wrote this code

;************************************************************
               org     0x0000  ; Page0
               goto    START

               org     0x0004
               ; ......

START:
               ; My main program go here
               ......
               ......
               lcall Sub1
               ......
               ......
               ; end of main program.

               org     0x1800  ; Page3 (I am using 16f877)
               ; I move all subroutine to page3
Sub1:           ......
               ......
               return

...:            ......
               return

...:            ......
               return

               end
;*************************************************************

The above code didn't work.

I found later in PICList library that instead of just return from Sub1,
pagesel START must add just before the return.

Although I get my code work now, it still make me confuse.

Isn't the program stack a 14-bits register. When a call or lcall instruction
is executed, pic should store PC+1 (which is 14-bits) in stack.
Then no matter to which page the call is address, a return command should
restore PC correctly. Why the pagesel is need just before return?

Can someone explain to me please?

Thanks in advance.

WH Tan

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

2003\03\26@063950 by Eric Bohlman

picon face
3/26/03 3:05:40 AM, WH Tan <.....tanwhKILLspamspam@spam@NOTES.SRC.GLOBAL.SHARP.CO.JP> wrote:

>I found later in PICList library that instead of just return from Sub1,
>pagesel START must add just before the return.
>
>Although I get my code work now, it still make me confuse.
>
>Isn't the program stack a 14-bits register. When a call or lcall instruction
>is executed, pic should store PC+1 (which is 14-bits) in stack.
>Then no matter to which page the call is address, a return command should
>restore PC correctly. Why the pagesel is need just before return?

The return does restore PC properly.  The problem is that PCLATH is still set to the new page (3, in
your case) as a result of the lcall, so the next call or goto (or move that affects PCL) that you
encounter will try to go into the new page.


IOW, if you do

       lcall   mysub
       skpnz
       goto    somewhere
;...
somewhere:

You'll return correctly from mysub and execute the skpnz, but if the Z flag were set then the goto
somewhere would go to the wrong place, namely somewhere in page 3.

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

2003\03\26@102847 by Bob Barr

flavicon
face
On Wed, 26 Mar 2003 17:05:40 +0800, WH Tan wrote:

>I have some question about memory paging.
>
Many people do. :=)


{Quote hidden}

Nope, it certainly would't/

>I found later in PICList library that instead of just return from Sub1,
>pagesel START must add just before the return.
>

This would be correct if you could *only* call sub1 from page 0. If
you can call sub1 from other pages, this will fail as well.

>Although I get my code work now, it still make me confuse.
>
>Isn't the program stack a 14-bits register. When a call or lcall instruction
>is executed, pic should store PC+1 (which is 14-bits) in stack.

True.

>Then no matter to which page the call is address, a return command should
>restore PC correctly.

It does.

> Why the pagesel is need just before return?
>

The "pagesel" should be put just after the "lcall" instruction, not
inside sub1.

The "lcall" mnemonic sets/clears the upper bits of PCLATH to make the
call switch to the proper page. These bits will remain as set until
you change them.

When you return from sub1, you are running code in page 0 but the
PCLATH upper bits are still set for page 3.

Any goto or call to a location in page 0 (without clearing those upper
bits of PCLATH) will cause your code to go to the corresponding
address in page 3.

You could code this as:

 lcall  sub1           ; call your 'out-of-page' subroutine
 pagesel  $+1      ; restore PCLATH bits to current page


Regards, Bob

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

2003\03\26@104929 by Alan B. Pearce

face picon face
>Then no matter to which page the call is address, a return
>command should restore PC correctly.

If you use Olin's development environment, you would not have this problem.
He has macros that deal with the page selection when doing a long call, and
the macro returns the PCLATH to the current code page on return.

See http://www.embedinc.com/pic/ to download the complete environment, along
with an example application and other goodies.

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

2003\03\26@113946 by Olin Lathrop

face picon face
> You could code this as:
>
>   lcall  sub1           ; call your 'out-of-page' subroutine
>   pagesel  $+1      ; restore PCLATH bits to current page

You could also code it as

   gcall  sub1           ;call global subroutine SUB1

if you use my environment.  GCALL is a macro defined in STD.INS.ASPIC at
http://www.embedinc.com/pic.  It sets PCLATH to the target routine, calls
it, then restores PCLATH afterwards.  It also helps in writing code to run
on different PICs.  It is smart enough to not mess with PCLATH on machines
with only one code page, or on the 18 family, for example.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

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