CMD 文件的原理

2019-07-27 17:51发布

CMD 文件的起源
在 DSP 系统中,存在大量的、各式各样的存储器,CMD 文件所描述的,就是开发工程师对物理存储器的管理、分配和使用情况。

有必要先复习一下存储器的知识。目前的物理存储器,种类繁多,原理、功能、参数、速度各不相同,有 PROM、EPROM、EEPROM、FLASH、NAND FLASH、NOR FLASH等(ROM 类),还有 SRAM、DRAM、SDRAM、DDR、DDR2、FIFO 等(RAM 类)。无论多么复杂,从断电后保存数据的能力来看,只有两类:断电后仍然能够保存数据的叫做非易失性存储器(non-volatile,本文称为 ROM 类),数据丢失的叫做易失性存储器(本文
称为 RAM 类);ROM 类的芯片都是非易失性的,而 RAM 类都是易失性的。即使同为 ROM类或同为 RAM 类存储器,仍然存在速度、读写方法、功耗、成本等诸多方面的差别。比如 SRAM 的读写速度,从过去的 15ns、12ns,提高到现在的 8ns、10ns,FLASH 的读取速度从 120ns、75ns,到现在的 40ns、30ns。

有没有人这样想过:使用存储器的人,希望存在这样的区别吗?
或者说,理想的存储器,应当是什么样的?
…………
我们使用存储器时,如果没有人为地改变它,就希望里面的数据永远不要变,即使断了电也要完好地保存;如果里面的内容是我不需要的或者不能用的,我自然就会给它写入有用的内容,比如初始化。理想的存储器就应当永远保存数据,无论掉电与否,而且,希望读写速度为每秒无穷多字节,是 0ns,而不是什么 8ns,10ns。——不是吗?

然而,人类实现存储器芯片的技术,还没有达到理想情况,所以才会有这么多类别。“非易失”和“速度”就是一对典型的矛盾。非易失的 ROM 类存储器,可以“永远”地保存数据,但读写速度却很低,比如 30ns;RAM 的速度(8ns)一般都比 ROM(30ns)快得多,但却不能掉电保存。这是很无奈的现实。假如有那么一天,ROM 类的读写速度和 RAM 一样快,或者 RAM 也可以掉电保存数据,就不存在易失和非易失的区别了,那将是革命性的进步。那时,智能芯片和智能系统的设计将会有很大的变化,编写 CMD 文件就会很简单,甚至不需要了。

已经有芯片厂家做了一些这方面的工作,比如把电池和 RAM 结合起来,就是一个能掉电保存的 RAM。它既可以作为传统的 ROM 使用,又可以当 RAM 使用。但这显然只是一个暂时、折中的方法,其原理、成本、体积、容量还不如人意,不能算是“革命性”的进步。

我们平时在用到存储器的时候,要考虑哪些因素呢?

首先必须确认,在你的使用场合,是要永久保存数据,还是暂时保存?这关系到选择非易失性,还是易失性存储器的大问题,是首要的问题。在某些场合,如果必须永远地保存数据,即使希望速度快一些,也只能选择非易失的 ROM 类存储器,而把速度问题放在其次,或者另外想办法解决;另外一些场合,却要把速度放在第一位,只要在通电期间能够始终保存数据,就够了,当然就要选择 RAM 类的存储器了。

这两种情况我们都会遇到:程序代码一般都要存储在 ROM 类存储器中,否则,从设备生产开始,储存、运输,一直到用户手里,要必备不间断电源,还要保证不发生断电的意外;程序运行的时候,为了提高速度,就必须在 RAM 中运行,试想想,如果你的 MP4放电影一停一顿的,谁还会用它看电影呢?所以 ROM 和 RAM 都是必不可少的,各有各的用途,而且,出于功能、参数、速度、读写方法、功耗、工艺、成本等方面的考虑,往往要同时使用不止一种存储器。

事实上,TI 在设计 DSP 芯片时,也遇到同样的问题,TI 考虑的情况要比我们更多,更复杂。要知道,设计芯片的人是最牛 X 的,开发工程师只是跟在人家后面,在人家规定的框框里亦步亦趋。翻开 DSP 的 PDF 文档,找到 memory map 就会看到,芯片上集成了形形 {MOD} {MOD}的存储器: FLASH、ROM、BROM、OTP ROM,SRAM、SARAM、DARAM、FIFO 等。就 2407 和 2812 而言,如果是做个流水灯之类的小东东,DSP 芯片加晶体加电源就可以了,片上集成的 ROM 和 RAM,在仿真状态下已经足够用了,烧写并脱离仿真器运行也足够。所以,它们的最小系统不需要外扩任何存储器。但也只能做简单的东东,往往还需要外扩一些 ROM  和/或 RAM 存储器,才能委以大用。(顺便说一句,DSP 的最小系统,要比 8951 芯片的最小系统大得多。)

千万不要被这些存储器的名称所迷惑!翻来覆去,其实就是两大类:非易失和易失。初学者往往忽略了这一点。

两大类!记住这一点,CMD 文件就是以这两类存储器为主轴,然后展开的。

DSP芯片的片内存储器,只要没有被TI占用,用户都可以全权支配。TI设计了“CMD文件”这种与用户的接口形式,用户通过编写 CMD 文件,来管理、分配系统中的所有物理存储器和地址空间。CMD 文件其实就是用户的“声明”,包括两方面的内容:
1、用户声明的整个系统里的存储器资源。无论是 DSP 芯片自带的,还是用户外扩的,凡是可以使用的、需要用到的存储器和空间,用户都要一一声明出来:有哪些存储器,它们的位置和大小。如果有些资源根本用不到,可以视为不存在,不必列出来;列出来也无所谓。
2、用户如何分配这些存储器资源,即关于资源分配情况的声明。用户根据自己的需要,结合芯片的要求,把各种数据分配到适当种类、适当特点、适当长度的存储器区域,这是编写 CMD 文件的重点。

用户编写完自己的程序以后,要经过开发环境(编译器)的安排和解释(即编译),转换为芯片可以识别的机器码,最后下载到芯片中运行。CMD 文件就是在编译源程序、生成机器码的过程中,发挥作用的,它作为用户的命令或要求,交给开发环境(编译器)去执行:就这么分配!

友情提示: 此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。
5条回答
tianli1980
2019-07-28 02:21
编写 CMD 文件之——资源分配
系统资源已经声明完了,现在就要说明,用户是如何分配这些存储器资源的,即向编译器声明资源的分配情况。
要合理地分配存储器资源,首先要搞清一个问题:资源要分配给谁?有哪些东东需要占用存储器?
我们来看下面这段不严格的 C 程序:
main()
{
unsigned  int  i;
i ++;
}

这“段”程序只是笔者建立的一个模型,用它来代表几乎所有的程序:哪怕变量(包括数组)有一千个、一万个,都用一个“i”来代表;哪怕程序主体包含了各种搬移、运算、逻辑等动作,哪怕有一万行那么长,都用一“i++”来表示。让我们站在 TI 公司和编译器的角度,来考虑下面的问题:程序经过编译以后,会产生哪些对存储器资源有要求的“状况”?有单片机开发经验的人都知道,至少要产生两种情况:

1、指令码,即二进制形式的指令,需要占用芯片的“程序空间”。这些数据,完全等价于或等同于用户编写的程序,只是转换成了另一种形式而已。这种“数据”有两个特点:a、只要用户程序编写完成,这些“数据”就已经是可知的、可预期的,是由用户编写的程序代码和编译器共同决定的。b、在系统运行过程中,这些数据的内容不会发生任何变化,只会被读取,不会被修改。

2、在运行过程中,动态变化的“量”,需要占用“数据空间”。上面例子程序中的变量 i,就属于这种情况。这些数据,在设计师编写程序的时候,有时会预先写入具体的数值,即初始化,有时甚至根本不需要进行初始化。在运行过程中,既要被读取,又会被改写,经常在变化。设计师自己也很难确切知道,在某一时刻,这些数据的具体的数值是什么,最多只知道它们的位数、最大和最小值的范围。

那么,什么样的物理存储器适合于数据空间使用,什么样的存储器适合于程序空间使用呢?对于数据空间,其最基本、最首要的要求是速度快,并不要求掉电保存数据的能力,显然应当由 RAM 类存储器来承担,所以,RAM 一般都必不可少。但是,并不是说数据空间只能连接 RAM 芯片,只要你能够接受比较慢的速度,并且安排好芯片的控制时序,你完全可以在数据空间扩展 ROM 类存储器。

程序空间的代码数据,一般都要求掉电保存,只能由 ROM 来承担,所以 ROM 必不可少。那么,ROM 的读取速度慢的问题,怎么解决呢?对于有些低速的智能芯片,ROM的速度慢一点,是完全可以接受的,可以直接从ROM 中读取代码指令,然后译码、执行;我们熟悉的 MCS51、PIC 系列单片机,都是这么做的(以下信息笔者不能保证正确性:2407 脱离仿真器运行时,似乎也是直接从 ROM 中读取程序代码)。另外有一些低端的智能芯片,生产商通过特殊的技术手段,在一定范围内等效地提高内部程序 ROM 的读取速度,比如 NXP 公司的 ARM 芯片 LPC213x,虽然 ARM 内核的数据接口只有 32 位,但LPC213x 的片内 FLASH 程序存储器,与内核之间的接口居然是 128 位宽度,通过所谓“加速器”相连接。对于高速的智能芯片,从 ROM 直接读取代码并执行,已经不能满足速度的要求了,通常的解决方法是,把程序代码储存在 ROM 中,在每次上电运行时,通过“引导程序”把用户代码读出并保存在 RAM 中,然后从 RAM 中运行,这样做既解决了 ROM速度慢的问题,又解决了 RAM 掉电丢失数据的问题。

实际操作中,并不是只有指令码和变量 i 这么简单,除这两项以外,还会出现很多小“状况”;而且,当芯片型号不同,甚至用户源程序不同时,出现的细节也是变化的。恰恰就是这些变化,导致 CMD 文件变得复杂。但是,任何大“状况”、小“状况”,都归属于对程序空间和数据空间的操作,不存在第三种空间。(有些 DSP 的所谓“IO 空间”,实质上是数据空间的一个变种,但又脱离了数据空间,不属于 CMD 文件考虑的范围。)编写 CMD 文件,就是要搞清楚以下情况,并对编译器做出声明:1、你的系统都有哪些存储器资源?2、哪些存储器安排在程序空间,哪些在数据空间?3、你的系统会产生哪些大“状况”和小“状况”?4、哪些状况属于程序空间,哪些属于数据空间?5、程序空间的“状况”如何安排在程序空间的资源里,数据空间的“状况”如何安排在数据空间的资源里?

一周热门 更多>