本系列文章链接

  因为最近开始接手实验室的DSP开发相关的工作，所以也是刚开始学习使用相关的工具，顺便做了一些记录。本篇文章主要介绍一些初期的准备工作，包括CCS的版本选择、CSL静态库的编译，目的是能够无误地编译例程，为后续的开发做准备。

环境搭建

  首先我们只需要有编译器就行。Code Composer Studio（CCS）是专门用于开发TI的处理器的集成开发环境（IDE），IDE能够帮助我们更加方便地调试，虽然重要但不是必要的。
  TI的编译器有很多种，针对不同的设备有ARM Compiler、C2000 Compiler、C6000 Compiler等等，不同的Compiler又有不同的版本号，所以选择非常多，但一定要选合适的。C6455需要用的是C6000 Compiler，我之前因为一些问题就采用了老版本的CCS，但实际上可以直接采用最新的，官方也建议采用最新版本的CCS。主要问题有以下两点：

  • 从CCS v7.0 开始，C6000 v7 Compiler已经不再默认包含在CCS的安装包中，需要之后手动添加。而目前最新的C6000 v8以及以后的Compiler已经不再支持对C6455。（我就是因为这个原因，一开始用的是CCS v6.2.0，但其实另外加C6000 v7的Compiler也不麻烦）
  • CCS v5.5 之后也不再支持在线仿真，调试程序都需要接仿真器。（这个其实在实际调试过程中也用不太到，如果真的要用这个功能也可以从老版本移植，网上有相关的教程）

  因此CCS的版本选最新的就行，我目前所用的是CCS v10.2.0。各个版本的CCS下载链接， 如果链接失效了也可以直接去TI官网搜索下载。（之前用CCS v6.2.0 连license都还需要额外下载ORZ）

芯片支持库（CSL）

  C6455的芯片支持库是一个测试版本，在与C6455相关的开发工具中可以找到这个“C6455 芯片支持库 - Beta”，里面提供了对外设的一些基本操作的API，减轻了从头开始写写驱动的繁琐工作。
下载得到的文件中有两个文档：

  • C6455_CSL_APIREFERENCE.pdf
  • Releasenotes_C6455_v3_00_10_02.pdf

  第一个文档中介绍了CSL中的一些结构体、宏定义和一些节本的函数，这个文档我很少看，之后在工程中看更加直观；第二个文档是一些说明，包括几个文件夹中的内容和一些修订记录。
  第二个文档是2006年写的，用的CCS版本是CCS v3.3，读着有种在考古的感觉。

一些准备

  让一个例程无误地编译通过是一切的开始。
  首次打开CCS v10.2.0需要安装 C6000 v7 Compiler，可以通过点击以下方式安装

  C6000 v7.4.24在2018年2月23日发布，之后也不会有更新的v7版本了，这也是我所认为的最合适的编译器。

导入例程

  导入例程之前可以先介绍一些workspace的概念，CCS也是基于Eclipse的IDE，同样的还有Xilix的Vitis（过去的SDK）。它们都可以用一个workspace来同时管理多个Project，在不同的Project之间可以灵活地切换，非常方便。特别是之后用源码编译CSL的静态库之后，在调试过程中想看源码就可以切换到用来编译库的工程中进行查看。
  CSL的例程就在“csl_c6455”和“csl_c64xplus_intc”下的“example”中，可以在不同模块的例程文件夹中的“build”目录下找到后缀为“.pjt”的工程文件，用于后续的工程导入。
导入例程的方法如下：

问题1

  导入完成后进行编译，会遇到第一个问题，就是：

Product XDAIS v1.0.0 is not currently installed and no compatible version is available.
Please install this product or a compatible version.

  这是因为原先的工程包含的XDAIS v1.0.0找不到了。XDAIS的全称是eXpress DSP Algorithm Interoperability Standard，大概是一种和算法相关的标准。而且我们也没用到，其实可以直接不要它，在工程的属性中Remove即可。

问题2

  虽然下载的文件中有提供编译完成的静态库，但如果直接用到我们现在的工程中，它会有很多警告，类似这种：

#16002-D build attribute vendor section TI missing in “xxx.o” …

  原因是编译库的编译器和现在的用来编译的编译器不同，这个warning大概率不会影响程序的正常功能，网上有些方法是直接在工程选项中把这个warning屏蔽（treat diagnostic ID as remark），但是我们还是应该争取优雅地解决这个问题——重新编译库。

重新编译CSL库

  其实本来是一件很简单的事，但我傻了折腾了很久。文档“Releasenotes_C6455_v3_00_10_02.pdf”中的第7页的“Build guidelines”介绍了如何编译库，非常详细。如果你同样用的也是CCS v3.3，那么也可以按照上面的每个步骤完成编译。两个源码文件夹“csl_c6455_src”和“csl_c64xplus_intc_src”中都有写好了的Makefile，而且也把gmake的参数都写到了对应的批处理文件中，只要命令行执行一下就行。
  但最关键的是第一步，要在命令提示符下运行“DosRun.bat”，现在的CCS已经没有这一功能了。所以即使设置了正确的gmake路径的环境变量，也没办法通过批处理文件编译静态库了。我也尝试了很久想用现有的Makefile来编译库，最后还是失败了，要编译还是需要通过CCS来进行。而且这样其实更好，之后在workspace下可以一直存放着编译库的工程，在需要的时候还可以查看源码。
  其实编译CSL库也不是必须的，我也见过一些人把CSL的源码文件直接放到自己的工程里，虽然第一次编译工程会有点慢，但后面因为增量编译，只要修改不大，编译器来也很快，也很方便，看库的源码甚至更加方便了。但这一般不推荐，CSL库本就是想提高抽象层次，减少用户对底层的接触，用户只需要知道函数的功能，而不需要去看源码，除非是像我这样的初学者为了学习。而且用户可以在CSL的基础上写一个更加上层的驱动，进一步提高开发的效率。

创建工程

  在Project菜单栏下选择“New CCS Project…”

  官方提供的四个lib文件如下面的表格所示。我们为了重新编译得到这几个库文件，可以新建和它们相同的工程名，如上图工程名为“csl_c6455”对应大部分外设的小端模式的静态库。下面的“Project templates and examples” 选择空白的工程即可。

大小端 大部分外设 中断控制器
小端模式 (little endian) csl_c6455.lib csl_c64xplus_intc.lib
大端模式（big endian） csl_c6455e.lib csl_c64xplus_intce.lib

  然后把csl_c6455_src路径下的“src”和“inc”两个文件夹都复制到新建的库工程路径下。这个工程的文件我们就都准备好啦！

工程设置

  在Project Explorer下选中新建的csl_c6455的工程，可以右键选择“Properties”，或者按快捷键“Alt”+“Enter”来编辑工程的属性。
  第一步先把工程的配置改为“Release”模式。顾名思义，“Debug”模式是用来调试的，而“Release”是用来最终发布的，我们现在的源代码不需要调试，只要编译得到最后的库文件就行。

  从上面的图里也可以看到，其实CCS实际上调用的还是gmake，gmake通过Makefile指定了各个目标文件之间的依赖关系、编译顺序和实际调用C6000 Compier的命令。
  在开始编译之前还需要设置编译器的“Include Option”，把工程路径下的“inc”文件夹包含进来，这样才能找到头文件。

  然后就可以进行编译了，编译之后可能还会有一些warning，比如“CSL_bwmngmtGetBaseAddress”这个函数没有显式的声明，在“csl_bwmngmt.h”中加上它的声明即可（也有可能这个函数本身就不想让用户调用所以没有在头文件中声明，但不管怎样加个声明也不会有影响）；还有一些函数比如“malloc”和“free”，它们包含在“stdlib.h”的头文件中，需要在加上相应的“#include”。
  在“Release”文件夹下，我们得到了编译得到的库文件，要编译剩下其他三个库文件也是一样的方法，就不再赘述。除了编译得到的库文件以外，我们还能看到由CCS自动生成的Makefile文件，把它们和CSL库的源码自带的Makefile对比，其实还是有挺大区别的，虽然我们有时候可以直接通过命令调用编译器，但那只能用于小工程，如果工程比较大，Makefile就有优势了，这是用CCS进行开发不可替代的地方。
  我们得到的静态库“csl_c6455.lib”文件中包含的就是由源码编译得到的目标文件，用户只需要有“.h”头文件，链接器就能够将这些库中的所需的目标文件链接起来得到最后的输出文件。根据这个特点，我们需要对工程中的“include options”和链接器的“file search path”做相应的设置就可以在例程乃至于之后的工程中方便地使用。