50002160 A
50002160 A
This document provides an overview of the migration 3. Device-dependent code largely remains
process from MPLAB® C Compiler for PIC18 MCUs identical
(formerly, and referred to here as, MPLAB C18) and For both compilers, the special function register
MPLAB XC8 C Compiler, so that you may judge the and Configuration bit names are derived from
effort required to convert your project. the same database. Differences may occur
MPLAB C18 is nearing end of life. When working with when migrating from early versions of MPLAB
MPLAB C18 projects, you can continue to use the leg- C18. The means of accessing SFRs and
acy compiler, temporarily compile the project in the Configuration bits is identical.
MPLAB XC8’s C18 compatibility mode, or migrate the In the following situations, the required MPLAB XC8
project to the native MPLAB XC8 settings and syntax. code might be structured differently than that for
The latter is recommended if the project is to be further MPLAB C18. Before you try to mimic the MPLAB C18
developed. keywords, consider that MPLAB XC8 may have an
Technical details of the changes to source code and easy way of doing what you need.
options are described in the “MPLAB® C18 to MPLAB 1. Pointers are handled differently
XC8 C Migration Guide” (DS52118). In summary, the
MPLAB XC8 does not use pointer memory mod-
process consists of the following steps:
els, nor are pointer qualifiers used. You do not
1. Create a new project need to write multiple function variants that take
There is no automated process that can convert pointer arguments.
existing MPLAB C18 projects.
2. Interrupt code is defined by one function
2. Add in the source files Typically, a single keyword creates the interrupt
Only C and assembly source is read by MPLAB function and all the context switch code.
XC8. You must obtain source code for object or
3. Use alternative ways to allocate objects
library routines used by your project.
Consider absolute objects or bank qualifiers
3. Confirm the compiler options before creating user-defined sections.
The default compiler (or MPLAB X IDE plugin)
4. Stack allocation of variables is different
options, will be suitable for most projects.
The stack used for variables can only be speci-
4. Build, working through warnings and errors fied at the function level. Typically, you do not
Most incompatible features will trigger errors in need to use any specifiers or options to obtain
MPLAB XC8, which you can work through. the best implementation when using MPLAB
XC8.
5. Convert the source code
Source code must have MPLAB XC8 C Com- 5. Linker scripts are not used
piler native syntax. Conversion is a manual pro- The default MPLAB XC8 linker options will be
cess, but most existing code will compile as-is. suitable for most projects. Linker options can be
expanded or adjusted; but, with caution.
To assist the conversion, make use of compiler-defined
preprocessor macros to maintain both original and 6. Preprocessor macros cannot have variable
modified code. Consider the following observations argument lists
when converting the code. If you use these, you will need to use alternate
1. ANSI compliant code will require no change macros or a function.
This covers most code. 7. Assembly code is not portable
2. Review code making assumptions about You will need to review any hand-written assem-
implementation-defined behavior bly code. There are differences in assembly
Behavior differences are summarized in the instruction syntax, assembler directives, and the
migration document. Both compilers’ user’s general structure of assembly code.
guides describe their implementation-defined
behavior.
NOTES:
• Microchip believes that its family of products is one of the most secure families of its kind on the market today, when used in the
intended manner and under normal conditions.
• There are dishonest and possibly illegal methods used to breach the code protection feature. All of these methods, to our
knowledge, require using the Microchip products in a manner outside the operating specifications contained in Microchip’s Data
Sheets. Most likely, the person doing so is engaged in theft of intellectual property.
• Microchip is willing to work with the customer who is concerned about the integrity of their code.
• Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their code. Code protection does not
mean that we are guaranteeing the product as “unbreakable.”
Code protection is constantly evolving. We at Microchip are committed to continuously improving the code protection features of our
products. Attempts to break Microchip’s code protection feature may be a violation of the Digital Millennium Copyright Act. If such acts
allow unauthorized access to your software or other copyrighted work, you may have a right to sue for relief under that Act.
QUALITY MANAGEMENT SYSTEM Microchip received ISO/TS-16949:2009 certification for its worldwide
headquarters, design and wafer fabrication facilities in Chandler and
CERTIFIED BY DNV Tempe, Arizona; Gresham, Oregon and design centers in California
and India. The Company’s quality system processes and procedures
are for its PIC® MCUs and dsPIC® DSCs, KEELOQ® code hopping
== ISO/TS 16949 == devices, Serial EEPROMs, microperipherals, nonvolatile memory and
analog products. In addition, Microchip’s quality system for the design
and manufacture of development systems is ISO 9001:2000 certified.