Searching \ for '[PIC]: CLRW give compile error' 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: 'CLRW give compile error'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: CLRW give compile error'
2004\01\16@003307 by WH Tan

flavicon
face
Dear all,

When I was compiling the PICDEM 2+ sample code for PIC18F452, I get the
following error message.
It look like MPLAB 6.40 is unable to regonize CLRW as a mnemonic.

Warning[207] D:\PROJECTS\PIC+\DEMO18\P18MATH.ASM 101 : Found label after
column 1. (CLRW)
Warning[207] D:\PROJECTS\PIC+\DEMO18\P18MATH.ASM 111 : Found label after
column 1. (CLRW)
Error[116]   D:\PROJECTS\PIC+\DEMO18\P18MATH.ASM 111 : Address label
duplicated or different in second pass (CLRW)

Have anyone having the same compile problem in MPLAB v6.40?

Thanks & regards.

WH Tan

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

2004\01\16@004552 by Ken Pergola

flavicon
face
WH Tan wrote:

> When I was compiling the PICDEM 2+ sample code for PIC18F452, I get the
> following error message.
> It look like MPLAB 6.40 is unable to regonize CLRW as a mnemonic.
>
> Warning[207] D:\PROJECTS\PIC+\DEMO18\P18MATH.ASM 101 : Found label after
> column 1. (CLRW)


Hi WH Tan,

I would just replace the 'CLRW' mnemonic with 'ANDLW 0x00'.
Using 'ANDLW 0x00' should make the source code architecture-independent.
Just don't forget to include a comment because 'ANDLW 0x00' isn't as
readable as 'CLRW':

ANDLW 0x00      ; Clear W register


Best regards,

Ken Pergola

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

2004\01\16@005358 by Ken Pergola

flavicon
face
Sorry I was not clear enough:

CLRW is a 14-bit core architecture-specific instruction mnemonic.
It is not a legal PIC18 architecture instruction mnemonic.
See previous post for a solution.

Best regards,

Ken Pergola

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

2004\01\16@013946 by Jinx

face picon face
> CLRW is a 14-bit core architecture-specific instruction mnemonic.
> It is not a legal PIC18 architecture instruction mnemonic.

CLRW compiles with MPLAB 6.20 to CLRF WREG,0

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

2004\01\16@014152 by WH Tan

flavicon
face
Hi Ken,

Thanks a lot for your reply.

>CLRW is a 14-bit core architecture-specific instruction mnemonic.
>It is not a legal PIC18 architecture instruction mnemonic.

Ain't the 14-bit core is a subset of 16-bit?

Regards,
WH Tan

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

2004\01\16@020436 by Jinx

face picon face
> >CLRW is a 14-bit core architecture-specific instruction mnemonic.
> >It is not a legal PIC18 architecture instruction mnemonic.

Sorry, my last reply went out prematurely, thought I was off-line

CLRW compiles with MPLAB 6.20 to CLRF WREG,0

This is in an 18F452 program. My settings for MPLAB text are
such that reserved words are blue, labels, macros etc are purple.
CLRW is purple. If you look in the 452 .inc you'll see this

 #define clrw clrf WREG       ; PIC16Cxxx code substitution (WREG is
addressable)

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

2004\01\16@021305 by Ken Pergola

flavicon
face
WH Tan wrote:

> Ain't the 14-bit core is a subset of 16-bit?

Hi WH Tan,

If you mean: Is the PIC18 instruction set 100% backward-compatible with the
14-bit core?, then the answer is no.
The easiest way to see the differences is to compare the two instruction
sets side-by-side -- and keep an eye especially on the status bits affected
between the same instructions of the two different core architectures.

Related to your specific question of your original post, you'll quickly see
that CLRW is not part of the PIC18 instruction set.

Regards,

Ken Pergola

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2004\01\16@022338 by WH Tan

flavicon
face
Hi Ken & Jinx,

Thank you very much for explaination. I am clear now.

WH Tan

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

2004\01\16@031902 by Hopkins

flavicon
face
How do you setup MPLAB to show different colours?
*************************************************

Roy Hopkins

RemoveMErdhopkinsTakeThisOuTspamihug.co.nz

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

>My settings for MPLAB text are
> such that reserved words are blue, labels, macros etc are purple.
> CLRW is purple.



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004

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

2004\01\16@033353 by Jinx

face picon face
> How do you setup MPLAB to show different colours?

This is for late versions of MPLAB (any 6.x I believe, I know
it wasn't possible with the last 5.x I had)

Edit/Properties/Text/Choose Colours

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

2004\01\16@035258 by Hopkins

flavicon
face
Great - set mine to the default colours for now.- don't know why the default
colours weren't set automatically when I installed the program.
*************************************************

Roy Hopkins

RemoveMErdhopkinsspamTakeThisOuTihug.co.nz

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



> > How do you setup MPLAB to show different colours?
>
> This is for late versions of MPLAB (any 6.x I believe, I know
> it wasn't possible with the last 5.x I had)
>
> Edit/Properties/Text/Choose Colours
>



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004

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

2004\01\16@090207 by Olin Lathrop

face picon face
WH Tan wrote:
> It look like MPLAB 6.40 is unable to regonize CLRW as a mnemonic.

Right.  I see no such opcode in the data sheet.  What do you expect it to
do?


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

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

2004\01\16@090631 by Olin Lathrop

face picon face
WH Tan wrote:
> Ain't the 14-bit core is a subset of 16-bit?

No, it ain't completely.

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

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

2004\01\16@094206 by Bob Ammerman

picon face
On an 18F you could also say: CLRF WREG

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Ken Pergola" <RemoveMEno_spamspam_OUTspamKILLspamLOCALNET.COM>
To: <RemoveMEPICLISTTakeThisOuTspamspamMITVMA.MIT.EDU>
Sent: Friday, January 16, 2004 12:53 AM
Subject: Re: [PIC]: CLRW give compile error


{Quote hidden}

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

2004\01\16@112757 by Ken Pergola

flavicon
face
Bob Ammerman wrote:

> On an 18F you could also say: CLRF WREG

Hi Bob,

Definitely true, but that would be architecture-specific (not portable
across all PICmicro cores) just like 'CLRW' was in the original source code
the original posted has.

Using 'ANDLW 0x00' is architecture-independent (portable across various
PICmicro cores) if you want the source code to compile on multiple PICmicro
cores.

Best regards,

Ken Pergola

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

2004\01\16@123648 by

picon face
Ken Pergola wrote :
> Bob Ammerman wrote:
>
> > On an 18F you could also say: CLRF WREG
>
> Hi Bob,
>
> Definitely true, but that would be architecture-specific (not portable
> across all PICmicro cores) just like 'CLRW' was in the
> original source code the original posted has.

Well, the 18-series has 77 instructions, *42 more* then the
35 instructions in the 16-series.
Shouldn't you use *any* of those 42 "extra" instructions just to
keep the portability with the 16-series ?

If you *realy* need cross plattform portability, you could also
use conditional assembly (using different code for the 18 and the
16 series) whenever it's needed.

Jan-Erik.

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

2004\01\16@130106 by Ken Pergola

flavicon
face
Jan-Erik Soderholm wrote:

> Shouldn't you use *any* of those 42 "extra" instructions just to
> keep the portability with the 16-series ?

Hi Jan-Erik,

Maybe I did not make my point clearly enough. I'm not saying *not* to use
the PIC18 instruction set to its fullest at all. I encourage people to
embrace the PIC18 architecture and the *entire* PIC18 instruction set.

But look, it's obvious the original poster experienced an ASM portability
problem in the source code he was using because of differences in
instruction sets of target processors.

All I'm simply trying to point out to the original poster is that if *he*
wants to keep instruction set portability between a 14-bit core and the
PIC18 16-bit core he can use my suggestion. That's all -- there's nothing
more to read into my post than that.

Sorry if this was confusing to anybody -- it was not my intent.

Best regards,

Ken Pergola

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

2004\01\16@141703 by WH Tan

flavicon
face
Hi Olin,

> Right.  I see no such opcode in the data sheet.  What do you expect it to
> do?

Actually I was expecting it will perfrom MOVLW 0x00 as what I did in 16
series.

I got PICDEM 2+ demo board which came together with my new ICD2.
When I was looking inside the source, I found that it is written for a
PIC18F452 device. But it is fail when I try to compile.

I assume that is a bug or something else going wrong with my MPLAB v6.40.
But now I know it isn't.

Thanks a lot for your responces.

WH Tan

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

2004\01\16@153258 by Jinx

face picon face
> But look, it's obvious the original poster experienced an ASM
> portability problem in the source code he was using because of
> differences in instruction sets of target processors

I'm curious as to why his 452 .inc didn't take care of it, particularly
as the sample code appears to be intended for the 18 series (if
you re-read the OP)

"PICDEM 2+ sample code for PIC18F452"

Not that I've never had to tinker with the .inc files. This sounds more
like a compiler fault that should have been found in factory debugging

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

2004\01\16@194949 by WH Tan

flavicon
face
Jinx wrote:

>  #define clrw clrf WREG       ; PIC16Cxxx code substitution

> I'm curious as to why his 452 .inc didn't take care of it


But I can't find as what you said in 'p18f452.inc' & 'p18c452.inc'.
Is there anything possibly wrong with my MPLAB v6.40.

Thanks & regards.
WH Tan

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

2004\01\16@200233 by Jinx

face picon face
> But I can't find as what you said in 'p18f452.inc' & 'p18c452.inc'.
> Is there anything possibly wrong with my MPLAB v6.40.

It wouldn't surprise me. I don't use 6.40, perhaps someone
who does can try to compile CLRW for a 452

Is your compilation accessing a good .inc file ? Mine is in \Program
Files\MPLAB IDE\MCHIP_Tools

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

2004\01\16@203215 by Tom

flavicon
face
I just tried assembling those files and it all assembled --- except for the
lines in the p18math.asm file which consist of CLRW. These produced an error.

Both 6.40 and 6.30 failed to assemble this.  These *did* assemble when I
first tried last year. I think I was using something like maybe 6.10 back
then...

The CLRW instruction is not included in the instruction set as listed in
the PIC18F452 data sheet; however it *did* assemble in the past.  Something
does indeed seem to have changed.

You can use the work-around others have suggested to get the code to
assemble but it might be illuminating to consult M'chips support on this
one...

Good luck!
Tom

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

2004\01\17@024659 by WH Tan

flavicon
face
Hi Jinx,

> Is your compilation accessing a good .inc file ? Mine is in \Program
> Files\MPLAB IDE\MCHIP_Tools

Yes. I am sure about that.

Regards,

WH Tan

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\17@024907 by WH Tan

flavicon
face
Hi Tom,

So the problem is verified now.
Thank you very much for your time.

Regards,
WH Tan

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\17@102459 by Ken Pergola

flavicon
face
Hi WH Tan,

Microchip changed the PIC18F452.INC file at some point in time and dropped
several '16Cxxx/17Cxxx Substitutions' substitutions -- including CLRW.

The omissions were either intentional or an oversight. In any event, the
'Revision History' does not detail the omissions.
To see the details, compare the two PIC18F452.INC snippets below from the
latest MPLAB v6.41 installation and an older MPLAB installation.
There may have been other changes as well, but I'm just focusing here on
your original question about CLRW:




       PIC18F452.INC SNIPPET FROM MPLAB v6.41:


;==========================================================================
;
;       Revision History
;
;==========================================================================
;Rev:   Date:      Details:                                           Who:
;1.0    03/23/01   Modified C452 for F452                             tr
;1.1    08/01/01   Added EECON1 bits, corrected code protect config bit inserts
;1.2    09/17/01   Corrected MAXRAM,BADRAM                            tr
;1.3    10/23/01   Corrected CONFIG bits/registers                    tr/pas


;==========================================================================
;       16Cxxx/17Cxxx Substitutions
;==========================================================================

 #define clrw clrf WREG       ; PIC16Cxxx code substitution (WREG is
addressable)
 #define CLRW CLRF WREG       ; PIC16Cxxx code substitution (WREG is
addressable)
 #define negw negf WREG       ; PIC16Cxxx code substitution (WREG is
addressable)
 #define NEGW NEGF WREG       ; PIC16Cxxx code substitution (WREG is
addressable)
 #define movpf movff          ; PIC17Cxxx code substitution
 #define MOVPF MOVFF          ; PIC17Cxxx code substitution
 #define movfp movff          ; PIC17Cxxx code substitution
 #define MOVFP MOVFF          ; PIC17Cxxx code substitution
 #define lcall call           ; PIC17Cxxx code substitution
 #define LCALL CALL           ; PIC17Cxxx code substitution
 #define lgoto goto           ; PIC17Cxxx code substitution
 #define LGOTO GOTO           ; PIC17Cxxx code substitution
 #define DDRA  TRISA          ; PIC17Cxxx SFR substitution
 #define DDRB  TRISB          ; PIC17Cxxx SFR substitution
 #define DDRC  TRISC          ; PIC17Cxxx SFR substitution
 #define DDRD  TRISD          ; PIC17Cxxx SFR substitution
 #define DDRE  TRISE          ; PIC17Cxxx SFR substitution




       PIC18F452.INC SNIPPET FROM AN OLDER MPLAB INSTALLATION:


;==========================================================================
;
;       Revision History
;
;==========================================================================
;Rev:   Date:      Details:                                           Who:
;1.0    03/23/01   Modified C452 for F452                             tr
;1.1    08/01/01   Added EECON1 bits, corrected code protect config bit inserts
;1.2    09/17/01   Corrected MAXRAM,BADRAM                            tr
;1.3    10/23/01   Corrected CONFIG bits/registers                    tr/pas
;1.4    09/26/02   Include both names SWDTE and SWDTEN                pas


;==========================================================================
;       16Cxxx/17Cxxx Substitutions
;==========================================================================

 #define DDRA  TRISA          ; PIC17Cxxx SFR substitution
 #define DDRB  TRISB          ; PIC17Cxxx SFR substitution
 #define DDRC  TRISC          ; PIC17Cxxx SFR substitution
 #define DDRD  TRISD          ; PIC17Cxxx SFR substitution
 #define DDRE  TRISE          ; PIC17Cxxx SFR substitution

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\17@104745 by

picon face
Hi.

Those defines are a major problem if you (as IMHO
anyone should) are running your environment *not*
case sensitive. Note that Microchip have added
multiple defines just in different case :

>   #define clrw clrf WREG       ; PIC16Cxxx code substitution
>   #define CLRW CLRF WREG       ; PIC16Cxxx code substitution

This produces a lot of "multiple defines" errors...
Yes, easy to "fix", but you shouldn't have to "fix"
built-in include files.

And, there is also a risk thay you get lazy and don't
throufully learn the new instruction set. For porting
task, yes these might be fine, but not for new
development. Finaly, these should have been in a special
backward-compatibility-include-file, that you could include
*when needed*. Having them in the device specific include
files just confuses people, which this thread clearly proves. :-)

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\17@115840 by Olin Lathrop

face picon face
Ken Pergola wrote:
> Microchip changed the PIC18F452.INC file at some point in time and
> dropped several '16Cxxx/17Cxxx Substitutions' substitutions --
> including CLRW.

I'm glad to hear that as I had been suggesting that for quite a while.  The
include file for a particular processor should only contain the definitions
for that processor.  If you want compatibility from a 16 to and 18 PIC, then
you should make a separate include file for that (or Microchip could provide
it).

Keeping fluff out of a mandatory include file is just good design.  I don't
want undocumented symbols automatically created.  These will cause more
trouble in the long run than they are worth.  I would rather have the
assembler give me an error so that I can decide how to fix it.  I might want
to use a bunch of conversion symbols, but then again I may be specifically
looking for non-18 syntax.  Another problem is with conditional assembly
code that uses IFDEF to decide what to emit.  Such code may work other than
what the manual would lead you to believe when unexpected compatibility
symbols are defined.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\01\17@120256 by Olin Lathrop

face picon face
Jan-Erik Soderholm XA (TN/PAC) wrote:
> Those defines are a major problem if you (as IMHO
> anyone should) are running your environment *not*
> case sensitive. Note that Microchip have added
> multiple defines just in different case :
>
>>   #define clrw clrf WREG       ; PIC16Cxxx code substitution
>>   #define CLRW CLRF WREG       ; PIC16Cxxx code substitution

This exact problem forced me to edit 18 family include files every new
release of MPLAB for a while.  I sent a bug report about that every time.  I
did notice that this was recently fixed.  Thank you Microcchip.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

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