Searching \ for 'Odd PCL behaviour solved' 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/index.htm?key=odd+pcl+behaviour
Search entire site for: 'Odd PCL behaviour solved'.

Truncated match.
PICList Thread
'Odd PCL behaviour solved'
1998\10\16@082146 by Stuart Allen

flavicon
face
Hello,

I have discovered my problem. Whenever a computed goto is executed PCLATH
must be set to match the current PC location, even if the source and target
of the jump have the same PCLATH value. This isn't neccessary if the table
is between 0 and 255 because PCLATH is zero.

By moving TEST in the following code this is demonstrated. The ADDWF PCL, F
behaves as if it is in the first 256 byte block, and the computed goto jumps
to 0+PCL.

The data sheet says:

"The contents of PCLATH are transferred to the upper byte of the program
counter when the PC is loaded with a new value. This occurs during a CALL,
GOTO or a write to PCL."

(However, there is a difference in the way and PCLATH is used by CALL and
GOTO, vs. PCL)

Conclusion: Computed goto's don't work without changes to PCLATH unless the
table is below 100H.

Excuse: The following paragraph on computed goto's mentions nothing about
this, only that care should be taking if a table location crosses a PCL
boundary.

Thanks for your ideas,

Stuart.



     LIST    P=16C84

#include "P16C84.INC"

       ORG     4

       B       TEST

       ORG     100H

TEST    ; MOVLW 1               ; 100H+=1, 200H+=2, 300H+=3
       ; MOVWF PCLATH  ; adding these two lines fixes the problem

       MOVLW   8
       ADDWF   PCL, F          ; Note: PCL=1, add 8 = 9. ie. no overflow into P
CLATH.

       END

1998\10\19@064251 by Caisson

flavicon
face
> Van: Stuart Allen <spam_OUTallenTakeThisOuTspamSONY.DE>
> Aan: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
> Onderwerp: Odd PCL behaviour solved
> Datum: vrijdag 16 oktober 1998 11:48
>
> Hello,
>
> I have discovered my problem. Whenever a computed goto is executed PCLATH
> must be set to match the current PC location, even if the source and
target
> of the jump have the same PCLATH value.

WRONG !  Your PCLATH should be set to the TARGET-locations page !!

>This isn't neccessary if the table
> is between 0 and 255 because PCLATH is zero.

This is _STILL_ neccessary : you just don't have to _CHANGE_ it when it's
allready pointing to the right page ...

> By moving TEST in the following code this is demonstrated. The ADDWF PCL,
F
> behaves as if it is in the first 256 byte block, and the computed goto
jumps
> to 0+PCL.
>
> The data sheet says:
>
> "The contents of PCLATH are transferred to the upper byte of the program
> counter when the PC is loaded with a new value. This occurs during a
CALL,
> GOTO or a write to PCL."

Hereby confirming my first statement : PCLATH is used to calculate the
TARGET adress, and has nothing to do with the CURRENT adres ....

> (However, there is a difference in the way and PCLATH is used by CALL and
> GOTO, vs. PCL)
>
> Conclusion: Computed goto's don't work without changes to PCLATH unless
> the table is below 100H.

Duh !

> Excuse: The following paragraph on computed goto's mentions nothing about
> this, only that care should be taking if a table location crosses a PCL
> boundary.

What the book say's is OK.  If your table resides within a single page you
set PCLATH to that page.

The problem the book adresses is when you have a table that is partly in
one page, and partly in the next ...

> Thanks for your ideas,
>
> Stuart.

Greetz,
 Rudy Wieser

1998\10\19@073817 by Stuart Allen

flavicon
face
>>This isn't neccessary if the table is between 0 and 255 because PCLATH is
zero.
>
>This is _STILL_ neccessary : you just don't have to _CHANGE_ it when it's
>allready pointing to the right page ...

This is correct, but when the target is in page zero, PCLATH IS already
pointing at the right page, so the statement is true. The example code I
gave demonstrated this, and this is why my code, cited in my first mail,
works.

>Duh !

Thanks.

>What the book say's is OK.  If your table resides within a single page you
>set PCLATH to that page.

Thats the answer I was looking for. Thanks.

Stuart.

>Greetz,
>  Rudy Wieser

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