Searching \ for '[PIC] Misc. ASM questions' 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: 'Misc. ASM questions'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Misc. ASM questions'
2005\08\01@000004 by GM

picon face

Hello,

PIC newbie here. I have a couple of questions that have come up over the
past month or so. Neither one is a burning issue, I'd just like to know
the answers, or at least collect a few opinions.

First, refer to the documentation for the RRF and RLF instructions in
MicroChip's Mid-Range MCU manual. I have a question about the contents
of the W register after either of these instructions are executed. The
examples (pages 29-36 and 29-37) show that the contents of W are not
defined prior to executing the instruction, but then they show that W
contains 0x17 after execution. The W reg is not the destination for the
instruction, which is given as RRF INDF,1. The bit-shifted value ends up
in the register whose pointer is in FSR, just as I expect. What I do not
expect or understand is why W would contain a value that doesn't have
any obvious relationship to the contents of the destination register.

I understand the rest of the "Example 2" code just fine - the contents
of the target register and the carry bit are just what I expect. How
does W get set to 0x17? Or does it? I wonder if that is just an
arbitrary example. If so, it is confusing.

Second, I'm wondering just how much use most programmers make of the
assembler directives. There are a LOT of directives available, yet when
I look at other folk's source code it seems that only a very few
directives ever actually show up in the code. The #include, EQU, and a
few others are very common, as is using $ to refer to the PC. That seems
about it. For example, I'd expect to see more use of DA, DT, BANKISEL,
and BANKSEL. Are there non-obvious drawbacks to using the MPASM
directives?

Thanks,
  Glenn Minch

2005\08\01@002841 by Spehro Pefhany

picon face
At 09:00 PM 7/31/2005 -0700, you wrote:
><snip>

>  What I do not
>expect or understand is why W would contain a value that doesn't have
>any obvious relationship to the contents of the destination register.

Looks like a simple mistake. The value of W should not be affected in
example 2, so if it has some arbitrary value prior to the RRF with
file destination, it will have the same value afterward.

>I understand the rest of the "Example 2" code just fine - the contents
>of the target register and the carry bit are just what I expect. How
>does W get set to 0x17? Or does it? I wonder if that is just an
>arbitrary example. If so, it is confusing.

There are lots of mistakes in data sheets and manuals. Not just Microchip.
So, if you find something confusing or if there is a conflict between
different bits of info, either you don't understand fully or there is
a mistake. ;-)

{Quote hidden}

Maybe they like to keep close to the 'metal'. Using macros and assembler
directives puts a bit of daylight in there. Not as much as a compiler does.
Inline asm code in a compiler may not have that stuff easily available.
Also in showing code fragments, I think it can be confusing.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\08\01@004520 by Dmitriy Kiryashov

picon face
Hi Glenn.

> First, refer to the documentation for the RRF and RLF instructions in
> MicroChip's Mid-Range MCU manual. I have a question about the contents
> of the W register after either of these instructions are executed. The
> examples (pages 29-36 and 29-37) show that the contents of W are not
> defined prior to executing the instruction, but then they show that W
> contains 0x17 after execution. The W reg is not the destination for the
> instruction, which is given as RRF INDF,1. The bit-shifted value ends up
> in the register whose pointer is in FSR, just as I expect. What I do not
> expect or understand is why W would contain a value that doesn't have
> any obvious relationship to the contents of the destination register.

RRF temp,F(1) will execute operation on temp and place result to temp.
W register wont change in this case. ( If it was shown as 0x17 after
execution it was 0x17 before that ) Applicable to any operation which
places result back to register.

RRF temp,W(0) will execute operation on temp and place result to W.
temp register wont change in that case. Applicable to any operation
which places result to W.

About the rest of your questions
1. Visit piclist.com and search for most of your answers.
2. Visit Olin's http://www.embedinc.com There are some useful stuff about
  macroses as well.


Cheers.

Dmitriy.

2005\08\01@040356 by Alan B. Pearce

face picon face
>Second, I'm wondering just how much use most programmers make of the
>assembler directives. There are a LOT of directives available, yet when
>I look at other folk's source code it seems that only a very few
>directives ever actually show up in the code. The #include, EQU, and a
>few others are very common, as is using $ to refer to the PC. That seems
>about it. For example, I'd expect to see more use of DA, DT, BANKISEL,
>and BANKSEL. Are there non-obvious drawbacks to using the MPASM
>directives?

Possibly because the directives they give are not too much use because they
are not making best use of the directive names (e.g. the skip macros are as
hard to understand as the skip instructions themselves), and the banksel
ones can put in much unneeded code. Dmitriy has already pointed you at Olins
website where he ahs an environment that you can download, which contains
many useful macros which are more user friendly than the Microchip ones -
the skip ones have more easily understood names and the bank selection ones
put in instructions only where they are needed.

Another problem with macros lies in how MPLab steps through them with the
debugger and simulator. This may discourage people from using macros as they
may find it just as easy to code the assembler straight off so they can see
what happens when debugging.

2005\08\01@080146 by olin piclist

face picon face
GM wrote:
> First, refer to the documentation for the RRF and RLF instructions in
> MicroChip's Mid-Range MCU manual.

No, I'm not going to dig that out.  If you want me to see something small,
reproduce it here.

> I have a question about the contents
> of the W register after either of these instructions are executed. The
> examples (pages 29-36 and 29-37) show that the contents of W are not
> defined prior to executing the instruction, but then they show that W
> contains 0x17 after execution. The W reg is not the destination for the
> instruction, which is given as RRF INDF,1.

You should use mnemonics for the destination.  The symbols W and F are
defined in the include file for exactly that purpose.  Since I always use
the mnemonic (or leave it off so that it defaults to F), I don't remember
off the top of my head which one is 1 and which one is 0.

In any case "RRF INDF, F" will have no effect on W.  The result will be
stored in the register indicated by FSR and the indirect bank bit in STATUS,
and it will effect the C bit of course.  Note that on the PIC 18,
instructions with F as the target can effect W since it is mapped to the
register address space as WREG.  However on the PIC 16 W is not mapped to
the RAM address space and an instruction with F destination can not effect
store to it regardless of what may be in FSR.

> Second, I'm wondering just how much use most programmers make of the
> assembler directives.

Not much, since most programmers don't seem to bother reading the manual.

> There are a LOT of directives available, yet when
> I look at other folk's source code it seems that only a very few
> directives ever actually show up in the code.

Keep in mind that the vast majority of code out there is crap and Microchip
examples are no exeception, although they seem to be getting a little better
lately.

> as is using $ to refer to the PC.

Don't do that except in very limited special circumstances.  Never do that
when the target is not an adjacent instruction.  This will also cause
problems when moving code between PIC 16 and PIC 18.  The PIC 16 has 1
address per instruction word, but the PIC 18 has 2.  Therefore GOTO $-2
jumps to the previous instruction on a PIC 18 (unless its a two word
instruction in which case it will jump back to the second word of the two
word instruction, which is a NOP), but goes two instructions back on a PIC
16.  Confused?  Good.  Don't do that.

> For example, I'd expect to see more use of DA, DT, BANKISEL,
> and BANKSEL. Are there non-obvious drawbacks to using the MPASM
> directives?

The MPASM diretives seem to work as documented.  DA and DT would mostly be
used for tables.  BANKISEL and BANKSEL are good for beginners since they are
guaranteed to produce the desired result unconditionally.  For production
code there are cleverer ways to set the bank state, although these have
limitations and require come cooperation from the programmer.


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

2005\08\01@081106 by olin piclist

face picon face
Dmitriy Kiryashov wrote:
> 2. Visit Olin's http://www.embedinc.com There are some useful stuff about
>   macroses as well.

That should be http://www.embedinc.com/pic.  It is very difficult or perhaps
even impossible to get to the PIC stuff from the main page.


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

2005\08\01@083628 by Russell McMahon

face
flavicon
face
> That should be http://www.embedinc.com/pic.  It is very difficult or
> perhaps
> even impossible to get to the PIC stuff from the main page.

Know thyself :-)

   Main Page
       Services
           Our Services
               PIC Resources section  [bottom of page]



                       RM

2005\08\01@110616 by GM

picon face


> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam@spam@mit.edu
> [piclist-bouncesspamKILLspammit.edu] On Behalf Of Olin Lathrop
>
> GM wrote:
> > First, refer to the documentation for the RRF and RLF
> instructions in
> > MicroChip's Mid-Range MCU manual.
>
> No, I'm not going to dig that out.  If you want me to see
> something small, reproduce it here.

Someone got up on the wrong side of the bed this morning. :-)

> > contains 0x17 after execution. The W reg is not the destination for
> > the instruction, which is given as RRF INDF,1.
>
> You should use mnemonics for the destination.  

I do. The #include files supplied with MPASAM define W and F as
mnemonics. I use those when coding. BUT - that is not what is shown in
the example in the manual, which I was reproducing verbatim.

I'm a programmer by trade, therefore I have learned that magic numbers
are to be avoided. It annoys me when my cow-orkers embed numbers and
string literals in the source when they could just as easily have
written code that is easier to read and easier to maintain, using
constants or "mnemonics." You're preaching to the choir, so to speak.

>
> In any case "RRF INDF, F" will have no effect on W.  The
> result will be stored in the register indicated by FSR and
> the indirect bank bit in STATUS, and it will effect the C bit
> of course.

That is what I thought, but being a novice I wasn't certain. Thank you,
and the others who have responded, for confirming my suspicions and also
for the other useful info you have included.

>
> > Second, I'm wondering just how much use most programmers
> make of the
> > assembler directives.
>
> Not much, since most programmers don't seem to bother reading
> the manual.

But I do, even to the point of catching errors in the docs.  

{Quote hidden}

Not confused, makes sense. I'll avoid $.


Regards,
  Glenn Minch

2005\08\01@112051 by John J. McDonough

flavicon
face
----- Original Message -----
From: "GM" <.....the_euphemismKILLspamspam.....yahoo.com>
Subject: RE: [PIC] Misc. ASM questions


>> No, I'm not going to dig that out.  If you want me to see
>> something small, reproduce it here.
>
> Someone got up on the wrong side of the bed this morning. :-)

I actually had a different response.

Olin is often kind of crotchety, but when someone is asking for help, they
really shouldn't expect the helper to jump through all sorts of hoops to
figure out the question.  I appreciated Olin pointing this out.  OK, maybe
Olin doesn't weigh his words quite as carefully as some would like, but
that's just Olin.  Indeed, makes me suspect he's really a Dutch guy living
in the Commonwealth. At least some Dutch folks consider the American
practice of sugar coating everything as almost a little dishonest.

--McD

2005\08\01@141505 by G Minch

picon face


"John J. McDonough" <EraseMEmcdspam_OUTspamTakeThisOuTis-sixsigma.com> wrote:
----- Original Message -----
From: "GM"
Subject: RE: [PIC] Misc. ASM questions


>> No, I'm not going to dig that out. If you want me to see
>> something small, reproduce it here.
>
> Someone got up on the wrong side of the bed this morning. :-)

I actually had a different response.

Olin is often kind of crotchety, but when someone is asking for help, they
really shouldn't expect the helper to jump through all sorts of hoops to
figure out the question.

******************************************************************************************

I understand what he meant, and I respect the general message. That's why I put the smiley in there. And, in the future when I have a short question I will include the code in the message. I like to make it easy for people to give me the info I want. I thought I was making it easier by referencing the manual, but in retrospect I do see Olin's point.

I also went out to the Embed Inc site and looked at the code there. That is the kind of stuff I want to see, although my own needs don't (at present) require that I introduce the same level of sophistication that is evident in the code that Olin is working with. Lots of study ahead.

Regards,

Glenn Minch

2005\08\02@044423 by Alan B. Pearce

face picon face
>I understand what he meant, and I respect the general message.
>That's why I put the smiley in there. And, in the future when
>I have a short question I will include the code in the message.
>I like to make it easy for people to give me the info I want.
>I thought I was making it easier by referencing the manual,
>but in retrospect I do see Olin's point.

I did think you had made a reasonable attempt at putting the code in your
original post, and that Olin had then broken it up somewhat. However good to
see you haven't taken umbrage at it.

>I also went out to the Embed Inc site and looked at the code
>there. That is the kind of stuff I want to see, although my
>own needs don't (at present) require that I introduce the
>same level of sophistication that is evident in the code
>that Olin is working with. Lots of study ahead.

You will find it a lot easier to just leap in the deep end, and use Olins
environment, rather than try and relearn later. That way you will get a
better strategy set up straight away, and work around the niggles in the
lower end PICs without realising it. A lot of Olins macro coding also has to
do with having them work with any family of PICs, from the smallest 10F
series to the dsPic family, without the code writer having to set to and use
different macros for different chip families. Just use the macros you need
to get under way, and sort the rest out later. Do not forget to download the
PDF document that Jan-Erik has produced from Olins documentation, as it is
in a nicer format to use as a reference. The link to it is on Olins pages.

2005\08\02@061638 by Jan-Erik Soderholm

face picon face
Alan B. Pearce wrote :

> Do not forget to download the
> PDF document
that Jan-Erik has produced from Olins
> documentation, as it is in a
nicer format to use as
> a reference.

Just note that it's based on a
slightly older
version of Olins environment. I think that
his current
envir has PIC10 and dsPIC support, not ?

An update have been in my
plans for
some time, but not my "summer-plans"... :-)

> The link to it
is on Olins pages.

Or here :

http://www.jescab.se/embedinc.htm

Olin
*might* link to my old web site...

Regards,

Jan-Erik.



2005\08\02@075548 by olin piclist

face picon face
> I think that
> his current
> envir has PIC10 and dsPIC support, not ?

Yes it does.

> Or here :
>
> http://www.jescab.se/embedinc.htm
>
> Olin
> *might* link to my old web site...

I did, but I just fixed it.

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

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