Searching \ for '[PIC]: custom mpasm mnemonics' 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/languages.htm?key=asm
Search entire site for: 'custom mpasm mnemonics'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: custom mpasm mnemonics'
2000\09\20@113115 by staff

flavicon
face
Roman wrote:
>
> I especially like the skpz, skpnz, tstf etc. These are great and
> really make the code easy to read. If there was one tip I had to
> give to a pic newbie it would be to get used to using these
> special mnemonics.
>
> Does anyone have home-made instructions they like to use?
>
> I quite like:
>
> incw
> decw
> setbank0
> setbank1


Am I the only person here who uses custom instructions?
Nobody has a comw or incw in their code??

Curious. :o)

--
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


2000\09\20@124850 by Sam Linder

flavicon
face
Roman:
<snip>
Sam, the skpc, skpnc etc are official Microchip mnemonics that
simply equate to the ridiculous "btfsc STATUS,C" stuff that
mightmares are made of. You actually prefer that??
<snip>

I agree that the Microchip mnemonics are the "stuff that nightmares are made
of." Do I prefer them? No.

<snip>
The incw and decw are my custom ones... I find it hard
to believe that you would have difficulty interpreting my
"incw" instruction... :o)
<snip>

It isn't so much a case of interpreting your custom mnemonics, it's a case
of trying to learn everyone's custom mnemonics. If everyone created a
different custom instruction for a basic Microchip mnemonic, I'd go nuts
trying to remember all the variations.

It's somewhat akin to what happened with Unix. By making the source of their
utility programs available for modification, everyone and their brother
created variations on a theme. So, anytime you went to a different Unix
shop, you would encounter similar utilities under a wide range of names.
(Any Unix folks who take umbrage to this, please don't respond, I've been
down that road too many times)

Since you correctly pointed out that "skpc, skpnc etc are official Microchip
mnemonics", I can't argue that those would be acceptable in a PIC assembly
language program. However, as I discovered, not all compilers accept them as
such. For example, Hi-Tech C does not recognize the special instruction
mnemonics, thus I must always use the basic Microchip instruction set.

       Sam....



{Original Message removed}

2000\09\20@131827 by staff

flavicon
face
Sam Linder wrote:
{Quote hidden}

I really do respect your personal preferences Sam, I just find it
amazing that someone prefers "btfss STATUS,z" to skpz...

Anyone else care to comment? Or does this remain a black/white
argument? Surely the point of good programming practices is to
make the code easier to read, and less errors in the interpretation
of the code by another person. And of course make it easier to
type it in!

To my way of thinking the skpz etc mnemonics are far superior to
the btfss STATUS,z equivalent and my personal preference to use
custom mnemonics like incw is superior to addlw 0x01??

Comments?

--
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


2000\09\21@084333 by Olin Lathrop

flavicon
face
> > SKIP_WLE  ;skip if W less than or equal from last SUBLW or SUBWF
> > SKIP_WGT  ;skip if W greater than ...
>
> I really like those skip_wle and skip_wgt mnemonics! Thanks,
> will make good use of those in the future! Does anyone else
> have any other good ones?

Since you plan on using them, I have included the source code below to save
you the trouble of re-creating them.

;
;********************
;
;   Macro SKIP_WLE
;
;   Skip the next instruction if W was less than or equal to the value
;   it was subtracted from.  This assumes that the carry flag has been
;   preserved from the last SUBWF or SUBLW instruction.
;
skip_wle macro
 if fam_17
        btfss   alusta, c
        exitm
   endif

        btfss   status, c   ;skip if no borrow occurred
        endm
;
;********************
;
;   Macro SKIP_WGT
;
;   Skip the next instruction if W was greater than the value
;   it was subtracted from.  This assumes that the carry flag has been
;   preserved from the last SUBWF or SUBLW instruction.
;
skip_wgt macro
 if fam_17
        btfsc   alusta, c
        exitm
   endif

        btfsc   status, c   ;skip if a borrow occurred
        endm
;
;********************
;
;   Macro SKIP_Z
;
;   Skip the next instruction if the zero flag is set.
;
skip_z   macro
 if fam_17
        btfss   alusta, z
        exitm
   endif

        btfss   status, z
        endm
;
;********************
;
;   Macro SKIP_NZ
;
;   Skip the next instruction if the zero flag is not set.
;
skip_nz  macro
 if fam_17
        btfsc   alusta, z
        exitm
   endif

        btfsc   status, z
        endm
;
;********************
;
;   Macro SKIP_CARR
;
;   Skip the next instruction if a carry occurred.
;
skip_carr macro
 if fam_17
        btfss   alusta, c
        exitm
   endif

        btfss   status, c
        endm
;
;********************
;
;   Macro SKIP_NCARR
;
;   Skip the next instruction if no carry occurred.
;
skip_ncarr macro
 if fam_17
        btfsc   alusta, c
        exitm
   endif

        btfsc   status, c
        endm
;
;********************
;
;   Macro SKIP_BORR
;
;   Skip the next instruction if a borrow occurred.
;
skip_borr macro
 if fam_17
        btfsc   alusta, c
        exitm
   endif

        btfsc   status, c
        endm
;
;********************
;
;   Macro SKIP_NBORR
;
;   Skip the next instruction if no borrow occurred.
;
skip_nborr macro
 if fam_17
        btfss   alusta, c
        exitm
   endif

        btfss   status, c
        endm
;
;********************
;
;   Macro INTR_OFF
;
;   Globally disable interrupts without changing which interrupts are
;   individually disabled.  This macro together with INTR_ON can be used
;   around small sections of code that need to run with interrupts off.
;
intr_off macro
 if fam_16
        bcf     intcon, gie
   endif
 if fam_17
        bsf     cpusta, glintd
   endif
        endm
;
;********************
;
;   Macro INTR_ON
;
;   Globally enable interrupts without changing which interrupts are
;   individually enabled.  This macro together with INTR_OFF can be used
;   around small sections of code that need to run with interrupts off.
;
intr_on  macro
 if fam_16
        bsf     intcon, gie
   endif
 if fam_17
        bcf     cpusta, glintd
   endif
        endm



*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spam_OUTolinTakeThisOuTspamcognivis.com, http://www.cognivis.com

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


2000\09\21@132137 by staff

flavicon
face
Thank you Olin! You are a true gentleman.
:o)
Roman



Olin Lathrop wrote:
{Quote hidden}

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


2000\09\22@045318 by Simon Nield

flavicon
face
having recently looked through Thomas McGahee's PICUART code (thankyou whoever it was who posted the
URL btw)
I think the interrupt off macro may be improved as follows:


WAS:
> intr_off macro
>   if fam_16
>          bcf     intcon, gie
>     endif
>   if fam_17
>          bsf     cpusta, glintd
>     endif
>          endm


BETTER?:
intr_off macro
  if fam_16
foo:
         bcf     intcon, gie
         btfsc   intcon, gie
         goto    foo
    endif
  if fam_17
bar:
         bsf     cpusta, glintd
         btfss   cpusta, glintd
         goto    bar
    endif
         endm


the _16 code certainly makes sense to me. no idea about th _17 code as I have not used this family


cut & paste of the reasoning behind the code from Thomas' code:
;If an IRQ happens when the "bcf intcon,gie" line is executing,
;the GIE bit will be cleared, but the interrupt will still occur.
;If the interrupt routine has a RETFIE instruction at the
;end, (which is the usual state of affairs),then GIE will
;be set to 1 again.


Regards,
Simon

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use listservspamKILLspammitvma.mit.edu?body=SET%20PICList%20DIGEST


2000\09\22@094400 by Olin Lathrop

flavicon
face
{Quote hidden}

I was the one who posted the original macro.  Is this true!?  Can an
interrupt really happen immediately after the instruction that disables
interrupts?  This seems hard to believe.  I've never seen any mention of
this issue in the Microchip docs, and yes, I DO read the manual.  If this
were really true I would expect at least a one of those gray boxes
mentioning this issue.

I just re-read the interrupt section of the 16F87x and 17C7xx data sheets
and didn't see any mention of this issue.  Both mentioned a possible
interrupt latency of up to 2 or 3 cycles from external conditions, but I am
assuming the interrupt still can't take place if they are globally disabled.
Someone from Microchip please confirm/deny this?

By the way, if you are going to put labels in a macro like this, you really
should declare them LOCAL.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspamspam.....cognivis.com, http://www.cognivis.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu?body=SET%20PICList%20DIGEST


2000\09\22@100243 by Alan B. Pearce

face picon face
>I was the one who posted the original macro.  Is this true!?  Can an
>interrupt really happen immediately after the instruction that disables
>interrupts?  This seems hard to believe.  I've never seen any mention of

Apparently yes. I have not experienced it, but have seen code with this sort of construct in it. The scenario seems to be that the interrupt occurrence is tested separately during the execution of the disable instruction, without the enable flag being checked immediately at the end of the instruction. This can occur because the instruction is a general purpose one which could be setting or clearing any bit anywhere in the chip, and hence cannot lockout testing of the interrupt line during its execution. Hence there could be a leap off to the interrupt routine before executing the next instruction.

On processors that have a specific instruction to disable interrupts, it would be possible in the decoding of the instruction to not test the interrupt line, and hence not require this jiggery pokery operation to ensure the  interrupts are disabled when you believe they are.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use listservspamspam_OUTmitvma.mit.edu?bodyT%20PICList%20DIGEST


2000\09\22@182028 by Olin Lathrop

flavicon
face
>>
>I was the one who posted the original macro.  Is this true!?  Can an
>interrupt really happen immediately after the instruction that disables
>interrupts?  This seems hard to believe.  I've never seen any mention of

Apparently yes. I have not experienced it, but have seen code with this sort
of construct in it. ...
<<

Hmm.  I'm trying to separate true fact from urban legend?  Does anyone have
proof one way or the other regading this behaviour?

Microchip, are you out there?


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, @spam@olinKILLspamspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use KILLspamlistservKILLspamspammitvma.mit.edu?body=SET%20PICList%20DIGEST


2000\09\24@161429 by John

flavicon
face
Hello PIC.ers,

A subtle gotcha, this one.
BTDT, got the T-shirt.

After disabling interrupts i.e.
   bcf    intcon,gie
complete safety is not assured unless you check the global enable
bit to see that it *really* is as expected (clear, that is).

My trouble with this magically vanished when I started to use macros
for int. enable/disable:


int_off         MACRO                ;disables all interrupts
                    bcf intcon,gie
                    btfsc intcon,gie  ;make sure bit cleared (int could
                                                  ;have occurred 1/2way
thru instruction)
                    goto $-2
          ENDM

int_on         MACRO               ;re-enable interrupts
                    bsf intcon,gie
          ENDM

best regards,   John


{Quote hidden}

e-mail from the desk of John Sanderson, JS Controls.
Snailmail:          PO Box 1887, Boksburg 1460, Rep. of South Africa.
Tel/fax:            Johannesburg  893 4154
Cellphone no:   082 469 0446
email:                spamBeGonejsandspamBeGonespampixie.co.za
Manufacturer & purveyor of laboratory force testing apparatus, and related
products and services.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\09\24@211826 by Tony Nixon

flavicon
picon face
Olin Lathrop wrote:
>
> >>
> >I was the one who posted the original macro.  Is this true!?  Can an
> >interrupt really happen immediately after the instruction that disables
> >interrupts?  This seems hard to believe.  I've never seen any mention of
>
> Apparently yes. I have not experienced it, but have seen code with this sort
> of construct in it. ...
> <<
>
> Hmm.  I'm trying to separate true fact from urban legend?  Does anyone have
> proof one way or the other regading this behaviour?
>
> Microchip, are you out there?

It doen't matter in this code using MPLAB

That suggests that the bcf INTCON,GIE kills the IRQ even if TMR0
overflows on that instruction. External IRQ's may have a different
mechanism.

To check it, I dumped the code into ROMzap and it worked the same.

I still remember reading something about it however, but it may be
because of externally genertaed interrupts.

       org 0h

       goto start

       org 4h

       bcf INTCON,T0IF
       retfie

start   bsf STATUS,RP0
       clrf OPTION_REG
       bcf STATUS,RP0

       clrf TMR0
       bcf INTCON,T0IF
       bsf INTCON,T0IE
       bsf INTCON,GIE

       movlw 0xA8
       movwf temp
loop    decfsz temp
       goto loop

       nop
       nop
       nop
       nop
       nop

; this NOP EXcluded, TMR0 IRQ fires on bcf INTCON,GIE
; this NOP INcluded, TMR0 IRQ fires on NOP

;       nop
       bcf INTCON,GIE
       goto loop


--
Best regards

Tony

ICmicro's
http://www.picnpoke.com
TakeThisOuTsalesEraseMEspamspam_OUTpicnpoke.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\09\25@003536 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

Just had a quick look and I can not find any reference to this in the 16F87X
data sheets.  However, this was a known problem with the 16C6X and 16C7X
devices.  The datasheet says:
"If an interrupt occurs while the Global Interrupt Enable (GIE) bit isbeing
cleared, the GIE bit may unintentionaly be re-enabled by the users Interrupt
Service Routine (the RETFIE instruction)."
It then goes on to describe the work around which is as per the macro's
above.

Perhaps this has been fixed in later silicon?

Mike

--
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


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