Searching \ for '[PIC]: Ring buffer acting oddly' 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: 'Ring buffer acting oddly'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Ring buffer acting oddly'
2003\03\11@021159 by Neil Bradley

flavicon
face
I'm attempting to implement a 256 character ring buffer in my 18F series
CPU. Under simulation and under hardware debug, the routine that deposits
the messages in the ring buffer (at INT1) places the incoming data bytes
in the right place, and the routine that extracts the message from the
ring buffer pulls out the correct data.

However, during runtime in my hardware target, I get nothing but 0s, and I
fear that I'm missing some critical piece of information:

RECEIVE_RING_BUFFER below equals 0x100. RXBufTail and RXBufHead are 0x0e
and 0x0d respectively. This is an 18F252:

This is my "remove from queue" code snippet:

       lfsr    FSR0, RECEIVE_RING_BUFFER       ; Point to our receive ring buffer
       bcf     INTCON, 7               ; Disable all unmaksed interrupts while we adjust the head/tail pointers
       movff   RXBufTail, FSR0L ; Point to our receive buffer tail
       movf    INDF0, W                ; Get the received byte in W
       incf    RXBufTail               ; Increment the tail pointer
       bsf     INTCON, 7               ; Reenable masked interrupts!

And this is the "Deposit in queue" code snippet:

       lfsr    FSR2, RECEIVE_RING_BUFFER       ; Point to our receive ring buffer
       movff   RXBufHead, FSR2L ; Point to our receive buffer head
       movff   RXByte, INDF2
       incf    RXBufHead               ; Increment the head pointer

FSR2 Is not used anywhere but inside INT1. FSR0 Is used in foreground code
exclusively.

The foreground code always seems to stay in sync with the number of bytes
received, it's just the data that's read is nothing but zeros. I suspect
it's a screwup in how I've defined the movff/movf instructions dealing
with INDF2/INDF0 but repeated trips to the datasheet don't yield anything
obvious. Am I just doing something stupid? Any help would be greatly
appreciated!

-->Neil

-------------------------------------------------------------------------------
Neil Bradley            In the land of the blind, the one eyed man is not
Synthcom Systems, Inc.  king - he's a prisoner.
ICQ #29402898

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

2003\03\11@044602 by Neil Bradley

flavicon
face
>         movff   RXBufTail, FSR0L ; Point to our receive buffer tail
>         movf    INDF0, W                ; Get the received byte in W

Aha:
         movff   INDF0, W

Much better. ;-)

-->Neil

-------------------------------------------------------------------------------
Neil Bradley            In the land of the blind, the one eyed man is not
Synthcom Systems, Inc.  king - he's a prisoner.
ICQ #29402898

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

2003\03\11@054419 by hael Rigby-Jones

picon face
> -----Original Message-----
> From: Neil Bradley [SMTP:nbspamKILLspamSYNTHCOM.COM]
> Sent: Tuesday, March 11, 2003 9:44 AM
> To:   .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
> Subject:      Re: [PIC]: Ring buffer acting oddly
>
> >         movff   RXBufTail, FSR0L ; Point to our receive buffer tail
> >         movf    INDF0, W                ; Get the received byte in W
>
> Aha:
>           movff   INDF0, W
>
> Much better. ;-)
>
> -->Neil
>
I don't quite understand this, but then again I'm not exactly an expert in
18F assembly.  You want to copy the value of INDF0 to W, so I would have
though movf INDF0,W was exactly the right instrcution to use?  movff is for
copying one file to another, and in this case you have specified a
destination of W which would move the contents of INDF0 to the first
location in the selected memory bank.  Am I way off course here?

Regards

Mike



=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to EraseMEpostmasterspam_OUTspamTakeThisOuTbookham.com.

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

2003\03\11@074036 by

flavicon
face
  movff   INDF0, WREG

would also work...

Jan-Erik.

Michael Rigby-Jones wrote:

>>           movff   INDF0, W
>>
> I don't quite understand this, but then again I'm not exactly an expert in
> 18F assembly.  You want to copy the value of INDF0 to W, so I would have
> though movf INDF0,W was exactly the right instrcution to use?

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

2003\03\11@074902 by Olin Lathrop
face picon face
> I'm attempting to implement a 256 character ring buffer in my 18F series
> CPU. Under simulation and under hardware debug, the routine that
> deposits
> the messages in the ring buffer (at INT1) places the incoming data bytes
> in the right place, and the routine that extracts the message from the
> ring buffer pulls out the correct data.
>
> However, during runtime in my hardware target, I get nothing but 0s,
> and I
> fear that I'm missing some critical piece of information:

If you just want a working solution, you can use my FIFO_xxx 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#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\03\11@075802 by Olin Lathrop

face picon face
>>         movff   RXBufTail, FSR0L ; Point to our receive buffer tail
>>         movf    INDF0, W                ; Get the received byte in W
>
> Aha:
>           movff   INDF0, W
>
> Much better. ;-)

Almost certainly not!

Remember that W does not represent the address of the W register.  That's
what WREG is.  However, using MOVFF to to copy the value in INDF0 into W
is a waste.  The MOVF INDF0, W instruction looks correct given the
comment.


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

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

2003\03\11@093039 by Scott Dattalo

face
flavicon
face
On Mon, 10 Mar 2003, Neil Bradley wrote:

> I'm attempting to implement a 256 character ring buffer in my 18F series
> CPU. Under simulation and under hardware debug, the routine that deposits
> the messages in the ring buffer (at INT1) places the incoming data bytes
> in the right place, and the routine that extracts the message from the
> ring buffer pulls out the correct data.
>
> However, during runtime in my hardware target, I get nothing but 0s, and I
> fear that I'm missing some critical piece of information:
>
> RECEIVE_RING_BUFFER below equals 0x100. RXBufTail and RXBufHead are 0x0e
> and 0x0d respectively. This is an 18F252:
>
> This is my "remove from queue" code snippet:

<snip>


Neil,

I have a similar but different technique. Like you I dedicate FSR2L:H to
the interrupt routine and use FSR0L:H and FSR1L:H for the not interrupt
code. I use two indices to access the buffer: one for the interrupt code
and one for the non-interrupt code.

In the interrupt routine I have this:

       LFSR    2,RxBuffer              ;   *** Rx Interrupt ***
       INCF    RxIndexInt,W            ;
       ANDLW   RX_INDEX_MASK           ; We just received a byte in the
       MOVWF   RxIndexInt              ;UART. This byte gets stored in
       MOVFF   RCREG,PLUSW2            ;  RxBuffer[RxIndexInt] = RCREG

While, in the non-interrupt routine I have something like this:

       MOVF    RxIndexInt,W            ;Did we receive a byte? If the Rx
                                       ; Indices
       XORWF   RxIndex,W               ;for the interrupt and
                                       ; non-interrupt code
       BNZ     rpob1                   ;are different then we have a
                                       ;byte.
       RETURN                          ;Otherwise we don't...
                                       ;
rpob1:                                  ;
       INCF    RxIndex,W               ;Advance the non-interrupt index
       ANDLW   RX_INDEX_MASK           ;using roll-over arithmetic
       MOVWF   RxIndex                 ;and get the byte that the
       LFSR    0,RxBuffer              ;interrupt routine placed into


I don't bother disabling interrupts while the indices are being adjusted
since that's not needed. In other words, the two pieces of code only
modify the indices that they "own".

This code does make the assumption that fewer than one buffer's size of
bytes will be received between two successive calls to the code that
processes the buffer. In other words, I don't check for buffer overflow.

In your case, the buffer indices are 8-bits. Thus, you can ommit the ANDLW
instruction.

I use a similar technique to record pulse widths in one application. The
interrupt routine measures the pulse width, the non-interrupt routine does
stuff with it. In this case, I don't want the buffer to roll-over. So I do
this (and this is purely debug code [that I know works]):

       BTFSC   TC_PulseIndexInt,6
        bra    check_next_interrupt
       MOVF    TC_PulseIndexInt,W
       ANDLW   0x03f
       INCF    TC_PulseIndexInt,F

       LFSR    2,PulseBuffer
       MOVFF   TC_PulseLo,PLUSW2

In this case, a 5-bit counter is used for the index. If bit 6 gets set
then the buffer is full.


Scott

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

2003\03\11@132724 by Neil Bradley

flavicon
face
> >>           movff   INDF0, W
> > I don't quite understand this, but then again I'm not exactly an expert in
> > 18F assembly.  You want to copy the value of INDF0 to W, so I would have
> > though movf INDF0,W was exactly the right instrcution to use?

I don't see how it can, since the "movf" instruction only allows for an 8
bit file register address, and INDF0 is in 12 bit address space, which
begs the question on why MPLAB doesn't flag this as an error when
assembling.

-->Neil

-------------------------------------------------------------------------------
Neil Bradley            In the land of the blind, the one eyed man is not
Synthcom Systems, Inc.  king - he's a prisoner.
ICQ #29402898

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

2003\03\11@133453 by Ned Konz

flavicon
face
On Tuesday 11 March 2003 10:25 am, Neil Bradley wrote:
> > >>           movff   INDF0, W
> > >
> > > I don't quite understand this, but then again I'm not exactly
> > > an expert in 18F assembly.  You want to copy the value of INDF0
> > > to W, so I would have though movf INDF0,W was exactly the right
> > > instrcution to use?
>
> I don't see how it can, since the "movf" instruction only allows
> for an 8 bit file register address, and INDF0 is in 12 bit address
> space, which begs the question on why MPLAB doesn't flag this as an
> error when assembling.

Why not
       movf INDF0,W,A

so you don't have to worry about banks?
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

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

2003\03\11@135323 by

flavicon
face
Hm, I'v used the 18F252 without the ",A" part, and got a
"0" as the a-bit in the MOVF instruction ("access bank").

Now, after checking with the manual a second time, it
actualy says that "1" as the a-bit is defualt.

It looks as the manual and MPASM have different definitions
for the default for the a-bit.

(Yes. I know, better to code it myself, and not use the default,
whatver *that* might be...)

Jan-Erik Söderholm.



Ned Konz wrote:
>Why not
>        movf INDF0,W,A
>
>so you don't have to worry about banks?

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

2003\03\11@141854 by

flavicon
face
*Every* RAM location (GPR's and FRS's) are in the
12-bit address space. Some instructions includes
all 12 bits, some just the lower 8.

The MOVFF has two 12 bit address fields (source and target)
and is coded as two 16-bit program "words" and addresses
the full RAM area without any "banking" logic.

The MOVF has one 8 bit "source" field that is
used with the normal "banking" logic. And if the
"a" bit in the instruction is "0", the "Access bank"
is accessed.

Using any FSR as source is valid in both cases, but in the
MOVF case, it might not access what was intended depending
on your setting of the banking bits (and the "a" bit).

Jan-Erik Söderholm.



Neil Bradley wrote:

>> >>           movff   INDF0, W
>> > I don't quite understand this, but then again I'm not exactly an expert in
>> > 18F assembly.  You want to copy the value of INDF0 to W, so I would have
>> > though movf INDF0,W was exactly the right instrcution to use?
>
>I don't see how it can, since the "movf" instruction only allows for an 8
>bit file register address, and INDF0 is in 12 bit address space, which
>begs the question on why MPLAB doesn't flag this as an error when
>assembling.

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

2003\03\11@150215 by Olin Lathrop

face picon face
> I don't see how it can, since the "movf" instruction only allows for an
> 8
> bit file register address, and INDF0 is in 12 bit address space, which
> begs the question on why MPLAB doesn't flag this as an error when
> assembling.

See manual.  Open manual.  Read about RAM addressing, banking, and the use
of BSR.


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

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

2003\03\11@150408 by Olin Lathrop

face picon face
> Why not
>         movf INDF0,W,A
>
> so you don't have to worry about banks?

Because, as has already been pointed out twice in this thread, that will
copy whatever byte FSR0 is pointing to into the RAM location 0.  This is
probably not the intended result.


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

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

2003\03\11@153339 by Neil Bradley

flavicon
face
> > bit file register address, and INDF0 is in 12 bit address space, which
> > begs the question on why MPLAB doesn't flag this as an error when
> > assembling.
> See manual.  Open manual.  Read about RAM addressing, banking, and the use
> of BSR.

Already know about that. INDF0 Equates to a 12 bit quantity. Using movf
chops off 4 of the 12 bits in all cases. Say what you want about this, it
does not make sense to take an obvious constant that will not fit in the
instruction it's used in and accept it without warnings or errors.
Requiring the user to do something like this:

       movf    (INDF0 & 0xff), W

Should be acceptable, but silent truncation is NEVER a good idea - in any
language.

-->Neil

-------------------------------------------------------------------------------
Neil Bradley            In the land of the blind, the one eyed man is not
Synthcom Systems, Inc.  king - he's a prisoner.
ICQ #29402898

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

2003\03\11@163009 by Olin Lathrop

face picon face
> Already know about that. INDF0 Equates to a 12 bit quantity. Using movf
> chops off 4 of the 12 bits in all cases. Say what you want about this,
> it
> does not make sense to take an obvious constant that will not fit in the
> instruction it's used in and accept it without warnings or errors.
> Requiring the user to do something like this:
>
>         movf    (INDF0 & 0xff), W
>
> Should be acceptable, but silent truncation is NEVER a good idea - in
> any language.

Then you'd have cumbersome and ugly syntax on almost every file register
reference.  Yuk.  Since you'd have to AND the address with FFh most of the
time, it might as well be understood that it will always be done
automatically.


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

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

2003\03\11@202233 by Dwayne Reid

flavicon
face
At 04:28 PM 3/11/03 -0500, Olin Lathrop wrote:
> > Already know about that. INDF0 Equates to a 12 bit quantity. Using movf
> > chops off 4 of the 12 bits in all cases. Say what you want about this,
> > it
> > does not make sense to take an obvious constant that will not fit in the
> > instruction it's used in and accept it without warnings or errors.
> > Requiring the user to do something like this:
> >
> >         movf    (INDF0 & 0xff), W
> >
> > Should be acceptable, but silent truncation is NEVER a good idea - in
> > any language.
>
>Then you'd have cumbersome and ugly syntax on almost every file register
>reference.  Yuk.  Since you'd have to AND the address with FFh most of the
>time, it might as well be understood that it will always be done
>automatically.

How many registers are larger than 8 bits?

I haven't done any projects with the 18F family (yet) but at first glance,
the situation seems similar to dealing with the bank bits in the 14 bit
family.  The warning message that comes up if I get an address wrong lets
me fix stupid mistakes right away and has saved many hours of debugging time.

Silently truncating values does seem a bit scary.

dwayne

--
Dwayne Reid   <RemoveMEdwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 19 years of Engineering Innovation (1984 - 2003)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

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

2003\03\11@220726 by Andrew Warren

flavicon
face
Dwayne Reid <spamBeGonePICLISTSTOPspamspamEraseMEmitvma.mit.edu> wrote:

> > >         movf    (INDF0 & 0xff), W
> > >
> > > Should be acceptable, but silent truncation is NEVER a good idea -
> > > in any language.
> >
> >Then you'd have cumbersome and ugly syntax on almost every file
> >register reference.  Yuk.  Since you'd have to AND the address with
> >FFh most of the time, it might as well be understood that it will
> >always be done automatically.
>
> the situation seems similar to dealing with the bank bits in the 14
> bit family.  The warning message that comes up if I get an address
> wrong lets me fix stupid mistakes right away and has saved many
> hours of debugging time.
>
> Silently truncating values does seem a bit scary.

Dwayne:

Back when I wrote PIC code -- it seems like AGES ago -- my solution
was to use macros like these (for the 14-bit PICs):

   MOVWF1  MACRO REG
           MOVWF  (REG ^ 0X80)
           ENDM

This removed the cumbersome and ugly syntax from my code and allowed
me to define bank-1 registers with their complete addresses so my
emulator watch windows would work properly.

It's easy to look at register accesses between "BSF STATUS,PA0" and
"BCF STATUS,PA0" instructions to make sure that they're all MOVWF1s
rather than MOVWFs, and check that MOVWF rather than MOVWF1 is used
outside of those bank-switch instruction pairs... Or, if you're too
lazy to do that, and you're not doing anything particularly tricky in
your code, you can add assemble-time flags to your bank-switch
macros, then check those flags in the MOVWF1 macro.

Note that I use XOR in my macro, rather than AND.  This was
deliberate; the XOR in the macro preserves the assembler's ability to
catch mistakes that would be missed if it were an AND:  If you
accidentally misapply the macro to a register that ISN'T in bank one,
the assembler produces a warning.

-Andy

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

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

2003\03\11@231328 by Neil Bradley

flavicon
face
> > > Should be acceptable, but silent truncation is NEVER a good idea - in
> > > any language.
> >Then you'd have cumbersome and ugly syntax on almost every file register
> >reference.  Yuk.  Since you'd have to AND the address with FFh most of the
> >time, it might as well be understood that it will always be done
> >automatically.
> How many registers are larger than 8 bits?

All of the SFRs. ;-) The registers themselves are 8 bits, but the
register's *ADDRESSES* are >8 bits.

-->Neil

-------------------------------------------------------------------------------
Neil Bradley            In the land of the blind, the one eyed man is not
Synthcom Systems, Inc.  king - he's a prisoner.
ICQ #29402898

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

2003\03\12@042751 by Alan B. Pearce

face picon face
>Now, after checking with the manual a second time, it
>actualy says that "1" as the a-bit is defualt.
>
>It looks as the manual and MPASM have different definitions
>for the default for the a-bit.
>
>(Yes. I know, better to code it myself, and not use the default,
>whatver *that* might be...)

Exactly, then you know what the result should always be instead of some
clown changing defaults in the next release for you and suddenly breaking
all your code :)))))

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu>

2003\03\12@090016 by Olin Lathrop

face picon face
> How many registers are larger than 8 bits?

None of them.  This is after all and 8 bit processor.

> I haven't done any projects with the 18F family (yet) but at first
> glance, the situation seems similar to dealing with the bank bits in
> the 14 bit family.  The warning message that comes up if I get an
> address wrong lets
> me fix stupid mistakes right away and has saved many hours of debugging
> time.

Wow, we finally found the one guy who hasn't shut off that annoying
warning!

> Silently truncating values does seem a bit scary.

Boo.


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

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspam_OUTspammitvma.mit.edu>

2003\03\12@122636 by Bob Barr

flavicon
face
On Wed, 12 Mar 2003 08:58:23 -0500, Olin Lathrop wrote:

<snip>
>
>> I haven't done any projects with the 18F family (yet) but at first
>> glance, the situation seems similar to dealing with the bank bits in
>> the 14 bit family.  The warning message that comes up if I get an
>> address wrong lets
>> me fix stupid mistakes right away and has saved many hours of debugging
>> time.
>
>Wow, we finally found the one guy who hasn't shut off that annoying
>warning!
>

Actually, that makes two of us. :=)

It takes me just a moment to put a "bnk1^" in front of any bank 1
register name and I can leave the 302 warning active.

The only times that I ever disable the 302 warning is when a higher
banked register doesn't have a valid bank 0 counterpart.


Regards, Bob

P.S. Your "How many Piclisters does it take..." post was great. Thanks
for posting it.

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu>

2003\03\12@143038 by Dwayne Reid

flavicon
face
At 07:06 PM 3/11/03 -0800, Andrew Warren wrote:

>Back when I wrote PIC code -- it seems like AGES ago -- my solution
>was to use macros like these (for the 14-bit PICs):
>
>     MOVWF1  MACRO REG
>             MOVWF  (REG ^ 0X80)
>             ENDM

Yeah, Andy, I've been using exactly those techniques since you put me on to
them.  Thanks again for the idea - it works well and helps me not make
certain bone-headed mistakes.  I have similar macros for the 12 bit parts
as well.

The point that Neil was making is that MPASM is not emitting a warning
message when using an instruction with 8 bit address limit to write a 12
bit wide address.  As he points out, the upper 8 bits get silently
truncated.  That sounds like another potential time waster for the unwary.

dwayne

--
Dwayne Reid   <TakeThisOuTdwaynerKILLspamspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 19 years of Engineering Innovation (1984 - 2003)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspamRemoveMEmitvma.mit.edu>

2003\03\12@143046 by Dwayne Reid

flavicon
face
At 08:58 AM 3/12/03 -0500, Olin Lathrop wrote:

> > I haven't done any projects with the 18F family (yet) but at first
> > glance, the situation seems similar to dealing with the bank bits in
> > the 14 bit family.  The warning message that comes up if I get an
> > address wrong lets
> > me fix stupid mistakes right away and has saved many hours of debugging
> > time.
>
>Wow, we finally found the one guy who hasn't shut off that annoying
>warning!

No - I suspect there are many of us out there.  But I've been using a
variant of Andy Warren's technique for years now and the only time I get
that error message is when I forget to invoke the macro that inverts the
high order address bit.  That is a mistake on my part and the error message
lets me go fix it quickly and easily.

My .ERR file is usually 0 bytes when I am finished with a piece of code -
all warnings are tracked down and fixed.  After all, that is what they are
there for - to flag a potential error.

> > Silently truncating values does seem a bit scary.
>
>Boo.

Perhaps! <grin>

The nice thing about all these discussions is that all the hard work is
done for me when I finally get around to these neat new parts.  I get to
learn from the pioneers and the gurus.

dwayne

--
Dwayne Reid   <RemoveMEdwaynerspamspamBeGoneplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 19 years of Engineering Innovation (1984 - 2003)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu>

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