Post by thread:[PIC]: Program Memory Paging

Hi everyone, I am writing a program for the PIC16F877. Suddenly, I get the following message "Crossing page boundary -- ensure page bits are set". I read the specs and it say that I can switch to different programming page by manipulate PCLATH <4:3> Please correct me if I am wrong (I can't find this info in the spec, so I am just guessing) PCLATH<4> | PCLATH<3> | GOTO PAGE -------------------------------- 0 0 Page 0 0 1 Page 1 1 0 Page 2 1 1 Page 3 Right? And I also have some questions: 1. What address do page 1, page 2, and page 3 start with? 2. If I place a subroutine in Page 1, and I want to call it from page 0, do I have to go to page 1 first before I can do a call (then switch back to page 0 to continue)? 3. Is there any trick to automatically switch the page? Is there any trick the treat the entire 8K of program memory as ONE page? Thank you very much! Thomas _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

At 07:57 PM 4/14/01 -0000, you wrote: >Hi everyone, > >I am writing a program for the PIC16F877. Suddenly, I get the following >message "Crossing page boundary -- ensure page bits are set". I read the >specs and it say that I can switch to different programming page by >manipulate PCLATH <4:3> > See: http://techref.massmind.org/techref/microchip/pages.htm -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> PCLATH<4> | PCLATH<3> | GOTO PAGE > -------------------------------- > 0 0 Page 0 > 0 1 Page 1 > 1 0 Page 2 > 1 1 Page 3 > > Right? Right. > 1. What address do page 1, page 2, and page 3 start with? You should be able to figure that out from the table above. > 2. If I place a subroutine in Page 1, and I want to call it from page 0, do > I have to go to page 1 first before I can do a call (then switch back to > page 0 to continue)? Whenever a GOTO or CALL is executed, PCLATH<4:3> must be set to indicate the intended target page. > 3. Is there any trick to automatically switch the page? Is there any trick > the treat the entire 8K of program memory as ONE page? Sortof, no. I use wrapper macros for subroutine calls and global jumps to make this much easier and less error prone. Check out the GCALL and related macros in STD.INS.ASPIC at http://www.embedinc.com/pic. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, spam_OUTolinTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu

> > PCLATH<4> | PCLATH<3> | GOTO PAGE > > -------------------------------- > > 0 0 Page 0 > > 0 1 Page 1 > > 1 0 Page 2 > > 1 1 Page 3 > > > > Right? Yes > > 1. What address do page 1, page 2, and page 3 start with? You can calculate the starting addresses from the following table: Core Size Page Size 12-bit 512 14-bit 2048 16-bit 8192 > > 3. Is there any trick to automatically switch the page? Is there any trick > > the treat the entire 8K of program memory as ONE page? Use EPICIS. ;-) Douglas Wood Software Engineer dbwoodKILLspamkc.rr.com Home of the EPICIS Development System for the PIC and SX http://epicis.piclist.com {Original Message removed}

Olin Lathrop wrote: >> 2. If I place a subroutine in Page 1, and I want to call it from page 0, >do >> I have to go to page 1 first before I can do a call (then switch back to >> page 0 to continue)? > >Whenever a GOTO or CALL is executed, PCLATH<4:3> must be set to indicate the >intended target page. > And, unless I am wrong, when you return from the CALL, you need to set the PCLATH bits back to the value of the "calling" page - although the datasheets are a little fuzzy about this. -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu

{Quote hidden}>From: Dan Michaels <EraseMEoricomspam_OUTTakeThisOuTUSWEST.NET> >Reply-To: pic microcontroller discussion list <PICLISTspam_OUTMITVMA.MIT.EDU> >To: @spam@PICLISTKILLspamMITVMA.MIT.EDU >Subject: Re: [PIC]: Program Memory Paging >Date: Mon, 16 Apr 2001 12:09:46 -0400 > >Olin Lathrop wrote: > > >> 2. If I place a subroutine in Page 1, and I want to call it from page >0, > >do > >> I have to go to page 1 first before I can do a call (then switch back >to > >> page 0 to continue)? > > > >Whenever a GOTO or CALL is executed, PCLATH<4:3> must be set to indicate >the > >intended target page. > > > >And, unless I am wrong, when you return from the CALL, you need to set >the PCLATH bits back to the value of the "calling" page - although the >datasheets are a little fuzzy about this. > >-- I agree with you, Dan. >http://www.piclist.com hint: To leave the PICList >KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

>> >Whenever a GOTO or CALL is executed, PCLATH<4:3> must be set to indicate >>the >> >intended target page. >> > >> >>And, unless I am wrong, when you return from the CALL, you need to set >>the PCLATH bits back to the value of the "calling" page - although the >>datasheets are a little fuzzy about this. You don't HAVE to do this unless you want to use another CALL or GOTO statement. And in this case, Olin's statement is still true; you must set the PCLATH bits to indicate the intended target page before they are executed. Of course, if you're trying to minimize your calls to pages other than the current one by grouping common routines together, then maybe it is best to reset the PCLATH bits once the call or goto has been completed to avoid unnecessary additional setting of PCLATH before each subsequent call. --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

No, you do not _have_ to set the PCLATH bits back to the value of the "calling" page on a return. A return does _not_ change the PCLATH at all. So, for example, this is a legal and perhaps useful way to do it: ; Page 0: movlw 20h movwf PCLATH call sub1 call sub2 call sub3 ; Page 1: org 2000h sub1: ... return sub2: ... return sub3: ... return Note that you can do other things between calling the subroutines, just don't include any 'goto's or 'call's that you expect to remain on page 0! Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) {Original Message removed}

Oh, Gakkk. At 12:33 PM 4/16/01 -0400, you wrote: {Quote hidden}>No, you do not _have_ to set the PCLATH bits back to the value of the >"calling" page on a return. A return does _not_ change the PCLATH at all. > >So, for example, this is a legal and perhaps useful way to do it: > > >; Page 0: > > movlw 20h > movwf PCLATH > > call sub1 > call sub2 > call sub3 > >; Page 1: > org 2000h >sub1: > ... > return > >sub2: > ... > return > >sub3: > ... > return > >Note that you can do other things between calling the subroutines, just >don't include any 'goto's or 'call's that you expect to remain on page 0! > >Bob Ammerman >RAm Systems >(contract development of high performance, high function, low-level >software) > > > >{Original Message removed}

> And, unless I am wrong, when you return from the CALL, you need to set > the PCLATH bits back to the value of the "calling" page - although the > datasheets are a little fuzzy about this. You don't need to, but I find it convenient to keep PCLATH pointing to the current code page. PCLATH only matters when a GOTO or CALL are executed, or on an explicit modification of PCL. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, RemoveMEolinTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu

> >1. What address do page 1, page 2, and page 3 start with? > > Well, each page starts with address 0. That's the reason > for all the confusion. Each page starts with zero in the page offset bits (by definition), but only page 0 starts at address 0. On the 16xxx family, GOTO and CALL contain 11 address bits in the opcode and the remaining high bits come from PCLATH. A new page therefore starts every 2**11 = 2048 = 800h addresses. On these cores, pages start as follows: page start address 0 0 1 800h 2 1000h 3 1800h So far all 16 family processors are limited to 8K program memory addresses, which is a maximum of 4 code pages. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, EraseMEolinembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestEraseMEEraseMEmitvma.mit.edu

I thought I would share a couple of macros I use to deal with code paging. These are for a 2-page machine (16C63 in this case). For a 4-page machine, it is a bit more complicated. To use: fcall Subroutine_in_other_page or: fgoto Label_in_other_page Potential trap: DON'T do btfsc STATUS,c fcall Subroutine_call_you_meant_to_skip The fcall macro will create 3 lines of code, but the skip instruction will only skip the first of these! Note: The MESSG line tells you if there's an unnecessary fcall, but I couldn't figure out how to get it to print the address in hex, so it's a pain to figure out where it happened. MPLAB reports the error location as being in the macro file, so that's totally useless. The errorlevel 306 stuff suppresses the now-meaningless warnings about references to the other code page. Using the bsf and bcf leave the W register undisturbed, which means it can still be used to pass and return arguments. This is especially important if you are using a call into the other page to do a lookup in a table or something. 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 fgoto macro t If((t & 0x800) == ($ & 0x800)) MESSG fgoto not actually needed at #v($). EndIf If (t & 0x800) bsf PCLATH,3 Else bcf PCLATH,3 EndIf errorlevel -306 goto t errorlevel +306 endm > {Original Message removed}

At 02:27 PM 4/16/01 -0400, you wrote: >> And, unless I am wrong, when you return from the CALL, you need to set >> the PCLATH bits back to the value of the "calling" page - although the >> datasheets are a little fuzzy about this. > >You don't need to, but I find it convenient to keep PCLATH pointing to the >current code page. PCLATH only matters when a GOTO or CALL are executed, or >on an explicit modification of PCL. > To new coders: Yes, you don't "need" to keep PCLATH always pointing at the current page, but if you don't keep your cross-page bookkeeping up-to-date in timely fashion, then about 1 inch down the road you're gonna get bit for certain. -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestspam_OUTKILLspammitvma.mit.edu

Do you have a similar code paging macros for 4-page machine (16F877)? {Quote hidden}>From: Don Hyde <RemoveMEDonHTakeThisOuTspamAXONN.COM> >Reply-To: pic microcontroller discussion list <EraseMEPICLISTspamspamBeGoneMITVMA.MIT.EDU> >To: RemoveMEPICLISTKILLspamMITVMA.MIT.EDU >Subject: Re: [PIC]: Program Memory Paging >Date: Mon, 16 Apr 2001 14:25:34 -0500 > >I thought I would share a couple of macros I use to deal with code paging. >These are for a 2-page machine (16C63 in this case). For a 4-page machine, >it is a bit more complicated. > >To use: > > fcall Subroutine_in_other_page > >or: > > fgoto Label_in_other_page > >Potential trap: > >DON'T do > > btfsc STATUS,c > fcall Subroutine_call_you_meant_to_skip > >The fcall macro will create 3 lines of code, but the skip instruction will >only skip the first of these! > >Note: > The MESSG line tells you if there's an unnecessary fcall, but I >couldn't figure out how to get it to print the address in hex, so it's a >pain to figure out where it happened. MPLAB reports the error location as >being in the macro file, so that's totally useless. >The errorlevel 306 stuff suppresses the now-meaningless warnings about >references to the other code page. >Using the bsf and bcf leave the W register undisturbed, which means it can >still be used to pass and return arguments. This is especially important >if >you are using a call into the other page to do a lookup in a table or >something. > >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 > >fgoto macro t > If((t & 0x800) == ($ & 0x800)) > MESSG fgoto not actually needed at #v($). > EndIf > If (t & 0x800) > bsf PCLATH,3 > Else > bcf PCLATH,3 > EndIf > > errorlevel -306 > goto t > errorlevel +306 > > endm > > > {Original Message removed}

Always creates a 5-instruction call. If you want to work on the macro with a bunch of additional If statements, you can make it optimize to the 3-instruction version when possible. I haven't bothered to do so, myself. fcall macro t If((t & 0x1800) == ($ & 0x1800)) MESSG fcall not actually needed at #v($). EndIf If (t & 0x1000) bsf PCLATH,4 Else bcf PCLATH,4 EndIf If (t & 0x800) bsf PCLATH,3 Else bcf PCLATH,3 EndIf errorlevel -306 call t errorlevel +306 If ($ & 0x1000) bsf PCLATH,4 Else bcf PCLATH,4 EndIf If ($ & 0x800) bsf PCLATH,3 Else bcf PCLATH,3 EndIf endm > -----Original Message----- > From: Thomas N [spamBeGonethomasn101STOPspamEraseMEHOTMAIL.COM] > Sent: Monday, April 16, 2001 3:23 PM > To: KILLspamPICLISTspamBeGoneMITVMA.MIT.EDU > Subject: Re: [PIC]: Program Memory Paging > > > Do you have a similar code paging macros for 4-page machine (16F877)? > SNIP -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestEraseMEmitvma.mit.edu

The fcall macro includes restoring PCLATH on return. {Quote hidden}> -----Original Message----- > From: Dan Michaels [@spam@oricom@spam@spam_OUTUSWEST.NET] > Sent: Monday, April 16, 2001 3:33 PM > To: spamBeGonePICLISTKILLspamMITVMA.MIT.EDU > Subject: Re: [PIC]: Program Memory Paging > > > Don Hyde wrote: > >I thought I would share a couple of macros I use to deal > with code paging. > >These are for a 2-page machine (16C63 in this case). For a > 4-page machine, > >it is a bit more complicated. > > > >To use: > > > > fcall Subroutine_in_other_page > > > >or: > > > > fgoto Label_in_other_page > > > ......... > > > Where are your macros for use after return from calls/etc ??? > > -- > http://www.piclist.com hint: To leave the PICList > .....piclist-unsubscribe-requestspam_OUTmitvma.mit.edu > > -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-request.....TakeThisOuTmitvma.mit.edu

Don Hyde <TakeThisOuTPICLISTKILLspamspamMITVMA.MIT.EDU> wrote: > Always creates a 5-instruction call. If you want to work on the macro > with a bunch of additional If statements, you can make it optimize to > the 3-instruction version when possible. I haven't bothered to do so, > myself. Don: If you had tried, though, you would have discovered that it ISN'T possible to do that with additional "if" statements; MPASM isn't happy with macros that conditionally assemble to varying code sizes. -Andy === Andrew Warren --- .....aiwRemoveMEcypress.com === IPD Systems Engineering, CYSD === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

If you had tried, though, you would have discovered that it ISN'T possible to do that with additional "if" statements; MPASM isn't happy with macros that conditionally assemble to varying code sizes. Really? All multipass assemblers tend to get pretty upset with macros that generate different amounts of code during different passes, but a macro that simply has variable (but consistant) sized output code should be OK. (Of course, this particular example is EXACTLY the sort of thing that causes different lengths during different passes. On pass1, some of your symbols (like your call destination) are undefined and will probably show up in calculations as zero or something. In pass2, they have real values and the conditional assembly goes different ways...) BillW -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-request@spam@spam_OUTmitvma.mit.edu

I wrote: > MPASM isn't happy with macros that conditionally assemble to > varying code sizes. and William Chops Westfield <TakeThisOuTbillwspamcisco.com> replied: > Really? All multipass assemblers tend to get pretty upset with > macros that generate different amounts of code during different > passes, but a macro that simply has variable (but consistant) sized > output code should be OK. Yes, but this particular example is EXACTLY the sort of thing that causes different lengths during different passes. > (Of course, this particular example is EXACTLY the sort of thing that > causes different lengths during different passes. Um, yeah. > On pass1, some of your symbols (like your call destination) are > undefined and will probably show up in calculations as zero or > something. In pass2, they have real values and the conditional > assembly goes different ways...) Precisely. In the first pass, MPASM assumes that all forward-referenced labels are equal to 0. Note that MPASM only makes this assumption for FORWARD references, though... So you CAN make a "long-call" macro that assembles to 1, 3, or 5 instructions, but only if the call destination appears ABOVE (i.e., before) the call in your source file. -Andrew === Andrew Warren --- aiwEraseMEcypress.com === IPD Systems Engineering, CYSD === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

----- Original Message ----- From: "Don Hyde" <@spam@DonHRemoveMEEraseMEAXONN.COM> To: <EraseMEPICLIST@spam@MITVMA.MIT.EDU> Sent: Monday, April 16, 2001 5:57 PM Subject: Re: [PIC]: Program Memory Paging > Always creates a 5-instruction call. If you want to work on the macro with {Quote hidden}> a bunch of additional If statements, you can make it optimize to the > 3-instruction version when possible. I haven't bothered to do so, myself. > > fcall macro t > If((t & 0x1800) == ($ & 0x1800)) > MESSG fcall not actually needed at #v($). > EndIf > If (t & 0x1000) > bsf PCLATH,4 > Else > bcf PCLATH,4 > EndIf > > If (t & 0x800) > bsf PCLATH,3 > Else > bcf PCLATH,3 > EndIf > > errorlevel -306 > call t > errorlevel +306 > > If ($ & 0x1000) > bsf PCLATH,4 > Else > bcf PCLATH,4 > EndIf > > If ($ & 0x800) > bsf PCLATH,3 > Else > bcf PCLATH,3 > EndIf > endm > > {Original Message removed}

> Always creates a 5-instruction call. If you want to work on the macro with > a bunch of additional If statements, you can make it optimize to the > 3-instruction version when possible. I haven't bothered to do so, myself. > > fcall macro t > If((t & 0x1800) == ($ & 0x1800)) > MESSG fcall not actually needed at #v($). > EndIf > If (t & 0x1000) > bsf PCLATH,4 > Else > bcf PCLATH,4 > EndIf > > ... Note that this will only work when T is known at assembly time. The PAGESEL pseudo-op must be used to set the page to that of an external routine. I've got a set of macros for doing various flavors of local and external calls. These are available in STD.INS.ASPIC at http://www.embedinc.com/pic. Here is a small snippett so you can see how they work: ; ;******************** ; ; Macro SETPAGE <address> ; ; Select the code page (by setting PCLATH) containing the indicated address. ; setpage macro adr if ncodepages <= 1 ;only one code page exists, no selection required ? exitm endif pagesel adr if fam_16 && (ncodepages == 2) ;need NOP bug workaround ? nop endif endm ; ;******************** ; ; Macro MYPAGE ; ; Sets PCLATH to the current code page, if this machine has multiple ; code pages. W may be trashed. ; mypage macro if ncodepages <= 1 ;only one code page exists, no need to set PCLATH ? exitm endif if fam_17 ;17Cxxx processor ? movfp pcl, wreg ;read PCL to load PCH into PCLATH exitm endif local here setpage here here endm ; ;******************** ; ; Macro GCALL <subroutine> ; ; Call a global subroutine, which could be anywhere in program memory. ; W is trashed between the caller and the subroutine, and can therefore not ; be used to pass data to the subroutine. The assumed register banks are ; set to invalid after the subroutine returns. ; ; No code page selection code is generated on machines that only have one ; code page. ; gcall macro subroutine setpage subroutine ;select the code page the subroutine is on call subroutine ;call the subroutine unbank ;invalidate register bank assumptions mypage ;restore PCLATH to the local page endm ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, @spam@olinspam_OUT.....embedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Conditionally assembling to varying code sizes is OK. The problem MPASM (and most macro assemblers) has is with macros that change size between the first and second passes. Trying to write macros that optimize relative branching can run into this. In this case, the optimization depends on which page the call and its target are in. If that can change from one pass to the next, then there's a problem, but I always use org's to force code into a page, so I know which page it is in. > {Original Message removed}

Hi everyone, I wrote this simple page switching macro and I put this file in page 0 (org 0x00). PAGE0 MACRO BCF PCLATH,3 BCF PCLATH,4 ENDM PAGE1 MACRO BSF PCLATH,3 BCF PCLATH,4 ENDM PAGE2 MACRO BCF PCLATH,3 BSF PCLATH,4 ENDM PAGE3 MACRO BSF PCLATH,3 BSF PCLATH,4 ENDM I put a file on Page 3 and when I try to use the Page3 macro, I get the following messages: Warning[207] C:\HAIFIL~1\PROJECT\TEMP.ASM 2 : Found label after column 1. (PAGE3) Error[116] C:\HAIFIL~1\PROJECT\MACRO.ASM 36 : Address label duplicated or different in second pass (PAGE3) How come I cannot use the Page macro above for the file on different page? Thank you very much! Thomas {Quote hidden}>From: Don Hyde <spamBeGoneDonHEraseMEAXONN.COM> >Reply-To: pic microcontroller discussion list <PICLISTspamBeGoneMITVMA.MIT.EDU> >To: RemoveMEPICLIST@spam@spamBeGoneMITVMA.MIT.EDU >Subject: Re: [PIC]: Program Memory Paging >Date: Tue, 17 Apr 2001 13:22:37 -0500 > >Conditionally assembling to varying code sizes is OK. The problem MPASM >(and most macro assemblers) has is with macros that change size between the >first and second passes. Trying to write macros that optimize relative >branching can run into this. In this case, the optimization depends on >which page the call and its target are in. If that can change from one >pass >to the next, then there's a problem, but I always use org's to force code >into a page, so I know which page it is in. > > > {Original Message removed}

Don Hyde <.....PICLIST@spam@EraseMEMITVMA.MIT.EDU> wrote: > Conditionally assembling to varying code sizes is OK. .... I > always use org's to force code into a page, so I know which page it > is in. Don: As I said before, "If you had tried it, you would have discovered that it isn't possible". Try it and you'll see. Unless the destination appears before the call in your source file, the ORGs don't matter; MPASM has no idea where any forward-referenced label is, no matter how many ORG statements are between the call and it. -Andy === Andrew Warren --- .....aiwRemoveMEcypress.com === IPD Systems Engineering, CYSD === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Ok so all this PCLATH setting bits are required if you call or goto accross a page boundry. What happens when normal program flow carries you over a boundry? Does PCLATH get updated automatically? or is it still up to you to set it. Say my program has a massive init sequence and the starting code runs halfway into page 1. When i then issue a call to a procedure ( also located in page 1 ) will pclath be set to page 1 or must i set it myself? In other words did it update itself when program execution flowed from page 0 to page 1? John -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestSTOPspam@spam@mitvma.mit.edu

John De Villiers <PICLISTEraseME@spam@MITVMA.MIT.EDU> wrote: > What happens when normal program flow carries you over a boundry? > Does PCLATH get updated automatically? No. -Andy === Andrew Warren --- RemoveMEaiwspamBeGonecypress.com === IPD Systems Engineering, CYSD === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu

BUT.... the PC *is* updated correctly. So your program will continue to flow just fine. {Quote hidden}> -----Original Message----- > From: pic microcontroller discussion list > [PICLISTspam_OUT@spam@MITVMA.MIT.EDU]On Behalf Of Andrew Warren > Sent: Thursday, April 26, 2001 1:59 PM > To: spamBeGonePICLIST@spam@MITVMA.MIT.EDU > Subject: Re: [PIC]: Program Memory Paging > > > John De Villiers <RemoveMEPICLISTEraseMEKILLspamMITVMA.MIT.EDU> wrote: > > > What happens when normal program flow carries you over a boundry? > > Does PCLATH get updated automatically? > > No. > > -Andy > > > === Andrew Warren --- spamBeGoneaiwspam_OUTRemoveMEcypress.com > === IPD Systems Engineering, CYSD > === Cypress Semiconductor Corporation > === > === Opinions expressed above do not > === necessarily represent those of > === Cypress Semiconductor Corporation > > -- > http://www.piclist.com hint: To leave the PICList > .....piclist-unsubscribe-requestRemoveMEmitvma.mit.edu > > -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-request@spam@mitvma.mit.edu

mmucker <EraseMEPICLISTRemoveMESTOPspamMITVMA.MIT.EDU> wrote: > > > What happens when normal program flow carries you over a > > > boundry? > > > Does PCLATH get updated automatically? > > > > No. > > BUT.... the PC *is* updated correctly. So your program will > continue to flow just fine. Yeah, until it hits a GOTO. -Andrew === Andrew Warren --- RemoveMEaiwKILLspamTakeThisOuTcypress.com === IPD Systems Engineering, CYSD === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-request@spam@mitvma.mit.edu

> Ok so all this PCLATH setting bits are required if you call or goto accross > a page boundry. What happens when normal program flow carries you over a > boundry? Does PCLATH get updated automatically? or is it still up to you to > set it. > > Say my program has a massive init sequence and the starting code runs > halfway into page 1. When i then issue a call to a procedure ( also located > in page 1 ) will pclath be set to page 1 or must i set it myself? In other > words did it update itself when program execution flowed from page 0 to page > 1? This has been beat to death many times. Check the archives (or better yet, read the manual). The short answers: 1 - Nothing happes to PCLATH automatically. 2 - It is best to avoid having code within a routine or module cross a page boundary. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, RemoveMEolinspam_OUTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspammitvma.mit.edu

----- Original Message ----- From: "John De Villiers" <spam_OUTbbjspam_OUTspam_OUTPLZ.CO.ZA> To: <PICLISTspam_OUTMITVMA.MIT.EDU> Sent: Thursday, April 26, 2001 1:50 PM Subject: Re: [PIC]: Program Memory Paging > Ok so all this PCLATH setting bits are required if you call or goto accross > a page boundry. What happens when normal program flow carries you over a > boundry? Does PCLATH get updated automatically? or is it still up to you to > set it. > > Say my program has a massive init sequence and the starting code runs > halfway into page 1. When i then issue a call to a procedure ( also located > in page 1 ) will pclath be set to page 1 or must i set it myself? In other > words did it update itself when program execution flowed from page 0 to page > 1? PCLATH is never changed by the pic itself. You have to set it manually. PCLATH is used to fill in the extra bits for CALL's GOTO's and other instructions(e.g. ADDWF) which directly modify to PCL register. The PCL register will flow over to a new page without problem. But, you still must set PCLATH if you are going to do any call's or goto's (outside of page 0, that is). I hope this helps some. > > John > > -- > http://www.piclist.com hint: To leave the PICList > RemoveMEpiclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu > > -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspamBeGone.....mitvma.mit.edu