Searching \ for '[PIC]: Re: Help understanding 16F84' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=16F
Search entire site for: 'Re: Help understanding 16F84'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Re: Help understanding 16F84'
2003\04\07@172938 by Andrew Warren

flavicon
face
Luis A. Loeff <spam_OUTPICLISTTakeThisOuTspammitvma.mit.edu> wrote:

{Quote hidden}

Luis:

If W is always guaranteed to be either 0 or 1 after the CALL, then
page boundaries clearly ARE the problem; there's no other
explanation, especially since interrupts can't be happening.

If you don't want to use the "aux1" register, you can do:

   CALL    READ80
   XORLW   0
   BZ      REFI
   MOVF    BREG,W

-Andy

=== Andrew Warren -- .....aiwKILLspamspam@spam@cypress.com
=== Principal Design Engineer
=== 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

2003\04\18@115201 by Luis A. Loeff

flavicon
face
{Quote hidden}

Hi Andy Warren,

I agree that page boundaries have to be the problem and indeed I am

sure they are, because in my case I found that none of the similar to

the above snippets of code will work in  any page other than 0.

( first 256  adresses of flash ). I had to change all addwf pcl, f

in all pages except the  00, for code to run.





>
> If you don't want to use the "aux1" register, you can do:
>
>     CALL    READ80
>     XORLW   0
>     BZ      REFI

                         Are you sure this is 16F84 code ?  BZ ??

>     MOVF    BREG,W
>
> -Andy
>

Regards

Luis A. Loeff

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\04\18@135049 by SOLID Corp.

picon face
You need to set the PCLATH (PC Latch High) register before writing to the
PCL register.  The 16F84 has 1K max (10 bits) worth of addressable program
space.  The goto and call functions load the entire 10 bits from the opcode
but writing to the PCL register directly will combine the written value as
the low 8 bits with the lower 2 bits of the PCLATH register as the high bits
to create a 10 bit destination address.  PCLATH is initialized to 0 at boot
which is why the code sample does not work, it keeps branching into page 0.
The register will retain the last value written so you must be careful when
you start using it.

The following code will do a computed branch to any address in the address
space.

   MOVLW    HIGH FARLABEL
   MOVWF    PCLATH
   MOVLW    LOW FARLABEL
   ADDWF    OFFSET,W
   MOVWF    PCL
   .
   .
   .

FARLABEL

Another approach I have used is to put all of my lookup tables or
subroutines into specific pages, then if I need to do multiple accesses I
set the PCLATH register once at the beginning.

Scott Williamson
@spam@SOLIDCorpKILLspamspamameritech.net








{Original Message removed}

2003\04\18@140536 by Andrew Warren

flavicon
face
Luis A. Loeff <KILLspamPICLISTKILLspamspammitvma.mit.edu> wrote:

> > CALL    READ80
> > XORLW   0
> > BZ      REFI
>
> Are you sure this is 16F84 code ?  BZ ??

   Yes, it's 16F84 code.  BZ is a pseudo-op built into MPASM; it
   assembles to:

       BTFSC   STATUS,Z
       GOTO    REFI

   This and all the other pseudo-ops are documented in the "MPASM
   User's Guide with MPLINK and MPLIB" (in Table B.11, on page 184,
   of version G).

   -Andrew







{Quote hidden}

=== Andrew Warren -- RemoveMEaiwTakeThisOuTspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\04\18@144133 by Olin Lathrop

face picon face
> The following code will do a computed branch to any address in the
> address space.
>
>     MOVLW    HIGH FARLABEL
>     MOVWF    PCLATH
>     MOVLW    LOW FARLABEL
>     ADDWF    OFFSET,W
>     MOVWF    PCL
>     .
>     .
>     .
>
> FARLABEL

Not exactly.  This assumes that LOW FARLABEL plus the contents of offset
does not exceed 255.  This is only guaranteed to be true if the table at
FARLABEL starts at a 256 word boundary (FARLABEL is multiple of 256).  A
more general approach is:

    movlw    high table  ;get table start address high byte
    movwf    pclath      ;init jump address high byte
    movf     offset, w   ;get table entry number in W
    addlw    low table   ;make table entry address low byte
    skip_nc              ;no carry into high address byte ?
    incf     pclath      ;propagate carry into high adr byte
    movwf    pcl         ;jump to the selected table entry

This is the approach I recommend you always use except in rare cases where
the few extra instructions matter for speed or memory size.  Note that
this code needs a slight tweak for the 18 family, since each instruction
takes up 2 memory addresses, and GOTOs take up 4.

> Another approach I have used is to put all of my lookup tables or
> subroutines into specific pages, then if I need to do multiple accesses
> I set the PCLATH register once at the beginning.

That sort of manual management of PCLATH will sooner or later cause some
nasty bugs.  It is also a maintenence nightmare in the making.

I use more automated PCLATH handling.  See the GCALL and related macros in
STD.INS.ASPIC at http://www.embedinc.com/pic.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\04\19@010933 by Josh White

flavicon
face
I am a little confused by this question.  I thought that the 16f84 has only
1023 bytes of memory.  If you look at the goto instruction, you can access
all 1023 locations, so I do not see why you need to mess around with the pcl
because there is only one page of memory.  Am I wrong here?  I hope not
because so far my program runs fine and I just assumed the goto instruction
can access everything.  Let me know.  Thanks.

--------------------------------------------
Joshua Melbourne White
Vice Chair
NCSU Student Chapter of IEEE
Treasurer
Eta Kappa Nu, Beta Eta Chapter
North Carolina State University
Electrical and Computer Engineering
--------------------------------------------


{Original Message removed}

2003\04\19@013740 by Bob Ammerman

picon face
Josh:

The GOTO and CALL instructions each contain a 10 bit target address that can
reach any location in the 16F84.

However, when you want to do a computed got (like ADDWF PCL,F) you have to
take some special considerations.

Here is a little more detail:

Bits from PCLATH are used to complete the target PC value for GOTO and CALL
instructions and any instruction with explicitly modifies PCL.

Since GOTO and CALL include an 11-bit address, they can access up to 2048
locations. In PICs like the F84, which only contain 1024 instruction words,
GOTO and CALL can thus access the entire program memory. However, even in
these PICs the high order 2 bits of the new PC are obtained from PCLATH,3
and PCLATH,4. These bits would normally be zero on an F84.

Instructions that modify PCL, like "ADDWF PCL,F" are a beast of another
color, however. Since PCL is only 8 bits long, the PIC has to get the rest
of the bits for the PC from PCLATH. So, when you execute an instruction like
this, bits 4 downto 0 of PCLATH are concatenated with the 8 bits of PCL to
determine the target PC. On the F84, with its 1024 instruction words the two
LSBits of PCLATH effectively select one of four 246 word 'pages'. The other
bits of PCLATH would typically be zero.

Vectoring to an interrupt, and returning from a subroutine or interrupt do
NOT need to access PCLATH. The vector always go directly to location 4, and
returns can return to a complete 13-bit address on the stack.

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Josh White" <spamBeGonejmwhite3spamBeGonespamUNITY.NCSU.EDU>
To: <TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU>
Sent: Saturday, April 19, 2003 1:08 AM
Subject: Re: [PIC]: Re: Help understanding 16F84


> I am a little confused by this question.  I thought that the 16f84 has
only
> 1023 bytes of memory.  If you look at the goto instruction, you can access
> all 1023 locations, so I do not see why you need to mess around with the
pcl
> because there is only one page of memory.  Am I wrong here?  I hope not
> because so far my program runs fine and I just assumed the goto
instruction
{Quote hidden}

> {Original Message removed}

2003\04\19@020116 by Josh White

flavicon
face
Ah, ok.  I think I understand now, but I guess I just don't see the power or
usefulness of doing a calculated goto.  Can you give me an example of when
this would be useful?  Thanks.
--------------------------------------------
Joshua Melbourne White
Vice Chair
NCSU Student Chapter of IEEE
Treasurer
Eta Kappa Nu, Beta Eta Chapter
North Carolina State University
Electrical and Computer Engineering
--------------------------------------------


{Original Message removed}

2003\04\19@024705 by Bob Ammerman

picon face
Lots of possibilities.

==== One of the most common is a state machine.

   call run_state_machine    ; run the machine
   movwf    state                 ; remember new state

run_state_machine:
   movf    state,f
   movwf    PCL
   retlw

state_0:
   btfsc    some_input
   retlw    low(state_0)        ; stay in state 0
   retlw    low(state_1)        ; go to state 1

state_1:
   btfss     some_input
   retlw    low(state_0)        ; go to start 0
   retlw    low(state_1)        ; stay in state

==== Or decoding commands.

   movf    command_code,f
   addwf    PCL,F
   goto    do_command_0
   goto    do_command_1
   goto    do_command_2

==== Or performing a table lookup using a collection of RETLW instructions
after an ADDWF PCL,F:

power_of_two:
   movf    index,W
   addwf    PCL,F
   retlw    X'01'
   retlw    X'02'
   retlw    X'04'
   retlw    X'08'
   retlw    X'10'
   retlw    X'20'
   retlw    X'40'
   retlw    X'80'

Remember, all these examples assume PCLATH contains the correct value, and
that the table entries are all on the same 256 instruction 'page'.
Bob Ammerman
RAm Systems

----- Original Message -----
From: "Josh White" <RemoveMEjmwhite3spamTakeThisOuTUNITY.NCSU.EDU>
To: <PICLISTEraseMEspam.....MITVMA.MIT.EDU>
Sent: Saturday, April 19, 2003 1:59 AM
Subject: Re: [PIC]: Re: Help understanding 16F84


> Ah, ok.  I think I understand now, but I guess I just don't see the power
or
{Quote hidden}

> {Original Message removed}

2003\04\19@025934 by Josh White

flavicon
face
Thank you for the examples.  They really cleared things up for me.  I would
have done all that the long drawn out way with a bunch of comparisons, but
this method really saves a lot of programming space.  Thanks again.

--------------------------------------------
Joshua Melbourne White
Vice Chair
NCSU Student Chapter of IEEE
Treasurer
Eta Kappa Nu, Beta Eta Chapter
North Carolina State University
Electrical and Computer Engineering
--------------------------------------------


{Original Message removed}

2003\04\19@081325 by Olin Lathrop

face picon face
> Ah, ok.  I think I understand now, but I guess I just don't see the
> power or usefulness of doing a calculated goto.  Can you give me an
> example of when this would be useful?

The same kind of places where you would do a CASE statement in Pascal, or
a SWITCH statement in C.  See the HOS_CMD.ASPIC module in my HOS PIC
project at http://www.embedinc.com/pic/hos.htm.  It contains a jump table
for dispatching to different command routines based on the command opcode.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\04\25@143257 by Luis A. Loeff

flavicon
face
Hi List


It seems that to keep track of pclath in order to use addwf pcl, f
in pages other than 00 is a burden, very prone to errors so it is better
to avoid it. That is the conclusion after reading replies.

Regards

Luis A. Loeff



{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\04\25@164800 by Bob Barr

flavicon
face
On Fri, 25 Apr 2003 14:32:57 -0400, you wrote:

>Hi List
>
>
>It seems that to keep track of pclath in order to use addwf pcl, f
>in pages other than 00 is a burden, very prone to errors so it is better
>to avoid it. That is the conclusion after reading replies.
>

The nice thing about the code that Olin posted is that you don't have
to keep track of anything at all. It works great.

The assembler handles the address constants involved and the program's
execution handles any page overlaps. You don't have to worry about
what's in PCLATH or where your table ends up in memory. It's all done
for you (and, as a bonus, it's done correctly every time you use it).


Regards, Bob


<snip>

Olin wrote:

{Quote hidden}

<snip>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

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