2024年7月14日发(作者:徭金枝)
CCS5.5使用总结
目 次
1 报警信息Warning“compatibility cannot be determined”处理方法 ....................... 1
2 报警信息Warning “creating ".stack" section with default size of 0x400; use the -stack option
to change the default size” ........................................................... 3
3 建议信息advice “Current optimization/debug settings: -opt_level=off --opt_for_speed=2 ”
...................................................................................... 5
4 注释字体大小不一,难以辨认 .......................................................... 6
5 错误Problem:“ cannot find file/ Description Resource Path Location Type .......... 8
6 错误Problem:”unresolved symbol _Flash2812_Erase, first referenced in ./Par_
PGM48_DO_V1.0
F2812_EzDSP_RAM_” 11
7 错误信息Problem:”specifies ISA revision "C2800", which is not compatible with ISA revision
"C2700" specified in a previous file or on the command line Problem”
12
8 打开已有CCS5.5工程 ................................................................ 14
9 绝对路径设置(编译程序拷贝或剪切到其它电脑或者盘都可用) ........................... 16
10 工程路径定义(不可修改)和源代码链接定义(可修改) ................................ 18
11 从CCS3.3移植到CCS5.5的技巧 ...................................................... 18
12 CCS3.3与CCS5.5异同比较 .......................................................... 22
13 从3.3转为5.5时通用板程序.ebss分配的内存空间不足 ................................ 25
14 创建的CCS5.5工程文件夹名修改后不可用 ............................................. 25
15 程序修改记录及修改对比 ............................................................ 25
16 新建库文件并且调用库文件中的函数 .................................................. 27
17 工程文件的注释文字出现乱码解决办法 ................................................ 29
18 编译好的工程拷贝到其它路径下变成出错:“gmake: *** No rule to make ” ............... 32
19 工程文件管理及版本变更方法 ........................................................ 33
20 附件 .............................................................................. 34
I
CCS5.5使用总结
1
报警信息Warning“compatibility cannot be determined”处理方法
具体报警信息如下:
此信息代表编译obj所用编译器的版本与当前工程的编译器版本不一致(原来是3.3工程编译器与5.5编
译器版本是不一样的),但不影响编译生成的结果,可忽略,也可以在属性中使用--diag_suppress=16002
来消除此警告信息
处理步骤:
1) 点开工程属性:
共32页 第1页
CCS5.5使用总结
2) 打开build/C2000linker/Advancd Option/Diagnose:
3) 在suppress diagnostic下设置:Diag_suppress=16002
共32页 第2页
CCS5.5使用总结
再次编译,问题解决:
2
报警信息Warning “creating ".stack" section with default size of 0x400;
use the -stack option to change the default size”
具体如下:
共32页 第3页
CCS5.5使用总结
根据报警提示,需修改堆栈默认大小=0x400,具体路径如下:
再次编译,报警消除:
共32页 第4页
CCS5.5使用总结
3
建议信息advice “Current optimization/debug settings: -opt_level=off
--opt_for_speed=2 ”
具体信息:
按提示属性修改成如下设置:
opt_level=off
opt_for_speed=2
共32页 第5页
CCS5.5使用总结
再次编译,问题消除,编译通过:
4
注释字体大小不一,难以辨认
共32页 第6页
CCS5.5使用总结
发现CCS3.3移植到CCS5.5后,注释部分尤其是汉字明显变小,修改字体大小及颜色方法:
进入Preference下:
共32页 第7页
CCS5.5使用总结
通过Colors and Fonts来设置!
5
错误Problem:“ cannot find file/
Description Resource Path
Location Type
具体错误:
共32页 第8页
CCS5.5使用总结
错误原因:找不到Flash2812_API_V210库函数,需要添加该库函数。
先找到库函数添加位置:
其中的“CG_TOOL_ROOT”路径定义为:
共32页 第9页
CCS5.5使用总结
在自己的调试机上找到该路径:
发现并没有Flash2812_API_V210库函数,将原来CCS3.3工程下的Flash2812_API_V210库函数拷贝到此文件
下,再编译没有问题:
共32页 第10页
CCS5.5使用总结
6
错误Problem:”unresolved symbol _Flash2812_Erase, first referenced
in ./Par_ PGM48_DO_V1.0 F2812_EzDSP_RAM_”
报错信息:
同5的处理方法一样!
共32页 第11页
CCS5.5使用总结
7
错误信息Problem:”specifies ISA revision "C2800", which is not
compatible with ISA revision "C2700" specified in a previous file or on
the command line Problem”
具体信息如下:
原因分析:编译器下同时存在多个的版本,而工程中添加了该路径的Lib文件,导致编译
报错:C2800与C2700不匹配或者C2800与C28FPU32不匹配!
解决办法:
将编译器下的相关.lib文件剪切到各自工程中,各工程根据自己需要来添加哪些.Lib文件加入:
先删除编译器下相关的.lib文件:
共32页 第12页
CCS5.5使用总结
然后工程中加入自己工程下的Lib文件
工程下的各种cmd/.C/.asm/.lib文件都可以通过直接拖到工程下的方式链接到工程。同时删除属性下的
Lib路径设置:
共32页 第13页
CCS5.5使用总结
再次编译,没有错误:
8
打开已有CCS5.5工程
1 右上角切换到编辑模式
2 Project下打开已有CCS5.5工程:
共32页 第14页
CCS5.5使用总结
3 选择工程名所在路径,并选中工程名:
则自动选中工程了:
共32页 第15页
CCS5.5使用总结
点击finish,则工程打开成功!
9
绝对路径设置(编译程序拷贝或剪切到其它电脑或者盘都可用)
当我们在PC机上新建了一个CCS5.5工程,并且成功编译通过。然后当将该程序剪切到别的盘或者别的电脑
再次打开时发现编译报错:“找不到头文件”
原因很简单:头文件设置用的是绝对路径:"D:DSP_exePGM48_DO_V1.0DSP281x_commoninclude"
共32页 第16页
CCS5.5使用总结
当剪切到E盘或者其它电脑的E盘或者F盘,则“D:DSP_exePGM48_DO_V1.0“已经不复存在,故无法找到
该路径,头文件自然无法找到,解决办法,改为绝对路径:
"....DSP281x_commoninclude"则无论是放到哪里,只会识别本工程下的“DSP281x_commoninclude
“文件夹下的头文件。如图所示(原来创建到D盘,剪切到E盘了):
剪切到C盘编译:
当然库文件的绝对路径不用修改,因为CCS默认安装是C:ti
共32页 第17页
CCS5.5使用总结
10
工程路径定义(不可修改)和源代码链接定义(可修改)
工程安装路径及工程所在路径定义
源代码链接定义(可修改):
11
从CCS3.3移植到CCS5.5的技巧
共32页 第18页
CCS5.5使用总结
1) 创建工程文件夹
首先,需要在电脑某盘下创建相应文件夹如C:PGM48_DO_V1.0_CCSV5PGM48_DO_V1.0_CCSV5,然
后将工程指定到该路径下,这样.cproject等文件都在指定文件夹下,否则工程文件会放得到处
都是,个人感觉这这一步是便于你管理工程文件和存档。
然后,将cmd文件拷贝到该工程文件夹下。
在工程名文件夹同一级下创建common/headers、UserHeader/ UserSource等文件夹。
将原来CCS3.3中的common/headers都拷贝过来,将原来CCS3.3自己设计的头文件和源程序.C文件
分别拷贝到UserHeader/ UserSource下。
将原来CCS3.3中的库文件”Flash2812_API_”拷贝到编译器lib安装路径下
“C:ticcsv5toolscompilerc2000_6.2.0lib”。
自此,原来CCS3.3下的所有类型文件(.C/.h/.cmd/.lib/.asm)文件都已经在工程文件夹下。
2) 将相关源文件、头文件、cmd文件、库文件链接到程序工程中。
.C /.cmd/.asm直接链接到工程中。
共32页 第19页
CCS5.5使用总结
通过单击右键“Add file”
然后选中相应文件:
选中link to project:
则链接完成。
共32页 第20页
CCS5.5使用总结
3) 设置.h和.lib的链接路径(必须是相对路径,如果是绝对路径则程序被剪切到其它位置后编译会
出错)。
头文件链接加入方法
单击右键选中“Properties“打开.在Build/Include Options/下添加你工程所需头文件:
"....DSP281x_commoninclude"
"....DSP281x_headersinclude"
"....UserHeader"
系统自带头文件是自动加入的:
"${CG_TOOL_ROOT}/include"
其中CG_TOOL_ROOT在linked Resource可以找到:
共32页 第21页
CCS5.5使用总结
.lib文件链接加入方法:
在File Search Path下通过"${CG_TOOL_ROOT}/lib"添加进来,前提是”Flash2812_API_ “已经
拷贝到CG_TOOL_ROOT下,否则编译出错,提示找不到FLASH_api系列的函数和变量,无法生成.OUT.
4) 保存工程,开始编译整个工程。
一般会出现,API库版本不兼容的报警,不过不影响编译结果,这个紧紧是因为CCS5.5编译了原来
CCS3.3下的API函数而已,该报警处理方法见报警信息Warning“compatibility cannot be determined”
处理方法。
另外,还会出现堆栈值报警,该报警信息处理见Warning “creating ".stack" section with default
size of 0x400; use the -stack option to change the default size”的处理方法。
12
CCS3.3与CCS5.5异同比较
CCS3.3工程
共32页 第22页
CCS5.5使用总结
CCS5.5
3.3下.lib显示在工程下,并且可以手动增减。5.5必须是路径设置自动查找,并且不显示在工程下。
3.3工程下的文件是分类列出,5.5则没有,但其头文件自动显示了所在位置源头。
3.3的连接目标板和仿真器是通过与CCS独立的SetUP来设置,5.5则集成进来,只需要配置文件Target
Config中将芯片型号和仿真器型号设置好就OK了。
3.3的头文件添加时通过Project下的Build option来设置的:
共32页 第23页
CCS5.5使用总结
而5.5则是通过属性设置的。
3.3头文件设置位置
Include Search Path中设置了绝对路
径:....DSP281x_headersinclude;....DSP281x_commoninclude没有引号
3.3库函数添加:
在Libraries下的Search Path中设置为:....DSP281x_headersinclude
所以即便工程中不含rts2800_,工程编译也不会出错(测试过)。
但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页
CCS5.5使用总结
编译通过会发现DEBUG文件夹下有.lib文件:
将该.LIB文件拷贝到需要调用该LIB库中函数的工程文件夹下,并且链接到该工程文件:
共32页 第28页
CCS5.5使用总结
通过添加头文件调用该函数:
17
工程文件的注释文字出现乱码解决办法
出现乱码时:
共32页 第29页
CCS5.5使用总结
单个源代码的乱码问题:
首先单击右键选择属性:
然后Resource下找到Text file encoding:
最后将UTF-8格式改成GBK格式:
共32页 第30页
CCS5.5使用总结
应用GBK格式后:
如果是整个工程都出现文字乱码则统一修改:
需要注意的是:无论是哪种方式修改必须都是先从上层修改开始,依次到下层:
即工作空间->工程—>源文件
其中工作空间修改的方式如下:
共32页 第31页
CCS5.5使用总结
GBK与UTF-8区别,百度答案:
字符均使用双字节来表示,只不过为区分中文,将其最高位都定成1。
至于UTF-8编码则是用以解决国际上字符的一种多字节编码,它对英文使用8位(即一个字节),中文使用24位(三个字
节)来编码。对于英文字符较多的论坛则用UTF-8节省空间。
GBK包含全部中文字符;UTF-8则包含全世界所有国家需要用到的字符。
GBK是在国家标准GB2312基础上扩容后兼容GB2312的标准(好像还不是国家标准)
UTF-8编码的文字可以在各国各种支持UTF8字符集的浏览器上显示。
比如,如果是UTF8编码,则在外国人的英文IE上也能显示中文,而无需他们下载IE的中文语言支持包。 所以,对于英文比
较多的论坛 ,使用GBK则每个字符占用2个字节,而使用UTF-8英文却只占一个字节。
UTF8是国际编码,它的通用性比较好,外国人也可以浏览论坛,GBK是国家编码,通用性比UTF8差,不过UTF8占用的数
据库比GBK大~
18
编译好的工程拷贝到其它路径下变成出错:“gmake: *** No rule to make ”
原本工程路径如下:
共32页 第32页
CCS5.5使用总结
加载到CCS5.5编译正确通过!
但拷贝一份到其它路径:
编译却出错:
查看头文件设置的都是绝对路径,在工程中也加载进来了,什么原因?
但将工程文件直接拷贝到D或者E盘下编译都没有问题,什么原因?
19
工程文件管理及版本变更方法
共32页 第33页
CCS5.5使用总结
如果对程序要进行版本修订,又要保持一份原版本的,则可通过以下方法实现:
新建一个文件夹“WlCnt_EthDrive”,用于存储所有版本:
将原始老版本V1.0(在CCS5.5下新建工程生成的)拷贝进去,在再次文件夹下将V1.0复制一份命名为
V1.1,同时在CCS5.5下打开后将工程名改为V1.1,否则CCS会任务与原工程同名,编译没有问题!
如果再用V1.1去创建V1.2会发现,V1.2工程链接到V1.1的.C去了,这样在编辑代码时实际是编辑了
V1.1工程下的源代码,所以必须用原本创建!
20
附件
附件1:2812寄存器查询
附件2:MCP2515寄存器查询
附件3:SAE_J1939-71应用层-车辆
附件4:28335寄存器查询
附件5:MCU_DSP_SOFTWARE V1.0
共32页 第34页
2024年7月14日发(作者:徭金枝)
CCS5.5使用总结
目 次
1 报警信息Warning“compatibility cannot be determined”处理方法 ....................... 1
2 报警信息Warning “creating ".stack" section with default size of 0x400; use the -stack option
to change the default size” ........................................................... 3
3 建议信息advice “Current optimization/debug settings: -opt_level=off --opt_for_speed=2 ”
...................................................................................... 5
4 注释字体大小不一,难以辨认 .......................................................... 6
5 错误Problem:“ cannot find file/ Description Resource Path Location Type .......... 8
6 错误Problem:”unresolved symbol _Flash2812_Erase, first referenced in ./Par_
PGM48_DO_V1.0
F2812_EzDSP_RAM_” 11
7 错误信息Problem:”specifies ISA revision "C2800", which is not compatible with ISA revision
"C2700" specified in a previous file or on the command line Problem”
12
8 打开已有CCS5.5工程 ................................................................ 14
9 绝对路径设置(编译程序拷贝或剪切到其它电脑或者盘都可用) ........................... 16
10 工程路径定义(不可修改)和源代码链接定义(可修改) ................................ 18
11 从CCS3.3移植到CCS5.5的技巧 ...................................................... 18
12 CCS3.3与CCS5.5异同比较 .......................................................... 22
13 从3.3转为5.5时通用板程序.ebss分配的内存空间不足 ................................ 25
14 创建的CCS5.5工程文件夹名修改后不可用 ............................................. 25
15 程序修改记录及修改对比 ............................................................ 25
16 新建库文件并且调用库文件中的函数 .................................................. 27
17 工程文件的注释文字出现乱码解决办法 ................................................ 29
18 编译好的工程拷贝到其它路径下变成出错:“gmake: *** No rule to make ” ............... 32
19 工程文件管理及版本变更方法 ........................................................ 33
20 附件 .............................................................................. 34
I
CCS5.5使用总结
1
报警信息Warning“compatibility cannot be determined”处理方法
具体报警信息如下:
此信息代表编译obj所用编译器的版本与当前工程的编译器版本不一致(原来是3.3工程编译器与5.5编
译器版本是不一样的),但不影响编译生成的结果,可忽略,也可以在属性中使用--diag_suppress=16002
来消除此警告信息
处理步骤:
1) 点开工程属性:
共32页 第1页
CCS5.5使用总结
2) 打开build/C2000linker/Advancd Option/Diagnose:
3) 在suppress diagnostic下设置:Diag_suppress=16002
共32页 第2页
CCS5.5使用总结
再次编译,问题解决:
2
报警信息Warning “creating ".stack" section with default size of 0x400;
use the -stack option to change the default size”
具体如下:
共32页 第3页
CCS5.5使用总结
根据报警提示,需修改堆栈默认大小=0x400,具体路径如下:
再次编译,报警消除:
共32页 第4页
CCS5.5使用总结
3
建议信息advice “Current optimization/debug settings: -opt_level=off
--opt_for_speed=2 ”
具体信息:
按提示属性修改成如下设置:
opt_level=off
opt_for_speed=2
共32页 第5页
CCS5.5使用总结
再次编译,问题消除,编译通过:
4
注释字体大小不一,难以辨认
共32页 第6页
CCS5.5使用总结
发现CCS3.3移植到CCS5.5后,注释部分尤其是汉字明显变小,修改字体大小及颜色方法:
进入Preference下:
共32页 第7页
CCS5.5使用总结
通过Colors and Fonts来设置!
5
错误Problem:“ cannot find file/
Description Resource Path
Location Type
具体错误:
共32页 第8页
CCS5.5使用总结
错误原因:找不到Flash2812_API_V210库函数,需要添加该库函数。
先找到库函数添加位置:
其中的“CG_TOOL_ROOT”路径定义为:
共32页 第9页
CCS5.5使用总结
在自己的调试机上找到该路径:
发现并没有Flash2812_API_V210库函数,将原来CCS3.3工程下的Flash2812_API_V210库函数拷贝到此文件
下,再编译没有问题:
共32页 第10页
CCS5.5使用总结
6
错误Problem:”unresolved symbol _Flash2812_Erase, first referenced
in ./Par_ PGM48_DO_V1.0 F2812_EzDSP_RAM_”
报错信息:
同5的处理方法一样!
共32页 第11页
CCS5.5使用总结
7
错误信息Problem:”specifies ISA revision "C2800", which is not
compatible with ISA revision "C2700" specified in a previous file or on
the command line Problem”
具体信息如下:
原因分析:编译器下同时存在多个的版本,而工程中添加了该路径的Lib文件,导致编译
报错:C2800与C2700不匹配或者C2800与C28FPU32不匹配!
解决办法:
将编译器下的相关.lib文件剪切到各自工程中,各工程根据自己需要来添加哪些.Lib文件加入:
先删除编译器下相关的.lib文件:
共32页 第12页
CCS5.5使用总结
然后工程中加入自己工程下的Lib文件
工程下的各种cmd/.C/.asm/.lib文件都可以通过直接拖到工程下的方式链接到工程。同时删除属性下的
Lib路径设置:
共32页 第13页
CCS5.5使用总结
再次编译,没有错误:
8
打开已有CCS5.5工程
1 右上角切换到编辑模式
2 Project下打开已有CCS5.5工程:
共32页 第14页
CCS5.5使用总结
3 选择工程名所在路径,并选中工程名:
则自动选中工程了:
共32页 第15页
CCS5.5使用总结
点击finish,则工程打开成功!
9
绝对路径设置(编译程序拷贝或剪切到其它电脑或者盘都可用)
当我们在PC机上新建了一个CCS5.5工程,并且成功编译通过。然后当将该程序剪切到别的盘或者别的电脑
再次打开时发现编译报错:“找不到头文件”
原因很简单:头文件设置用的是绝对路径:"D:DSP_exePGM48_DO_V1.0DSP281x_commoninclude"
共32页 第16页
CCS5.5使用总结
当剪切到E盘或者其它电脑的E盘或者F盘,则“D:DSP_exePGM48_DO_V1.0“已经不复存在,故无法找到
该路径,头文件自然无法找到,解决办法,改为绝对路径:
"....DSP281x_commoninclude"则无论是放到哪里,只会识别本工程下的“DSP281x_commoninclude
“文件夹下的头文件。如图所示(原来创建到D盘,剪切到E盘了):
剪切到C盘编译:
当然库文件的绝对路径不用修改,因为CCS默认安装是C:ti
共32页 第17页
CCS5.5使用总结
10
工程路径定义(不可修改)和源代码链接定义(可修改)
工程安装路径及工程所在路径定义
源代码链接定义(可修改):
11
从CCS3.3移植到CCS5.5的技巧
共32页 第18页
CCS5.5使用总结
1) 创建工程文件夹
首先,需要在电脑某盘下创建相应文件夹如C:PGM48_DO_V1.0_CCSV5PGM48_DO_V1.0_CCSV5,然
后将工程指定到该路径下,这样.cproject等文件都在指定文件夹下,否则工程文件会放得到处
都是,个人感觉这这一步是便于你管理工程文件和存档。
然后,将cmd文件拷贝到该工程文件夹下。
在工程名文件夹同一级下创建common/headers、UserHeader/ UserSource等文件夹。
将原来CCS3.3中的common/headers都拷贝过来,将原来CCS3.3自己设计的头文件和源程序.C文件
分别拷贝到UserHeader/ UserSource下。
将原来CCS3.3中的库文件”Flash2812_API_”拷贝到编译器lib安装路径下
“C:ticcsv5toolscompilerc2000_6.2.0lib”。
自此,原来CCS3.3下的所有类型文件(.C/.h/.cmd/.lib/.asm)文件都已经在工程文件夹下。
2) 将相关源文件、头文件、cmd文件、库文件链接到程序工程中。
.C /.cmd/.asm直接链接到工程中。
共32页 第19页
CCS5.5使用总结
通过单击右键“Add file”
然后选中相应文件:
选中link to project:
则链接完成。
共32页 第20页
CCS5.5使用总结
3) 设置.h和.lib的链接路径(必须是相对路径,如果是绝对路径则程序被剪切到其它位置后编译会
出错)。
头文件链接加入方法
单击右键选中“Properties“打开.在Build/Include Options/下添加你工程所需头文件:
"....DSP281x_commoninclude"
"....DSP281x_headersinclude"
"....UserHeader"
系统自带头文件是自动加入的:
"${CG_TOOL_ROOT}/include"
其中CG_TOOL_ROOT在linked Resource可以找到:
共32页 第21页
CCS5.5使用总结
.lib文件链接加入方法:
在File Search Path下通过"${CG_TOOL_ROOT}/lib"添加进来,前提是”Flash2812_API_ “已经
拷贝到CG_TOOL_ROOT下,否则编译出错,提示找不到FLASH_api系列的函数和变量,无法生成.OUT.
4) 保存工程,开始编译整个工程。
一般会出现,API库版本不兼容的报警,不过不影响编译结果,这个紧紧是因为CCS5.5编译了原来
CCS3.3下的API函数而已,该报警处理方法见报警信息Warning“compatibility cannot be determined”
处理方法。
另外,还会出现堆栈值报警,该报警信息处理见Warning “creating ".stack" section with default
size of 0x400; use the -stack option to change the default size”的处理方法。
12
CCS3.3与CCS5.5异同比较
CCS3.3工程
共32页 第22页
CCS5.5使用总结
CCS5.5
3.3下.lib显示在工程下,并且可以手动增减。5.5必须是路径设置自动查找,并且不显示在工程下。
3.3工程下的文件是分类列出,5.5则没有,但其头文件自动显示了所在位置源头。
3.3的连接目标板和仿真器是通过与CCS独立的SetUP来设置,5.5则集成进来,只需要配置文件Target
Config中将芯片型号和仿真器型号设置好就OK了。
3.3的头文件添加时通过Project下的Build option来设置的:
共32页 第23页
CCS5.5使用总结
而5.5则是通过属性设置的。
3.3头文件设置位置
Include Search Path中设置了绝对路
径:....DSP281x_headersinclude;....DSP281x_commoninclude没有引号
3.3库函数添加:
在Libraries下的Search Path中设置为:....DSP281x_headersinclude
所以即便工程中不含rts2800_,工程编译也不会出错(测试过)。
但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页
CCS5.5使用总结
编译通过会发现DEBUG文件夹下有.lib文件:
将该.LIB文件拷贝到需要调用该LIB库中函数的工程文件夹下,并且链接到该工程文件:
共32页 第28页
CCS5.5使用总结
通过添加头文件调用该函数:
17
工程文件的注释文字出现乱码解决办法
出现乱码时:
共32页 第29页
CCS5.5使用总结
单个源代码的乱码问题:
首先单击右键选择属性:
然后Resource下找到Text file encoding:
最后将UTF-8格式改成GBK格式:
共32页 第30页
CCS5.5使用总结
应用GBK格式后:
如果是整个工程都出现文字乱码则统一修改:
需要注意的是:无论是哪种方式修改必须都是先从上层修改开始,依次到下层:
即工作空间->工程—>源文件
其中工作空间修改的方式如下:
共32页 第31页
CCS5.5使用总结
GBK与UTF-8区别,百度答案:
字符均使用双字节来表示,只不过为区分中文,将其最高位都定成1。
至于UTF-8编码则是用以解决国际上字符的一种多字节编码,它对英文使用8位(即一个字节),中文使用24位(三个字
节)来编码。对于英文字符较多的论坛则用UTF-8节省空间。
GBK包含全部中文字符;UTF-8则包含全世界所有国家需要用到的字符。
GBK是在国家标准GB2312基础上扩容后兼容GB2312的标准(好像还不是国家标准)
UTF-8编码的文字可以在各国各种支持UTF8字符集的浏览器上显示。
比如,如果是UTF8编码,则在外国人的英文IE上也能显示中文,而无需他们下载IE的中文语言支持包。 所以,对于英文比
较多的论坛 ,使用GBK则每个字符占用2个字节,而使用UTF-8英文却只占一个字节。
UTF8是国际编码,它的通用性比较好,外国人也可以浏览论坛,GBK是国家编码,通用性比UTF8差,不过UTF8占用的数
据库比GBK大~
18
编译好的工程拷贝到其它路径下变成出错:“gmake: *** No rule to make ”
原本工程路径如下:
共32页 第32页
CCS5.5使用总结
加载到CCS5.5编译正确通过!
但拷贝一份到其它路径:
编译却出错:
查看头文件设置的都是绝对路径,在工程中也加载进来了,什么原因?
但将工程文件直接拷贝到D或者E盘下编译都没有问题,什么原因?
19
工程文件管理及版本变更方法
共32页 第33页
CCS5.5使用总结
如果对程序要进行版本修订,又要保持一份原版本的,则可通过以下方法实现:
新建一个文件夹“WlCnt_EthDrive”,用于存储所有版本:
将原始老版本V1.0(在CCS5.5下新建工程生成的)拷贝进去,在再次文件夹下将V1.0复制一份命名为
V1.1,同时在CCS5.5下打开后将工程名改为V1.1,否则CCS会任务与原工程同名,编译没有问题!
如果再用V1.1去创建V1.2会发现,V1.2工程链接到V1.1的.C去了,这样在编辑代码时实际是编辑了
V1.1工程下的源代码,所以必须用原本创建!
20
附件
附件1:2812寄存器查询
附件2:MCP2515寄存器查询
附件3:SAE_J1939-71应用层-车辆
附件4:28335寄存器查询
附件5:MCU_DSP_SOFTWARE V1.0
共32页 第34页