CCS5.5使用总结 而5.5则是通过属性设置的。 3.3头文件设置位置

Include Search Path中设置了绝对路

径：..\\..\\DSP281x_headers\\include;..\\..\\DSP281x_common\\include没有引号

3.3库函数添加：

在Libraries下的Search Path中设置为：..\\..\\DSP281x_headers\\include 所以即便工程中不含rts2800_ml.lib,工程编译也不会出错（测试过）。 但exmple工程下的Lib和.h文件是如何添加进去的呢?

毕竟build option下没有添加他们的头文件路径，仔细分析发现:

5.5下头文件可以手动添加和删除，3.3下头文件无法手动删除，添加方法是通过将头文件放置到工程路径下，然后再需要调用的.c文件下包含该头文件，则头文件自动添加进去了。

是手动添加进去的，CC5.5也能添加，但此种方法操作头文件后路径则不会显示出来，而且跟.C文件混在一起不易查找，不建议这么做。

共32页 第24页

CCS5.5使用总结 13

从3.3转为5.5时通用板程序.ebss分配的内存空间不足

左图是CCS5.5，右图是CCS3.3

原本没有错误的，但移植到5.5报错：

原因是.ebss分配空间变大很多，超出0X1000，无法生成.OUT文件。其它PGM48-DO/AI/DI/DI6pulse转换都没有问题，转换方法一样。细查代码发现在Example_Flash281x_API.h中原CCS3.3的buffer定义如下：

#define WORDS_IN_FLASH_BUFFER 0x800 // Programming data buffer, Words extern volatile Uint16 Buffer[WORDS_IN_FLASH_BUFFER]; 而CCS5.5的的buffer定义如下：

#define WORDS_IN_FLASH_BUFFER 0x800 // Programming data buffer, Words volatile Uint16 Buffer[WORDS_IN_FLASH_BUFFER];

即5.5中的Buffer变成了一个800个元素的Uint16数组，导致占用了大量内存空间，将原CCS3.3的Example_Flash281x_API.h重新拷贝到CCS5.5下，重新加载编译，工程编译通过！！

14

创建的CCS5.5工程文件夹名修改后不可用

发现：创建了PGM48相应的DO/AI/DI等系列工程编译都没有问题，拷贝的其它盘的任何英文路径或者其它电脑都没有问题，但拷贝用于地铁打磨车需要对工程文件夹重新命名则发现修改名字后工程编译有问题了。没有解决：

15

程序修改记录及修改对比

共32页 第25页

CCS5.5使用总结 在编辑器中右键单击一个文件，选择“团队 - >显示本地的历史”(Team -> Show Local History) 您可以把当前的源文件对任何以前的版本作比较或回滚到以前的版本 打开方式：

历史记录如下：

共32页 第26页

CCS5.5使用总结 如果发现修改程序引起很大错误，则可以通过：

右键单击该项目，并在菜单中选择“从本地历史恢复”(Recover from Local History)

恢复到未修改前的程序版本。

16

新建库文件并且调用库文件中的函数

该方法主要是对自己编写的一些关键重要函数进行保护和保密，同时让使用者又直接调用使用。 新建工程选择输出为Library格式，而不是Executable(.OUT),

新建目标函数.C和.H文件：

共32页 第27页