Searching \ for 'trisa warnings' 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/index.htm?key=trisa+warnings
Search entire site for: 'trisa warnings'.

Truncated match.
PICList Thread
'trisa warnings'
1995\10\17@145848 by Mike Schreck

flavicon
face
All,

       This question was posted some time ago, but I cant find it in the
archives (sorry). I'm moving W into TRISA, and getting the truncation
warning. I understand that TRISA (on 16c71) is 5 bits wide. Is there
some way to assign all the bits in 1 shot and not get the warning? I just
don't want to get into the habbit of having code that produces warning
messages (because i'll get in the habbit of ignoring them).

Michael J. Schreck

1995\10\17@201813 by John Payson

flavicon
face
>         This question was posted some time ago, but I cant find it in the
> archives (sorry). I'm moving W into TRISA, and getting the truncation
> warning. I understand that TRISA (on 16c71) is 5 bits wide. Is there
> some way to assign all the bits in 1 shot and not get the warning? I just
> don't want to get into the habbit of having code that produces warning
> messages (because i'll get in the habbit of ignoring them).

Perhaps the complaint is that the TRISA address is in the second page, and
can thus not be specified directly.  I've not used that assembler, but it
may be trying to warn you that your store to TRISA is instead going to PORTA
(the ADDRESS is being truncated, not the data).  I'd suggest being very care-
ful with TRIS code because setting the wrong bank can really mess things up.

1995\10\17@225532 by Andrew Warren

face
flavicon
face
Mike Schreck <spam_OUTschreckTakeThisOuTspamHORIZSYS.COM> wrote:

>I'm moving W into TRISA, and getting the truncation warning. I
>understand that TRISA (on 16c71) is 5 bits wide. Is there some way to
>assign all the bits in 1 shot and not get the warning? I just don't
>want to get into the habbit of having code that produces warning
>messages (because i'll get in the habbit of ignoring them).

Mike:

The warning has nothing to do with the width of TRISA; it happens
because you're trying to directly access a register on page 1.  To
avoid this, change your code from:

   MOVWF   TRISA

to:

   MOVWF   TRISA^080H

(This assumes that TRISA is equated to 081H.)

Also, be sure that you switch to register page 1 before the MOVWF, and
back to register page 0 afterward.

-Andy

--
Andrew Warren - .....fastfwdKILLspamspam@spam@ix.netcom.com
Fast Forward Engineering, Vista, California

1995\10\18@113956 by Jeff D. Pipkins

flavicon
face
From:    Andrew Warren <fastfwdspamKILLspamIX.NETCOM.COM>

| The warning has nothing to do with the width of TRISA; it happens
| because you're trying to directly access a register on page 1.  To
| avoid this, change your code from:
|
|     MOVWF   TRISA
|
| to:
|
|     MOVWF   TRISA^080H
|
| (This assumes that TRISA is equated to [085H].)

EEK!  It certainly does!  I'd much prefer writing "TRISA & 0x7F"
instead.  This clears the problem bit, instead of assuming it's
set to 1 and flipping it.  I realize that the end result is the
same, but Mike's goal was to develop _good_habits_ for writing
better code.

BTW, I briefly toyed with the idea of equating TRISA to 5 instead
of 85, but decided against it.  If TRISA is equated to 85, then
you can ask the simulator to show you TRISA, and you'll get the
correct register.  Otherwise, you'll get PORTA when you ask for
TRISA.

| Also, be sure that you switch to register page 1 before the MOVWF,
| and back to register page 0 afterward.

Ain't THAT the truth!  I might also add that if you have an
interrupt service routine, don't forget that when your isr
executes you might not be in page 0.

--Jeff
(Not teaching anymore, but not altogether successful in kicking the soapbox
habit, either...)

Jeff Pipkins <.....PipkinsKILLspamspam.....bangate.compaq.com>  -------------------
Lead, Communications VP, Quartet Activities Chairman,
Lone Star Statesmen Barbershop Chorus
Opinions above are mine personally; use only at your own risk.

1995\10\20@001131 by Andrew Warren

face
flavicon
face
Jeff D. Pipkins <EraseMEpipkinsspam_OUTspamTakeThisOuTBANGATE.COMPAQ.COM> wrote:

>I'd much prefer writing "TRISA & 0x7F" instead [of TRISA ^ 0x80].
>This clears the problem bit, instead of assuming it's set to 1 and
>flipping it.  I realize that the end result is the same, but Mike's
>goal was to develop _good_habits_ for writing better code.
> ....
>(Not teaching anymore, but not altogether successful in kicking the
>soapbox habit, either...)

Jeff:

Perhaps you should try harder; XORing the hi-bit is a MUCH better way.

Here's why:

If you mistakenly apply my XOR to a register on page 0 (very easy to do
on the larger PICs, whose registers are scattered over both pages), the
assembler will warn you of the error, since the XOR sets the high bit
instead of clearing it.  This warning is important, because your code
will also have switched the RP0 bit to page 1.

Using your method, there's no way for the assembler to tell you that
you've made this mistake.

-Andy


--
Andrew Warren - fastfwdspamspam_OUTix.netcom.com
Fast Forward Engineering, Vista, California

1995\10\20@014454 by dave madden

flavicon
face
Jeff D. Pipkins <@spam@pipkinsKILLspamspamBANGATE.COMPAQ.COM> wrote:

=>>I'd much prefer writing "TRISA & 0x7F" instead [of TRISA ^ 0x80].
=>>This clears the problem bit, instead of assuming it's set to 1 and
=>>flipping it.  I realize that the end result is the same, but Mike's
=>>goal was to develop _good_habits_ for writing better code.
=>> ....
=>>(Not teaching anymore, but not altogether successful in kicking the
=>>soapbox habit, either...)

to which Andrew Warren <KILLspamfastfwdKILLspamspamIX.NETCOM.COM> replied:

=>Perhaps you should try harder; XORing the hi-bit is a MUCH better way.
=>
=>Here's why:
=>
=>If you mistakenly apply my XOR to a register on page 0 (very easy to do
=>on the larger PICs, whose registers are scattered over both pages), the
=>assembler will warn you of the error, since the XOR sets the high bit
=>instead of clearing it.  This warning is important, because your code
=>will also have switched the RP0 bit to page 1.

Sorry for quoting so much, but I'd hate to ruffle feathers by
misattributing text.  Andy, I cannot claim to be the PIC guru that
others on this forum style themselves to be, but as I understand it,
Jeff is correct.

Here's why:

The whole point of XORing the high bit, or otherwise masking it out,
is to avoid spurious assembler warnings.  Those warnings tell you
*nothing* except that you've provided an operand that will be
truncated in the instruction.  Warning or no, the code will operate as
intended iff you've set the RP bits correctly.  The assembler can't
check that for you, and the warning is of no use.  If you put the
top-bit-clearing magic in a macro, then Jeff's method is clearly the
better way -- if you used XOR, then you would have to use the macro
for some cases and not for others, or write another macro for Page 0
registers.  If you write XOR out in each instruction that needs it,
you've still only succeeded in keeping the assembler happy, at the
cost of cluttering your source code.  The important point is that
*none* of this has any bearing on whether the code is correct!

As you note in your final sentence:

=>Using your method, there's no way for the assembler to tell you that
=>you've made this mistake.

There's no way for the assembler to tell you that you've made a
mistake in the first place, so the method I'd choose is the one that
eliminates spurious warnings and leaves the code readable.

d.

1995\10\20@040041 by Andrew Warren

face
flavicon
face
   In order to avoid "truncation" warnings from MPASM, I suggested
   that instructions like MOVWF TRISA be replaced by
   MOVWF TRISA ^ 0x80 ('^' is the exclusive-OR operator).

   Jeff D. Pipkins <RemoveMEpipkinsTakeThisOuTspamBANGATE.COMPAQ.COM> then suggested that
   MOVWF TRISA & 0x7F was preferable.

   I replied, explaining that XORing the register had a useful
   side-effect:  Any accidental application of the XOR to a page-0
   register would generate a warning.

   Dave Madden <spamBeGonedhmspamBeGonespamVHEISSU.III.NET> must not have understood, because
   he wrote:

>[As] I understand it, Jeff is correct.
>
>Here's why:
>
>The whole point of XORing the high bit, or otherwise masking it out,
>is to avoid spurious assembler warnings.  Those warnings tell you
>*nothing* except that you've provided an operand that will be
>truncated in the instruction.  Warning or no, the code will operate as
>intended iff you've set the RP bits correctly.

   Right so far, Dave.

{Quote hidden}

   Here's where you start to miss the point.

   Because, as you say, the RP bits must be set correctly for accesses
   to page-1 registers, you ALREAADY write different code for page-0
   and page-1 registers:  Page-0 accesses aren't bracketed by BSF RP0
   and BCF RP0 instructions, while page-1 accesses are.

   Let's say that you've written a macro for page-1 register-accesses.
   If you use my method, a MOVWF macro will look like this:

       MOVWF1  MACRO   REG
               MOVWF   REG^080H
               ENDM

   Now let's say you want to set all the PORTA pins to output low.
   You'd do the following:

       PORTA   EQU     5
       TRISA   EQU     85
       #DEFINE RP0     STATUS,5

               MOVLW   0
               MOVWF   PORTA
               BSF     RP0
               MOVWF1  TRISA
               BCF     RP0

   In this case, everything'll work fine.

   Now, let's assume that you forget that PORTA is on page 0 and
   accidentally make this mistake:

               BSF     RP0
               MOVWF1  PORTA
               BCF     RP0

   What happens?

   The XOR in the macro SETS the high-bit of PORTA's address, sees
   that this value is too large to fit in the instruction, and
   generates a "Truncation" warning.

   Good thing, too, because (again, as you said) the code generated
   by a MOVWF 0x85 is exactly the same as that for a MOVWF 0x05.
   Because the RP0 bit is set, though, this "exactly the same" MOVWF
   would have written to the wrong page.

   If you'd shortsightedly used the "AND 0x7F" instead of my
   "XOR 0x80", the assembler would have generated no warnings when
   you mistakenly tried to write to a page-0 register after setting
   the RP0 flag.

   Now do you get it, Dave?

   -Andy

--
Andrew Warren - TakeThisOuTfastfwdEraseMEspamspam_OUTix.netcom.com
Fast Forward Engineering, Vista, California

1995\10\20@125544 by dave madden

flavicon
face
Andy Warren summarizes this thread as follows:

=>    In order to avoid "truncation" warnings from MPASM, I suggested
=>    that instructions like MOVWF TRISA be replaced by
=>    MOVWF TRISA ^ 0x80 ('^' is the exclusive-OR operator).
=>
=>    Jeff D. Pipkins <RemoveMEpipkinsspamTakeThisOuTBANGATE.COMPAQ.COM> then suggested that
=>    MOVWF TRISA & 0x7F was preferable.
=>
=>    I replied, explaining that XORing the register had a useful
=>    side-effect:  Any accidental application of the XOR to a page-0
=>    register would generate a warning.
=>
=>    Dave Madden <dhmEraseMEspam.....VHEISSU.III.NET> must not have understood, because
=>    he wrote:
=>
=> [Jeff's method is better because it's simpler]

Andy goes on to explain his MOVWF1 (MOVe W to a File register on page
1) macro in great detail, including an example showing how you get a
warning if you accidentally use MOVWF1 to set a register that's
actually on page 0.  However, I contend that all the macro *really*
does is force the programmer to prove to the assembler that he knows
what page a register is on every time he uses one -- it doesn't
(indeed, can't) determine if you're actually going to get the register
you're asking for.

So for this trivial bit of sanity checking you pay a correspondingly
trivial price: you have two opcodes that evaluate to the same object
code (MOVFW PORTA === MOVFW1 TRISA).  I prefer a solution that allows
me to use the same opcode in all cases (thus conserving my limited
capacity to understand for the important task of making sure the page
bits are set right), while Andy obviously prefers to prove that he
knows what he's doing at all turns.

Fair enough; perhaps we can move on to more interesting topics, like
what to do about magazine advertisements, right after Andy gets the
last word.

d.

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