Searching \ for '[PIC]:Paging Issues' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Paging Issues'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:Paging Issues'
2000\08\17@114300 by Andy Stubbins

flavicon
picon face
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
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu>

2000\08\17@122854 by Don Hyde

flavicon
face
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 removed}

2000\08\17@123505 by Dan Michaels

flavicon
face
Andy Stubbins wrote:
..........
>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
.........


Andy,

I have read the exact same words from Mchp, and had exactly the same
experience as you. Maybe someone else can decipher them better than me.
However, I have found that code along the following lines seems to work
reliably:

           call    zero                ; set zero state.
           bsf     PCLATH,     3       ; select page 1 for call.
           call    set_async           ; config serial port.
           call    auto_baud           ; autoset baud rate.
           bcf     PCLATH,     3       ; select page 0.
           call    signon

This is for PIC73/74, which have 2 code pages. The code shown resides
in page 0, the middle 2 routines are in page 1, the others in page 0.
All routines end with a simple < return > statement.

In other words, the appropriate PCLATH bit is manually adjusted
both *before* and *after* making calls to other pages.

I use the same format for making calls to page 0 from page 1, in
which case, of course, the bit set/clr would be reversed from
that shown here.

best regards,
- Dan Michaels
Oricom Technologies
===================

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu>

2000\08\17@124114 by Dan Michaels

flavicon
face
Don Hyde wrote:
............
>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.
>

Ditto, ditto. [this and possibly trying to figure out where regW is
stored after an interrupt call].
=================

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

If you ever go to the Scenix - Mchp do-alikes - you'll find they have
their own set of anachronisms, but they did figure out how to handle
the page switching with relative grace. Coming back to Mchp from Scenix
usually requires a strong jolt of java.

- danM

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu>

2000\08\17@145905 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Aahh the old 'friend' PCLATH is back ;-)
Kidding aside some minor comments:

Andy Stubbins wrote:

>pagesel <label>
>call    <label>
>;do something
>return

Yes this is not 'safe', You also need to ( as others suggested )
use an additional pagesel after the call but before the return to set to
current page ( calling ).

Don Hyde wrote:

>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>
>
Hmmm strange this, according to the data sheet YES, BUT not according to
my own testings, try it, it actually uses BSF/BCF instructions at least
on the 16F8xx Ive tried on.
Nether the less it cannot be trusted.

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

Yep !!

Anyway to give some suggestions,
look at some erlier ramblings by me and others at:

www.piclist.com/techref/default.asp?from=/techref/piclist/../micr
ochip/&url=pages.htm

'Mine' are at the bottom and should work A-OK ( except the last L_CALL
thats redundant and originates from some 'playing around' )

SHORT_CALL      - Page0 <-> Page1 OR Page2 <-> Page3, two additional
instructions totally
LONG_CALL   - Any page <-> any page, four additional instructions
totally ( the same as two pagesel's )
PCALL       - same page call BUT with REAL warning for page crossings
+ some 'help' macros

Have fun,

/Tony



Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: .....tony.kubekKILLspamspam.....flintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu>

2000\08\18@033110 by Andy Stubbins

flavicon
picon face
Thanks for the suggestions guys hopefully should crack it now.

Andy

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\08\18@110350 by Olin Lathrop

flavicon
face
>>
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 )
<<

You are right, PCLATH is not effected by call/return.  In a multi-page
environment, you have to assume that PCLATH is trashed on return from
external subroutines.  I use a macro called GCALL (global call) that
restores PCLATH to the current page after return from the subroutine.  I set
up separate linker sections for each page, so the code for each module is
guaranteed to be on a single page.  Therefore local calls and GOTOs work
fine after restoring PCLATH to the current page.

On 14 bit code devices, you can restore PCLATH by using a temporary label in
the assembler macro (MOVLW  HIGH HERE, MOVWF PCLATH).  On 17C and 18C
devices any read of PCL will set PCLATH to the current page.  Just don't get
lazy and try to do a "read" on PCL by doing MOVF PCL, F.  That will also do
a write, which will cause a jump to the trash page instead of a reload to
the correct page.

And no, of course CLRF PCLATH won't work unless you are on page 0.  This can
be a legitimate shortcut in an interrupt routine, which I always start right
at the last interrupt vector.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinspamspam_OUTcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\08\18@110357 by Olin Lathrop

flavicon
face
> Personally, I have found the linker to be pretty disfunctional, and always
> assemble directly (i.e. without the linking step).

I use multi-module code almost exclusively.  While the linker is a bit
primitive, it seems to work as documented.  The only linker bug I've found
in doing many PIC projects this way is the PAGESEL bug in MPLAB 5.00, which
was fixed in 5.11.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, @spam@olinKILLspamspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

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