有些CCS工程中为什么会有两个CMD文件？

　　这里的ccs就是ti公司的code composer studio 集成开发环境，所以这篇随笔也就是关于ti公司dsp开发过程中对于刚入门同学的一个常见问题了。

　　那作为一个初学者，对于ccs工程中的cmd文件首先应该是有些基础了解的，下面做一个简单的介绍：

　　.cmd 的专业名称叫链接器配置文件，是存放链接器的配置信息----给出了程序空间和数据空间的设置，及编译后各程序段在程序或数据空间的具体位置。一般情况下该文件主体部分为两个伪指令，　　　　　　memory和sections。memory用来配置目标存储器，sections用来指定段的存放位置。例如下面的格式：

memory
{
page 0 :  /* program memory */

　　.......

page 1 :

　　......

}

sections
{
 /* allocate program areas: */
 .cinit   : > flashf  page = 0, align(8)
 .pinit   : > flashf  page = 0, align(8)
 .text   : > flashg   page = 0, align(8)

......

}

限于篇幅，这里就不展开讲cmd文件里面内容的具体含义和语法了，可以参考另一篇博文。。。。。。

　　这里重点讲一讲，为什么ccs工程里面会有两个cmd文件，它们之间是什么关系？

　　可能有些同学已经想到了，既然是链接器配置文件，对于一个工程来讲，只要告诉链接器具体的配置内容，那么链接器就可以知道怎么处理编译后的二进制文件，用一个cmd文件完全可以做到。

　　这样就很好理解，ccs工程里面的两个cmd文件其实是一分为二的关系，也就是说，这些ccs工程里面，把一个cmd文件分成了两个部分，分别解释不同的部分该怎么去配置处理。

　　那么问题又来了，为什么要把一个cmd文件分成两个呢？　

　　实际上，（推测是基于便于管理的角度）ti把它分开了，一个对寄存器进行存储映射，因为同个系列的芯片寄存器都是一样的，这样一个cmd文件在该系列芯片的工程里都是可以通用的。

　　另外一个是对flash, ram进行存储分配，同个系列不同芯片有不同存储配置，所以他们的cmd也不一样。

　　例如2837xs系列芯片的不同芯片ram/rom配置如下表：

　　

　　从上面可以看到，根据不同的需要，芯片的ram和rom(flash)有多有少，那么在cmd文件中也要针对性的调整，否则可能编译出来的文件无法正确烧写或者执行。

　　另外一个，顺便提一句的。在同一个芯片系列中相同的cmd文件，主要存放芯片寄存器地址信息，同学们会看到，在这个cmd文件中memory指令中只有page1的内容，就像下面这样：

　　为什么呢？这是因为，ti公司默认在memory把page0作为程序储存器，page1作为数据储存器进行分配，分别有数据总线和程序总线进行访问。那么，所有芯片寄存器都属于数据空间，所以放在page1，因此这个cmd文件里就只有page1的内容了。