Searching \ for 'Odd PCL behaviour on 16C84' 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=16C
Search entire site for: 'Odd PCL behaviour on 16C84'.

Truncated match.
PICList Thread
'Odd PCL behaviour on 16C84'
1998\10\12@041328 by Stuart Allen

flavicon
face
Hello,

I use the modification of PCL extensively to implement switch statements.
And I am fully aware of the consideration that must be given to PCLATH.

However, if I modify PCL when in the top 100H bytes of a 16C84 processor, it
doesn't work. The processor jumps off to somewhere completely different to
where I want it to go.

This also happens in the DOS simulator! I haven't done very much
investigation into this problem, I just keep all my jump tables in the first
page of ROM and that avoids it.

I don't know exactly where in RAM this problem starts occuring, but it's
near the top on ROM.

Please note that in this case, I do NOT modify PCLATH, because I know that
the table doesn't cross a 100H boundary.

Has anybody else noticed this? Have I mis-understood/missed something?

More investigation with a simulator or emulator would be useful I know.

Thanks for any insight,

Stuart.

1998\10\12@075203 by Valter Gruntar

flavicon
face
part 0 4521 bytes
<P>I see that you have the same problem that I had. I've resolved that
after long experiments with MPLAB-SIM because I didn't understood the data
sheet.You have to check out the AN556 on the Microchip's site.You can put
a table any where you want in prog.memory but you have to preset the PCLATH
before the call table is executed.
<BR>example.
<BR>PC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;
opcode
<BR>----------------------------
<BR>xxx&nbsp;&nbsp;&nbsp; main&nbsp;&nbsp;&nbsp;&nbsp; -
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-
<BR>xxx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;
movlw&nbsp;&nbsp;&nbsp; H'0<B>2</B>'
<BR>xxx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;
movwf&nbsp;&nbsp;&nbsp; PCLATH
<BR>xxx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;
call&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Table
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-
<BR><B>2</B>46&nbsp;&nbsp;&nbsp; Table&nbsp; addwf&nbsp;&nbsp;&nbsp; PCL
<BR><B>2</B>47&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;
retlw&nbsp;&nbsp;&nbsp; ....
<BR><B>2</B>48&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;
retlw&nbsp;&nbsp;&nbsp; ....
<BR><B>2</B>49&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;
............
<BR><B>2</B>xx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;
- // -

<P>You have to check, on which page in the prog.memory is the Table. In
this example the Table begin in the H'<B>2</B>46' so PCLATH has to be preloaded
with H'0<B>2'</B>. Be carefull that the Table doesn't cross a page boundary.
If it does , you can check out AN556 example 6.The best way to check where
the Table begin and stop is to assembly the program and check in the program.lst
file.

<P>good luck, Valter

<P>Stuart Allen wrote:
<BLOCKQUOTE TYPE=CITE>Hello,

<P>I use the modification of PCL extensively to implement switch statements.
<BR>And I am fully aware of the consideration that must be given to PCLATH.

<P>However, if I modify PCL when in the top 100H bytes of a 16C84 processor,
it
<BR>doesn't work. The processor jumps off to somewhere completely different
to
<BR>where I want it to go.

<P>This also happens in the DOS simulator! I haven't done very much
<BR>investigation into this problem, I just keep all my jump tables in
the first
<BR>page of ROM and that avoids it.

<P>I don't know exactly where in RAM this problem starts occuring, but
it's
<BR>near the top on ROM.

<P>Please note that in this case, I do NOT modify PCLATH, because I know
that
<BR>the table doesn't cross a 100H boundary.

<P>Has anybody else noticed this? Have I mis-understood/missed something?

<P>More investigation with a simulator or emulator would be useful I know.

<P>Thanks for any insight,

<P>Stuart.</BLOCKQUOTE>
&nbsp;</HTML>

</x-html>

1998\10\12@205005 by James Cameron

flavicon
face
Valter Gruntar wrote:
> You have to check, on which page in the prog.memory is the Table.

Can't you just load the register with a bitwise shifted and masked copy
of the current address pointer "$"?

table   movlw   x
       movwf   PCLATH
       addwf   PCL,f
data    retlw   ...
       retlw   ...

Where "x" would be the MPASM (or gpasm) syntax equivalent for the C
expressed "data>>8".  And this is?

--
James Cameron                                    (spam_OUTcameronTakeThisOuTspamstl.dec.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

1998\10\13@072741 by Caisson

flavicon
face
> Van: Stuart Allen <.....allenKILLspamspam@spam@SONY.DE>
> Aan: PICLISTspamKILLspamMITVMA.MIT.EDU
> Onderwerp: Odd PCL behaviour on 16C84
> Datum: maandag 12 oktober 1998 10:09
>
> Hello,
>
> I use the modification of PCL extensively to implement switch statements.
> And I am fully aware of the consideration that must be given to PCLATH.
>
> However, if I modify PCL when in the top 100H bytes of a 16C84 processor,
it
> doesn't work. The processor jumps off to somewhere completely different
to
> where I want it to go.

That's funny ... Because of the hasseling with PCLATH I myself keep my
tables (the few that I use) in the last 0100h bytes of memory (in the 16C84
and others). I do not see any out-of-the-ordinary behavour ...

> This also happens in the DOS simulator! I haven't done very much
> investigation into this problem, I just keep all my jump tables in the
first
> page of ROM and that avoids it.

DOS simulator for 16C84 ?  What's it's name ?

> I don't know exactly where in RAM this problem starts occuring, but it's
> near the top on ROM.
>
> Please note that in this case, I do NOT modify PCLATH, because I know
that
> the table doesn't cross a 100H boundary.

It's not because of the _crossing_ of a page-boundary, but because of the
Jump _target_ that you will have to set PCLATH.  In other words : the
source of the indirect-jump does not matter, the target of the jump does.
It's perfecly legal to have a Indirect-jump vector of 0x40 to 0x60 and than
to have the ADDWF PCL command at any adress higher-or-equal to 0xC0 in the
page just in front of the page where PCLATH points to.  (0xC0 + 0x40 -->
target will be in the page PCLATH points to ...)

> Has anybody else noticed this? Have I mis-understood/missed something?

I myself have not.  Maybe, I do not know.  Please supply the offending
routine for close scrutiny ... :-)

Greetz,
 Rudy Wieser

1998\10\13@200131 by Tony Nixon
flavicon
picon face
Stuart Allen wrote:
>
> Hello,
>
> I use the modification of PCL extensively to implement switch statements.

When you modify the Program Counter value by using an instruction such
as ADDWF PCL, the new Program Counter value becomes the value in PCL
concatenated with the 5 lower bits of the PCLATH register.

Example.

PC = 0010h  = 0 0000 0001 0000

PCL is always the lower 8 bits of the PC value so,

PCL = 10h = 0001 0000

If the value in W Reg = 5h and the ADDWF PCL instruction is executed
then 5h is added to the PCL value.

   10h  0001 0000
+   05h  0000 1001
=        0001 1001

New PCL value = 15h

Because the PCL value is connected to the lower 8 bits of the Program
Counter, they must also change.

Just by changing the PCL value does not enable us to move anywhere in
the PIC's ROM space. That would only allow us to move anywhere in the
first 256 ROM addresses. The mechanism to enable us to move to
'anywhere' in the PICs ROM space is by using 5 bits from the PCLATH
register.

The reason we use '5 bits only' from the PCLATH is because the PC is 13
bits wide. So the 8 bits from PCL plus the 5 bits from PCLATH = 13 bits.

Moving on from the above example...

PCLATH = 01h  = 0000 0001    PCL = 05h  = 0000 1001

Merge these together we get

                  0 0001                 0000 1001

New 13 bit PC value = 0 0001 0000 1001.

This new value is now placed into the Program Counter.

Because of the PIC's architecture, the PC value is incremented by 1.

PC value now = 0 0001 0000 1010  = 0106h.
This address is where the next instruction will be fetched from.

The 16F84 only has a 1K ROM space so only 11 bits from the PC value are
used.

eg.  001 0000 1010 = 106h

Notice how we were able to move more than 256 ROM locations from the
original instruction.


Hope this helps.

--
Best regards

Tony

Multimedia 16F84 Beginners PIC Tools.
**New Improved PicNPost**

http://www.picnpoke.com
Email .....picnpokeKILLspamspam.....cdi.com.au

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