genrally i am using xc8 compiler but start to to c18 compiler. but when done code then it works on xc8 compiler but didn't on c18.
i just changed the header for respectively.
so what is changes required for each compiler to make the code work on c18.
and which compiler is best?
i know this question is common but can suggest compiler you are using.

 

C18 is being phased out and replaced by the newer XC8 compiler. Essentially, there no reason you should start using it unless you have a real possibility of having to work on projects compiled with it.

 

But what is reason code work on xc8 but not c18.

 

But what is reason code work on xc8 but not c18.

They are different compilers and implement code differently as such.

Embedded C is not the same as the C standard - there are nuances with microcontrollers that don't mesh well with C. This means each compiler will have different approaches and implementations to overcome these issues.

That is not to mention the different libraries that come bundled with each.

 

But what is reason code work on xc8 but not c18.

This must be the "portability" of C that everyone talks about...

 

This must be the "portability" of C that everyone talks about...

.... This is not the C standard and is not the target when saying C is portable.

 

This must be the "portability" of C that everyone talks about...

Also. I might add, portability can be achieved by really thinking out your code... I keep my code as close to ansi C as humanly possible. so almost all of my code will port easily to the new XC8... Alot of newbies tend to use all these libraries that are bundled... "anding this and oring that" C18 made there own bed ( so to speak ) I think that the C18 libraries will kill off users trying to move to XC8.... Major flaw in my book... Keep it simple....

 

I'm a native C programmer. No problems at all for C18. I've yet to get a program to build on XC8.

 

.... This is not the C standard and is not the target when saying C is portable.

All I know is that I've got legacy products with PIC code written as far back 1992 in .asm, and they still assemble fine today regardless of the assembler I am using.

If they were C, the rewrites would put me out of business.

 

C18 is being phased out and replaced by the newer XC8 compiler. Essentially, there no reason you should start using it unless you have a real possibility of having to work on projects compiled with it.

I built one project with XC8 and it will be my last project. I will be going back to C18 until things improve with XC8 or C18 actually goes away.

My biggest complaint is that XC8 is overly thorough on optimization and there is no way to turn it off as there is in C18.

 

All I know is that I've got legacy products with PIC code written as far back 1992 in .asm, and they still assemble fine today regardless of the assembler I am using.

If they were C, the rewrites would put me out of business.

That is because the assembly code is directly translated to opcodes, where the C compiler compile to assembly, then translates into opcodes - each compiler has a different approach to how a for loop should work in assembly, or how to do 3.14159265*0.7071 in a fixed point processor such as the 8-bit PIC family.

If you were to take the disassembly from a previously compiled project written in C and compiled that asm file, you'd get the same processor action, regardless of what compiler made it.

If something might need tweaking down the line, keep a copy of the compiler on hand...

 

I built one project with XC8 and it will be my last project. I will be going back to C18 until things improve with XC8 or C18 actually goes away.

My biggest complaint is that XC8 is overly thorough on optimization and there is no way to turn it off as there is in C18.

I believe they recently did a large update to XC8 (I recently found out, at least) to address some of the major complaints (I'm not sure on any specifics), and I'm going to give it another shot.

I tried it in its infancy and found it unwieldy and an an absolute displeasure to work with. After trying more projects and rewriting a few(not to mention updates), I've gotten to a point where I can use it just fine.

 

Microchip like to keep moving the goal posts.
Its to make sure you keep upgrading to new software !

Most of my software was written under MPLAB and PICSTART plus.
Now neither are current.

 

I recently downloaded some tools setting up a workstation and discovered Microchip has completely revamped their applications library (MLA). It lives in a different folder (the default is no longer directly off the root).

Definitely worth looking into for any MC users.

XC is apparently working much better, the initial pointer problems introduced a while back are long gone. I am using it for my latest project as a test case and it is behaving well.

MPLAB-X has been as issue, I just can't get a PICkit 2 or 3 to be recognized by it, so I dropped back and punted with MPLAB-no X.

Most of my software was written under MPLAB and PICSTART plus.

It just irks me to see statements such as this. Neither MPLAB nor PICSTART perform any code operations.

PICSTART is a programmer and works with any hex file handed to it.

MPLAB is an environment, just a glorified ASCII text editor, where many different compilers may be used. Even different versions of the same compiler. It don't make code.