Searching \ for 'PicAssembly' 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: 'PicAssembly'.

Truncated match.
PICList Thread
'PicAssembly'
1998\05\12@223309 by Peter Schultz

flavicon
face
Hi All,

Please help to a C language PICer.
I have to modify a code written in assembly.

M_LOOP  BCF     PORTA,LED
               BC      M_LOOP

Can somebody explain me what kind code is the: BC
Also it has code  called BZ .

Thank You,
Peter
spam_OUTschupetTakeThisOuTspamdvp.com

1998\05\12@231430 by Peter Schultz

flavicon
face
Hi All,
Thank You,
and sorry same time,
I found it, BZ and BC belongs to the special instructions set.
Peter
.....schupetKILLspamspam@spam@dvp.com

1998\05\12@235122 by David Sorlien

picon face
>From the MPASM.HLP file, appendix D:

Mnemonic   Description         EquivalentOperation(s)

BC k       Branch on Carry     BTFSC 3,0
                              GOTO k
BZ k       Branch on Zero      BTFSC 3,2
                              GOTO k


Looks to me like this is an infinite loop when the carry flag is set on
entry to your code snippet ... unless the interrupt handler does not
save/restore the STATUS register and modifies the carry flag!

Dave Sorlien


Peter Schultz wrote:

{Quote hidden}

1998\05\13@075632 by Peter L. Peres

picon face
>BC

BC There == Branch on Carry == BTFSC, CARRY (2,1)
                              GOTO There   (2)

>BZ

BZ There == Branch on Zero == BTFSC, ZERO (2,1)
                             GOTO There  (2)

imho someone should compile an online version of these macro explanations
soon, because they get asked about every 2 days or so.

Peter

1998\05\13@080254 by Peter L. Peres

picon face
On Tue, 12 May 1998, Peter Schultz wrote:

> Hi All,
> Thank You,
> and sorry same time,
> I found it, BZ and BC belongs to the special instructions set.
                                      ^^^^^^^^^^^^^^^^^^^

Sorry, no special instructions on PICs, thanks Microchip (who is not
Intel). They are MACROS.

Peter (plp)

> Peter
> .....schupetKILLspamspam.....dvp.com
>
>
>

1998\05\13@162146 by Andrew Warren

face
flavicon
face
Peter L. Peres <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU> wrote:

> imho someone should compile an online version of these macro
> explanations soon, because they get asked about every 2 days or so.

Here's a copy of a message I wrote about a year ago...

------- Forwarded Message Follows ------

The following pseudo-ops are understood by MPASM directly; no
include file, etc., is needed in order to use them.

          PIC16CXX SPECIAL INSTRUCTION MNEMONICS

    Name                Mnemonic       Equivalent       Status
                                      Operation(s)
Clear Carry                CLRC        BCF      3,0        -
Clear Digit Carry          CLRDC       BCF      3,1        -
Set Digit Carry            SETDC       BSF      3,1        -
Clear Zero                 CLRZ        BCF      3,2        -
Set Zero                   SETZ        BSF      3,2        -
Skip on Carry              SKPC        BTFSS    3,0        -
Skip on No Carry           SKPNC       BTFSC    3,0        -
Skip on Digit Carry        SKPDC       BTFSS    3,1        -
Skip on No Digit Carry     SKPNDC      BTFSC    3,1        -
Skip on Zero               SKPZ        BTFSS    3,2        -
Skip on Non Zero           SKPNZ       BTFSC    3,2        -
Test File                  TSTF f      MOVF     f,1        Z
Move File to W             MOVFW f     MOVF     f,0        Z
Negate File                NEGF f,d    COMF     f,1
                                      INCF     f,d        Z
Add Carry to File          ADDCF f,d   BTFSC    3,0
                                      INCF     f,d        Z
Subtract Carry from File   SUBCF f,d   BTFSC    3,0
                                      DECF     f,d        Z
Add Digit Carry to File    ADDDCF f,d  BTFSC    3,1
                                      INCF     f,d        Z
Subtract Digit             SUBDCF f,d  BTFSC    3,1
Carry from File                        DECF     f,d        Z
Branch                     B k         GOTO     k          -
Branch on Carry            BC k        BTFSC    3,0
                                      GOTO     k          -
Branch on No Carry         BNC k       BTFSS    3,0
                                      GOTO     k          -
Branch on Digit Carry      BDC k       BTFSC    3,1
                                      GOTO     k          -
Branch on No Digit Carry   BNDC k      BTFSS    3,1
                                      GOTO     k          -
Branch on Zero             BZ k        BTFSC    3,2
                                      GOTO     k          -
Branch on Non Zero         BNZ k       BTFSS    3,2
                                      GOTO     k          -
Call across page boundary  LCALL k     BCF 3,5 or BSF 3,5
                                      BCF 3,6 or BSF 3,6
                                      CALL     k

By the way, don't bother using the "LCALL" pseudo-op... Since it
doesn't restore the code-page bits after the CALL, it's sorta
useless.  Also, be careful with the pseudo-ops that assemble to two
instructions; constructs like the following, for instance, will cause
you great pain and suffering:

   ; DON'T DO THIS!

   BTFSS   FLAGS,SWITCH    ;If the switch is pressed, skip ahead.
   NEGF    REG             ;Otherwise, negate the REG register.

------- End of Forwarded Message ------

-Andy

=== Andrew Warren - fastfwdspamspam_OUTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499 (personal)
=== http://www.netcom.com/~fastfwd (business)

1998\05\14@074549 by g.daniel.invent.design

flavicon
face
Ah Ha !
I've caught you out !

Regarding the below, stack is taken from actual location at a CALL or
LCALL.
stack is wider than PCL, includes  non R/W  PCH bits.  When you set
program page select bits, these do not take effect until the actual jump
or call at which time a special internal operation transfers them to the
the otherwise non R/W PCH register.

Easy english: LCALL does not spoil return address on stack.


Andrew Warren wrote:
> By the way, don't bother using the "LCALL" pseudo-op... Since it
> doesn't restore the code-page bits after the CALL, it's sorta
> useless.

       , Leave it to the PIC to save and restore stack correctly !

1998\05\14@100537 by Andy David

flavicon
face
> Andrew Warren wrote:
> > By the way, don't bother using the "LCALL" pseudo-op... Since it
> > doesn't restore the code-page bits after the CALL, it's sorta
> > useless.

Graham Daniel added:
> Regarding the below, stack is taken from actual location at a CALL or
> LCALL.
> stack is wider than PCL, includes  non R/W  PCH bits.  When you set
> program page select bits, these do not take effect until the actual jump
> or call at which time a special internal operation transfers them to the
> the otherwise non R/W PCH register.
>
> Easy english: LCALL does not spoil return address on stack.


       You are correct, it doesn't spoil the return address.

       BUT...

       after the return, PCLATH will still contain the code page bits as set by
       the LCALL, so any subsequent CALL/GOTO/operation-using-PCL-as-destinatio
n
       will use them, which is what Andy meant. LCALL would be more useful if
       it restored PCLATH upon return. If you have to manipulate PCLATH manuall
y
       when you DO use LCALL, you may as well not use LCALL and control PCLATH
       yourself.


- Andy.

----------------------------------------------------------
Andrew David, Software Manager, Ultronics Ltd, Cheltenham.
@spam@akdavidKILLspamspamUltronics.co.uk          http:\\http://www.ultronics.com
----------------------------------------------------------

1998\05\15@034621 by Tom Handley

picon face
  Andy, the way the Parallax assembler handles this is with an LCALL/LSET
pair of instructions. LCALL generates 0-2 BCF/BSF instructions followed by a
CALL. LSET then generates 0-2 BCF/BSF instructions to restore PCLATH. If you
wanted to, you could use LCALL/LSET everywhere. If you call a routine in the
same code page then:

     LCALL   addr
     LSET    $

  becomes:

     CALL    addr

  - Tom

At 02:55 PM 5/14/98 +0100, Andy David wrote:
{Quote hidden}

set by
>        the LCALL, so any subsequent
CALL/GOTO/operation-using-PCL-as-destination
>        will use them, which is what Andy meant. LCALL would be more useful if
>        it restored PCLATH upon return. If you have to manipulate PCLATH
manually
{Quote hidden}

1998\05\15@095025 by Andrew Warren

face
flavicon
face
I wrote:

> > By the way, don't bother using the "LCALL" pseudo-op... Since it
> > doesn't restore the code-page bits after the CALL, it's sorta
> > useless.

and G.Daniel Invent Design <RemoveMEg.daniel.invent.designTakeThisOuTspamxtra.co.nz> wrote:

> Ah Ha !
> I've caught you out !

   I'm afraid you haven't, G.Daniel... You've simply missed my
   point.

> stack is taken from actual location at a CALL or LCALL. stack is
> wider than PCL, includes  non R/W  PCH bits. When you set program
> page select bits, these do not take effect until the actual jump or
> call at which time a special internal operation transfers them to
> the the otherwise non R/W PCH register.
>
> Easy english: LCALL does not spoil return address on stack.

   Yes, I know... My point was that after the RETURN (to the
   correct address), the PCLATH register will still contain the
   value stored in it before the LCALL.

   The next GOTO or CALL instruction encountered by the PIC,
   therefore, will cause a branch to a location on the same page as
   the subroutine that was LCALLed.  For example:

           ORG     0x0000

           LCALL   A800
           GOTO    A50

           ORG     0x50

   A50:    NOP

           ORG     0x800

   A800:   RETURN

In the above code fragment, the LCALL branches to address 800, then
the RETURN (correctly) points the PC back to the GOTO. Because the
PCLATH register wasn't restored after the CALL, however, the GOTO
branches to address 850 rather than to address 50.

That's why I recommend against using LCALL; it's much safer to just
write your own "long CALL" macros to adjust PCLATH before _and
after_ the CALL.

-Andy

=== Andrew Warren - spamBeGonefastfwdspamBeGonespamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499 (personal)
=== http://www.netcom.com/~fastfwd (business)

1998\05\15@100522 by Andy David

flavicon
face
>    Andy, the way the Parallax assembler handles this is with an
LCALL/LSET
> pair of instructions. LCALL generates 0-2 BCF/BSF instructions followed
by a
> CALL. LSET then generates 0-2 BCF/BSF instructions to restore PCLATH. If
you
> wanted to, you could use LCALL/LSET everywhere. If you call a routine in
the
> same code page then:
>
>       LCALL   addr
>       LSET    $
>
>    becomes:
>
>       CALL    addr


       Yes, that does look more useful than MPASM's LCALL which was
       what I was describing. The last 16c73 application I wrote ended
       up about 3 1/2 K and I was using MPASM. I started off using LCALLs
       for calls across code pages, but I found out that I was still
       having to handle about half the maintenance of PCLATH myself
       (restoring PCLATH after the return of an LCALL). I also found
       that with a little care and thought I could manage the
       maintenance of PCLATH myself with better results than if I
       just used LCALLs.


- Andy.

----------------------------------------------------------
Andrew David, Software Manager, Ultronics Ltd, Cheltenham.
TakeThisOuTakdavidEraseMEspamspam_OUTUltronics.co.uk          http:\\http://www.ultronics.com
----------------------------------------------------------

1998\05\15@131801 by Andy Kunz

flavicon
face
>----------------------------------------------------------
>Andrew David, Software Manager, Ultronics Ltd, Cheltenham.
>RemoveMEakdavidspamTakeThisOuTUltronics.co.uk          http:\\http://www.ultronics.com
>----------------------------------------------------------

Uh-oh.  Another Andy on the list.  Has he been assigned an ANDY NUMBER yet <G>

Andy #5

==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\05\15@145911 by DREITEK

picon face
In a message dated 98-05-15 13:18:32 EDT, you write:

<<
>----------------------------------------------------------
>Andrew David, Software Manager, Ultronics Ltd, Cheltenham.
>akdavidEraseMEspam.....Ultronics.co.uk          http:\\http://www.ultronics.com
>----------------------------------------------------------

Uh-oh.  Another Andy on the list.  Has he been assigned an ANDY NUMBER yet
<G>

Andy #5

==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================
 >>
Hi Andy #5
Do your friends call you Andy Dave???

Dave Duley

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