Searching \ for '[PIC]: FSR and page boundry help needed (please)' 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/devices.htm?key=pic
Search entire site for: 'FSR and page boundry help needed (please)'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: FSR and page boundry help needed (please)'
2004\01\02@161232 by Steve Smith

flavicon
face
Good evening people:
How does one manage the fsr when doing a table read that crosses a page
boundary? I guess there is a high bit somewhere but ones mind is still
flushed from new year and has lost its ability to retain information.
Thanks in advance

Steve

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@162307 by

picon face
Steve Smith wrote:
> Good evening people:
> How does one manage the fsr when doing a table read that
> crosses a page
> boundary? I guess there is a high bit somewhere but ones mind is still
> flushed from new year and has lost its ability to retain information.
> Thanks in advance

Hi.

You don't say which PIC model, but just as an
example, for the 16F628A it's on page 26 of
data sheet DS40300B. For other PICs it might
very well be other page numbers of course...

Btw, you *are* talking about "indirect reads"
using the FSR register, not ?

And it's "banks" not "pages", right ?

I don't think the FSR reg is used in table reads
in program memory (where the "pages" are located)...

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@163344 by Steve Smith

flavicon
face
Its an '877 and me text block starts at 0800h
It's a big bunch of ascii for a display but I got loads a messages and
about half way throu msg 34 (address 08ff) it jumps to the wrong place
middle of some previous message (PCL should be 256 for the computed
jump) but I aint sure where bit 9 of the pointer is
Steve..

{Original Message removed}

2004\01\02@165320 by

picon face
Steve Smith wrote:

> Its an '877 and my text block starts at 0800h

OK, so it's table reads in program memory then. But then,
I dont see where the FSR reg comes into play...

> It's a big bunch of ascii for a display but I got loads a messages

What messages ?

> and about half way throu msg 34

I don't know what "msg 34" is.

> (address 08ff) it jumps to the wrong place
> middle of some previous message (PCL should be 256 for the computed
> jump) but I aint sure where bit 9 of the pointer is

What "pointer" ?

Well, definitly time to show some code...
A stripped down example that shows the problem
would be fine.

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@165943 by Bob Barr

flavicon
face
On Fri, 2 Jan 2004 21:31:41 -0000, Steve Smith wrote:

>Its an '877 and me text block starts at 0800h
>It's a big bunch of ascii for a display but I got loads a messages and
>about half way throu msg 34 (address 08ff) it jumps to the wrong place
>middle of some previous message (PCL should be 256 for the computed
>jump) but I aint sure where bit 9 of the pointer is

Well, that's an issue with PCLATH rather than with the FSR. When you
compute your GOTO address, you've got to propogate any carry out of
the lower 8 bits of the PC up into the PCLATH bits.


Regards, Bob

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@170410 by Bob Barr

flavicon
face
On Fri, 2 Jan 2004 21:31:41 -0000, Steve Smith wrote:

>Its an '877 and me text block starts at 0800h
>It's a big bunch of ascii for a display but I got loads a messages and
>about half way throu msg 34 (address 08ff) it jumps to the wrong place
>middle of some previous message (PCL should be 256 for the computed
>jump) but I aint sure where bit 9 of the pointer is

Sorry, my previous post didn't explain why this is the case. PCL can't
ever be 256; it's only an 8-bit register. The "L" indicactes its the
low byte of the target address. Any overflow from computing its value
must be put up into PCLATH to jump to the correct address, i.e the
address in the correct page.

Regards, Bob

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@170414 by Josh Koffman

flavicon
face
Steve, there are some excellent resources about this in the source code
library at http://www.piclist.com. Have a look there, you may find what
you need.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

Steve Smith wrote:
> How does one manage the fsr when doing a table read that crosses a page
> boundary? I guess there is a high bit somewhere but ones mind is still
> flushed from new year and has lost its ability to retain information.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@171024 by Steve Smith

flavicon
face
Code attached sorry bout FSR its nothing to do with it. Its (AN556)
computed goto crossing 256 bit page boundary. All messages up to and
including 33 are ok but when pcl >255 it starts reading from the wrong
place.
Steve

STRNUM is the message to be displayed
TABOFF is the pointer to the char to be returned
;------------------INCREMEMTS CHARTHER POINTER FOR TEXT STRING----------
POINT   MACRO

       INCF    TABOFF,F
       MOVFW   TABOFF
       ADDWF   PCL,F
       ENDM

Org 0800h
LAST    EQU     b'10000000'     ; SIGNIFIER FOR LAST CHAR

CALLSTR
       MOVFW   STRNUM  ; GET STRING
       ADDWF   PCL,1   ; WHICH STRING
       GOTO    MSG0    ; blah
         GOTO    MSG1  ; blah

       goto    MSG34           ; blah

; lots of text strings here

MSG34   POINT
       RETLW   'B'
       RETLW   'A'
       RETLW   'T'
       RETLW   'T'
       RETLW   'E' ;<this actual address 08ffh (returns ok)
       RETLW   'R' ;never gets here but returns from somewhere else
       RETLW   'Y'
       RETLW   ' '
       RETLW   'C'
       RETLW   'B'+LAST


{Original Message removed}

2004\01\02@171650 by Jinx

face picon face
> Its an '877 and me text block starts at 0800h
> It's a big bunch of ascii for a display but I got loads a messages
> and about half way throu msg 34 (address 08ff) it jumps to the
> wrong place middle of some previous message (PCL should
> be 256 for the computed jump) but I aint sure where bit 9 of the
> pointer is
> Steve..

Aw, don't 'e talk luvverly [thanks for reminding me what I'm missing
while Eastenders is off for a week ;-) ]

Try indexing as per AN556, which is to increment and test PCL
before doing the call. If there's a rollover in PCL then increment
PCLATH

http://www.microchip.com/download/appnote/pic16/00556e.pdf

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@171652 by Jinx

face picon face
> Its (AN556) computed goto crossing 256 bit page boundary

Example 5 is what you need. Your code does nothing to
PCLATH, and that's the address high byte. Using PCL on
its own means you're stuck in a 256-byte black hole

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@172100 by Olin Lathrop

face picon face
Steve Smith wrote:
> How does one manage the fsr when doing a table read that crosses a
> page boundary?

Huh?  The FSRs have nothing to do with table reads or page boundaries.  FSRs
only point to data memory.  Table read is a means of reading program memory.

> I guess there is a high bit somewhere but ones mind is
> still flushed from new year and has lost its ability to retain
> information.

There's always the manual.

On the 16 family, the high bit of the address when using an FSR comes from
the STATUS register.  However, on the 18 family the FSRs contain the
complete address.

What PIC are you using?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, 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

2004\01\02@172306 by Steve Smith

flavicon
face
Am allowed 2 I comes frm Devon we all talks luverly down there !
(now in Bristol acents worserer ere!)
Stev

{Original Message removed}

2004\01\02@172928 by Olin Lathrop

face picon face
Steve Smith wrote:
> Its an '877 and me text block starts at 0800h
> It's a big bunch of ascii for a display but I got loads a messages and
> about half way throu msg 34 (address 08ff) it jumps to the wrong place
> middle of some previous message (PCL should be 256 for the computed
> jump) but I aint sure where bit 9 of the pointer is

OK, step back from the PIC, and actually *read* the manual.  Pay particular
attention to the data and program memory organization, to FSRs, and PCLATH.

You are confusing almost too many issues to enumerate.  If you're reading a
"text block", why is the program counter there?  What does this have to do
with FSRs as in your original post?  What does it have to do with table
reads, since the 16F877 doesn't have them?

In any case, you seem to be wondering where the upper bits of the PC come
from when PCL is modified.  The answer is from PCLATH.  READ THE MANUAL!


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, 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

2004\01\02@173137 by David P Harris

picon face
Hi Steve-
Surprisingly hard to get a straight answer.  However, assuming you are
using the 16F series, have a look at the PICLIST archives at:
http://www.piclist.com/techref/microchip/tables.htm

Here is one of the code snippets:

       fcall    Table
; will be returned here with data in W.



       ; Tony Nixon
       ; plus tweak from Dmitry Kiryashov [zews at AHA.RU]
Table   movlw High(TStart)
       addwf OffsetH,W
       movwf PCLATH
       movlw Low(TStart)
       addwf OffsetL,W
       skpnc
         incf PCLATH,F

       movwf   PCL     ;computed goto with right PCLATH
       ; end of Table subroutine.


       ; ...
       ;
       org 0x????
TStart  Retlw d'0'
       Retlw d'255'
       Retlw d'9'
       ....
       etc


As you can see, you have to account for when you roll over the 256 boundary on the address, and correct the PCLATH.

David





Steve Smith wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@173758 by Olin Lathrop

face picon face
Steve Smith wrote:
> Code attached sorry bout FSR its nothing to do with it. Its (AN556)
> computed goto crossing 256 bit page boundary. All messages up to and
> including 33 are ok but when pcl >255 it starts reading from the wrong
> place.

OK, so you are trying to read data from program memory by using RETLW
instructions.  The best way to read data from program memory on a 16F877 is
not to use RETLW instructions, but read it directly.  This can be done with
the same interface used for reading the data EEPROM.  See section 4 starting
on page 41 of "PIC16F87x Data Sheet", DS30292C.

For dealing with PCL wrap around issues you have to manage PCLATH.  You
really have to read them manual.  Read pages 26 and 27 of the same book,
which contain section 2.3 "PCL and PCLATH", section 2.4 "Program Memory
Paging", and section 2.5 "Indirect Addressing, INDF and FSR Registers".  The
last section isn't relevant here, but you are obviously confused about the
content.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, 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

2004\01\02@182902 by

picon face
Jinx wrote :
>
> > Its (AN556) computed goto crossing 256 bit page boundary
>
> Example 5 is what you need...


Just a minor note...

A couple of months ago there was a thread where I and Olin
(mostly) showed that AN556 is just full of errors (and maybe
correct but badly written code anyway).

Example 5 is maybe the most obvious example of this.
(Hint: What happens if the code in example 5 is entered with
offest = x'00' ?)

I'm not going to re-write all comments here, they should
be available from the archive...

:-)

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@184355 by Jinx

face picon face
> A couple of months ago there was a thread where I and Olin
> (mostly) showed that AN556 is just full of errors (and maybe
> correct but badly written code anyway).

Ah, noted. As I wrote yesterday "Microchip has been cited for
publishing dodgy material". Maybe I should have said it twice,
once for the list and once for me ;-)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\02@191329 by Steve Smith

flavicon
face
Thanks guys I now have a better grasp ov it just gotta rewrite me macro
to take account of PCLATH

Thanks Steve

{Original Message removed}

2004\01\02@193027 by

picon face
I wrote :

> Example 5 is maybe the most obvious example of this.
> (Hint: What happens if the code in example 5 is entered with
> offest = x'00' ?)


OK, here's what happens. This is a stripped down "example 5".
Let's say that the "offest" register is x'00' :

  movlw  LOW Table
  addwf  offset, F   ; offset = "LOW Table".
  movf   offset, W   ; W-reg = "LOW Table".
  call   Table

Table
  movwf  PCL, F      ; PCL = "LOW Table".

and we have an endless loop :-)

The fact that I have stripped out the PCLATH handling
doesn't change *this* error.

The descriptive text in AN556 is OK i think, but the code
examples must be carefully used.

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

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