在cmd文件中，可以把连续的Flash模块组合为一个整体的区间吗?

　　虽然可用的存储空间看起来比section的长度要大，但是链接器为何提示“placement fails for object”？
　　这种情况一般是因为段的空间的分配是并不是我们想象中的连续的一个紧挨一个，而是被编译器给“分块”管理了。在内存地址分配时，一个段需要完全适配到页（page）中，或者从页的边界开始连续分配;为了满足这个要求，段在分配到页中时，可能无法完全利用某些页，导致内存地址中产生了间隙（hole），使得实际所需要的内存空间超过了根据变量大小计算出来的理论值。编译器这样做的目的是为了优化数据页（DP）寄存器的加载，达到减小代码尺寸和优化程序性能的目的。例如，针对一个数组，如果数组的长度小于64字（words），则编译器仅需安全地加载DP一次就可以访问数组的全部元素;如果数组长度大于64字，则在访问每64字的数组元素时，编译器仅需加载一次DP，当然如果访问多个64字的数组元素则仍需要多次加载DP。
　　举例说明：
　　在cmd里定义：
　　RAMM1 ： origin = 0x000400， length = 0x000400 /* on-chip RAM block M1 */
　　commbuf ： 》 RAMM1 PAGE = 1
　　在main.c里定义以下几个变量
　　#pragma DATA_SECTION（sendT， “commbuf”）
　　Uint16 sendT;
　　#pragma DATA_SECTION（receT， “commbuf”）
　　Uint16 receT;
　　#pragma DATA_SECTION（CntPPR， “commbuf”）
　　Uint32 CntPPR;
　　表面上共需260+260+250*2=1020，commbuf正好放得下。但ccs提示空间不够：
　　（run placement fails for object “commbuf”， size 0x474 （page 1）。
　　Available ranges： RAMM1 size： 0x400 unused： 0x400 max hole： 0x400）
　　产生错误的原因是根据DP加载的原则，page被划分为64word的小单元，而数组被存储在连续的、整块的单元上，未使用到的空间不会再分配给其它数组或者变量使用。所以16位260长度的数组实际占用了64*5=320 （64*4=256《260），32位500的长度实际占用了64*8=512，占用的总长度为：320*2+512=1152=0x480。
　　按照CCS的提示，commbuf占用空间是320*2+500=1140=0x474，但是事实上32位数组占据的最后那个page已经无法被别的变量使用了，所以如果还有新的变量出现的话，会提示RAMM1块缺少的地址更多。
　　根据我们的需要，可以在每次之间内存读取操作之前都加载DP，这样就可以禁用上面的“分块”管理特性了。这样做虽然可以减小内存地址空间中的“间隙”，但是每一次访问内存都需要加载DP，反而大大地增加了代码的尺寸，实在是得不偿失（看起来很少有人会这么做）。我们可以通过启用编译器的-disable_dp_load_opt，或者叫-md选项来实现这一方法。
　　确认某个段是否被编译器给分块管理的方法就是使用.bss和.usect指令。

　　链接器提示“placement fails for object ‘.text’”，我们如何为.text分配更多的内存？
　　.text段中包含包含所有可执行的代码，以及编译器编译产生的常量。如果我们的代码比较大，超过了cmd文件中默认分配的空间，则.text无法适配到内存空间中，就会产生上面的错误。通常有三种方法可以来为其分配更多的空间。
　　方法一：修改cmd
　　方法二：分割.text，把它平均分配到多个内存区域中
　　这个方法比较直观，前提是几个内存区域的总长度要满足要求。例如：
　　.text ： 》》 FLASHA | FLASHC | FLASHD， PAGE = 0
　　方法三：完整分割法
　　这个名字有点古怪，它本质仍然是把.text分割，目标区域也可以有多个，但是当第一个区域就满足要求时，则只把它分配到第一个区域中，剩余的目前区域实际上未被使用到。
　　在实际编程实现时，这些方法仍然存在一定的限制，包括：
　　1. 在包含控制律加速器CLA 的Piccolo器件中，只有特定的内存区域可被CLA所使用。
　　2. 在含有DMA的器件中，并不是所有的内存都可被DMA所访问。
　　3. 一般情况下，SRAM都是单个机器周期内只能访问一次，但是0等待状态的。但在一些器件中，程序内存控制是包含等待状态的，例如在某些2833x器件中，DMA可访问的数据空间是0等待状态的，但是程序控制是1等待状态的。这些SRAM空间更适合纯数据访问类型的使用。

　　在cmd文件中，可以把连续的Flash模块组合为一个整体的区间吗？
　　答案是可以的。在Flash的烧写中，可以在同一时间被烧写的Flash的最小长度被称为扇区（sector），所以通过把我们的代码进行分区烧写，就可以把它们对齐到扇区。
　　Flash模块结合的方法一：直接合并法
　　以把两个Flash扇区组和为一个段为例：
　　合并前，两个扇区的定义是：
　　MEMORY
　　{
　　//
　　// Individual sectors E and F called out in the MEMORY description
　　//
　　。..
　　FLASHF ： origin = 0x310000， length = 0x008000 /* on-chip FLASH */
　　FLASHE ： origin = 0x318000， length = 0x008000 /* on-chip FLASH */
　　。..
　　}
　　合并之后的Flash区间为：
　　MEMORY
　　{
　　//
　　// Sectors E and F merged into one in the MEMORY description
　　//
　　。..
　　FLASH ： origin = 0x310000， length = 0x010000 /* on-chip FLASH F & FLASH E */
　　。..
　　}
　　方法二：反其道行之，把段分配到多个Flash模块中，与问答36的方法二是一致的，例如：
　　SECTIONS
　　{
　　.text： { *（.text） } 》》 FLASHE| FLASHH
　　}

　　在cmd文件中，可以把相邻的SARAM模块组合为一个整体的区间吗？
　　答案是可以的，方法与Flash组合的方法一样。
　　虽然这样做是完全没有问题的，但需要牢记SARAM模块都是单个机器周期内只能访问一次的，所以为了优化程序的性能，最好把代码给分区到不同的物理SARAM模块中，这样可以减少大量读/写操作中的资源冲突。

　　对于DSP/BIOS的工程，如何了解链接的信息？
　　DSP/BIOS 的配置工具生成一个cmd文件，规定如何连接所有 DSP/BIOS 生成的程序段，并且默认链接至所有 C/C++ 语言编译程序生成的程序段。 当从 RAM 运行程序时，可能只需要这一个cmd文件就够了。但在当从Flash中执行时，很有可能需要生成且连接一个或多个自定义的程序段。
　　此外，任何配置片载Flash控制寄存器（例如，Flash等待状态）的代码不能从Flash执行。我们也许需要从 RAM（而非Flash）中运行特定时间关键函数来大幅提升性能。 必须创建一个自定义cmd来处理这些我们定义的程序段。可以参考Running an Application from Internal Flash Memory on the TMS320F28xx DSP这个文档，其示例代码在http://www.ti.com/general/docs/lit/getliterature.tsp？baseLiteratureNumber=spra958&fileType=zip。
　　需要注意的是，这些文档和程序与新版本的CCS中所包含SYS/BIOS并不是完全兼容的。此外，如果我们想使用第三方的操作系统，例如VxWorks、us/OS、INTEGRITY等，则要根据这些RTOS的特点进行内存的分配与管理。