MCC18使用随笔

修改时间：2010-08-02

修改人 ：张元南

修改说明：不作为系统入门的指导文档，仅作为初次接触MCC18的开发人员的辅助文档。

部分观点为一家之言，还请理解。

MCC18使用随笔

一、为什么使用MCC18

MCC18编译器是MICROCHIP自主开发的针对PIC18系列MCU的编译器。在中国大陆，就笔者的多年FAE的经验，在用C语言开发PIC18的用户中，与PICC18各占半壁江山。笔者比较系统使用MCC18开发不过是今年7月份以来的事情。为什么选择MCC18？有一个主要理由：没有版权问题，省心。有一个次要理由：支持的协议栈丰富，包括实时操作系统。

MCC18的标准评估版，60天内与正版无任何差异，60天后仅仅优化功能无法使用，而大多数PIC18F的项目，ROM和RAM空间并不紧张，不优化，也无所谓。MCC18可以最快支持PIC18系列的芯片，尤其是廉价的PIC18J，PIC18K系列，支持可靠，稳定。所谓可靠稳定是指编译结果可靠。稳定则是指不会突然发生一些奇异的功能缺失。

此外，目前MICROCHIP自己开发的协议栈，PIC18系列，已经只提供对MCC18的支持，PICC18需要自己动手处理，而笔者钟爱的F*R*E*E*RTOS，以及其它OS，找到对MCC18的现成移植是很容易的。

二、MCC18的“缺点”

1）格式死板，汇编痕迹多

对比MCC18、PICC18对中断函数的声明，就可以发现此点。MCC18有LKR文件，如果你定义一个超过256字节的全局变量，必须手动在RAM中为其指定固定地址，并修改LKR文件。如果使用的局部变量超过256字节，也必须手动修改LKR文件，为其分配足够的堆栈区。

2）数学算法，整形提升，不够聪明

笔者在开发PIC18的代码时，从PIC16F的PICC上移植了一些代码，结果一直得不到正确结果，经过DEBUG终于发现，编译器在进行数学运算，整形提升时，不够聪明。比如以下代码：

unsigned int OCVal,ICVal;

OCVal = (PR2+1)*16 ;

PIC8BIT芯片，PR2目前都是一个8位寄存器，尽管OCVal是16位整型，但由于算式右边都是8位整型，因此计算出的结果是将一个8位整型赋给OCVal，最后笔者被迫这么写代码：

OCVal =(unsigned int) (PR2+1)*16 ;

而采用PICC编译器，就不需要这么麻烦。

3）编译速度慢

这个是BBS上的公论，笔者编译PIC18F4620驱动SD卡的程序，编译后的程序大概有30多KB，双核T2370的MCU，楞是每次卡个10S。而同样大小的PICC18程序，早就编译完了。当然，这样的对比不具备完全的可靠性，不过笔者实在没有把PIC18F4620+SD卡的程序用PICC18编译器移植的动力，等有心思的时候移植下，再做对比测试。

三、MCC18版本的演变

MCC18最早的版本，当使用调试器调试时，比如ICD2/PICKIT3等，是需要在项目中添加带i的LKR文件，比如PIC18F4620，就要添加18f4620i.LKR文件，以避开调试器占用的资源。到了V3.35版本，带i和不带i的LKR文件就被统一到一个LKR文件中了，在调试的时候，在工具栏选择DEBUG，而在烧写的时候，在工具栏选择RELEASE编译，并且IDE

可以友好提示。

V3.35版本，LKR文件所在的文件夹也发生了变化，挪到c:\mcc18\bin\LKR\文件夹下。

四、MCC18的常见问题

经常有人提问，为什么我编译后提示c018i.o文件找不到。请在项目中，设置include路径到c:\mcc18\h，设置lib路径到c:\mcc18\lib，设置lkr路径（针对MCC18V3.35以及更高版本）到c:\mcc18\bin\lkr。

还有一个问题是，如何分配一个超过256个字节的数组。如果你的时间很紧张了，人越紧张，很多简单的东西往往越学不进去，那我建议你把数组拆成2个以上独立的小于256字节的数组。如果你有一定的时间，可以看看MICROCHIP关于SD卡的项目，该项目使用的就不是默认的LKR，其中就分配了1个512字节，1个1024字节的数组，并分配了512字节的堆栈（默认为256字节）。当这样做后，项目路径的LKR请不要设置到默认路径。一般我们直接把特殊的手动修改的LKR直接放在项目目录下，此时LKR的路径请不要设置。

五、MCC18编译器的发展

此点纯属猜测，因为MCC18编译器的LKR路径下，出现了大量PIC16F芯片的LKR，MCC16应该迟早是要出来的。MCC16的问世，也将解决PIC16F的开发人员到处找编译器的历史（当然，您可以选择不用MCC16，可能你测试后也会发现MCC16有与MCC18一致的“缺点”）。

六、PICC18编译器的“缺点”

严格来说，笔者没有资本评说，笔者没有足够的资金把PICC18的每个版本的正版买下来测试，因此测试对象（DEMO版本及其变种）本身可能就是故意设计成如此的。姑且看看这些版本，9.xx的版本是让笔者郁闷的版本，比如9.50PLX-STD的几个版本，局部变量居然无法观察，而到9.61-PRO版本，LIST文件中大量丢失反汇编代码，导致编译的HEX倒是对的，烧片或者全速运行没什么问题，就是大量的区域（反汇编代码丢失的区域）无法设置断点调试。对于不打算花几百美圆到1000多美圆使用PICC18正版的用户，选择MCC18，无疑能避免很多烦心的事情。至于MCC18的几个“缺点”，笔者认为只要不是半路项目换编译器，又有调试器，咬咬牙都是可以克服的。此次PIC591开发的PIC18F的DEMO，也选择MCC18编译器，这样的选择，对将来移植到PIC18J，或者PIC18K，笔者都不需要折腾测试编译器的事了。