DSP28335工程文件 .cmd 作用
2015-10-01 21:31
351 查看
在DSP28335工程文件里(不用BIOS产生CMD文件),手写CMD文件一般有两个,在RAM里调试时用的两个CMD文件分别为DSP2833x_Headers_nonBIOS.cmd和28335_RAM_lnk.cmd,烧写到flash里时用的两个CMD文件分别为DSP2833x_Headers_nonBIOS.cmd和F28335.cmd,其中DSP2833x_Headers_nonBIOS.cmd文件可以在所有工程文件中通用,主要作用是把外设寄存器产生的数据段映射到对应的存储空间,可以跟DSP2833x_GlobalVariableDefs.c文件对照一下看看。下面通过一个简单例子,比如向CpuTimer0Regs.
TIM.all写数据,来解读一下CMD文件是如何把寄存器里的值准确映射到所在存储器的位置的。
先在DSP2833x_GlobalVariableDefs.c文件里找到以下几行代码:
#ifdef __cplusplus
#pragma DATA_SECTION("CpuTimer0RegsFile")
#else
#pragma DATA_SECTION(CpuTimer0Regs,"CpuTimer0RegsFile");
#endif
volatile struct CPUTIMER_REGS CpuTimer0Regs;
由上可知CpuTimer0Regs是一个结构体变量名(其定义在DSP2833x_CpuTimers.c文件里),通过预处理命令#pragma 为这个结构体定义了一个名称为CpuTimer0RegsFile的数据段。
接着在DSP2833x_Headers_nonBIOS.cmd文件里找到如下代码:
SECTIONS
{
DevEmuRegsFile : > DEV_EMU, PAGE = 1
FlashRegsFile : > FLASH_REGS, PAGE = 1
CsmRegsFile : > CSM, PAGE = 1
AdcMirrorFile : > ADC_MIRROR, PAGE = 1
4000
XintfRegsFile : > XINTF, PAGE = 1
CpuTimer0RegsFile : > CPU_TIMER0, PAGE = 1
......
}
红字体代码的作用就是,通过SECTIONS伪指令把CpuTimer0RegsFile数据段装载到名称为CPU_TIMER0的存储空间。
同样在DSP2833x_Headers_nonBIOS.cmd文件里找到如下代码:
MEMORY
{
PAGE 0:
PAGE 1:
DEV_EMU : origin = 0x000880, length = 0x000180
FLASH_REGS : origin = 0x000A80, length = 0x000060
CSM : origin = 0x000AE0, length = 0x000010
ADC_MIRROR : origin = 0x000B00, length = 0x000010
XINTF : origin = 0x000B20,
length = 0x000020
CPU_TIMER0 : origin = 0x000C00, length = 0x000008
......
}
CPU_TIMER0存储空间通过MEMORY伪指令指示了其起始地址和长度,也就等于间接确定了结构体CpuTimer0Regs的具体位置,所以通过以上几层映射关系,当向CpuTimer0Regs.
TIM.all写数据时就可以准确的写入DSP内部寄存器所在的存储器的位置。由此看见,CMD的作用就是为程序代码和数据分配存储空间。本节先针对DSP2833x_Headers_nonBIOS.cmd文件做一下解读,后续再分别解读一下CMD用于调试和烧写时需要注意哪些问题。
TIM.all写数据,来解读一下CMD文件是如何把寄存器里的值准确映射到所在存储器的位置的。
先在DSP2833x_GlobalVariableDefs.c文件里找到以下几行代码:
#ifdef __cplusplus
#pragma DATA_SECTION("CpuTimer0RegsFile")
#else
#pragma DATA_SECTION(CpuTimer0Regs,"CpuTimer0RegsFile");
#endif
volatile struct CPUTIMER_REGS CpuTimer0Regs;
由上可知CpuTimer0Regs是一个结构体变量名(其定义在DSP2833x_CpuTimers.c文件里),通过预处理命令#pragma 为这个结构体定义了一个名称为CpuTimer0RegsFile的数据段。
接着在DSP2833x_Headers_nonBIOS.cmd文件里找到如下代码:
SECTIONS
{
DevEmuRegsFile : > DEV_EMU, PAGE = 1
FlashRegsFile : > FLASH_REGS, PAGE = 1
CsmRegsFile : > CSM, PAGE = 1
AdcMirrorFile : > ADC_MIRROR, PAGE = 1
4000
XintfRegsFile : > XINTF, PAGE = 1
CpuTimer0RegsFile : > CPU_TIMER0, PAGE = 1
......
}
红字体代码的作用就是,通过SECTIONS伪指令把CpuTimer0RegsFile数据段装载到名称为CPU_TIMER0的存储空间。
同样在DSP2833x_Headers_nonBIOS.cmd文件里找到如下代码:
MEMORY
{
PAGE 0:
PAGE 1:
DEV_EMU : origin = 0x000880, length = 0x000180
FLASH_REGS : origin = 0x000A80, length = 0x000060
CSM : origin = 0x000AE0, length = 0x000010
ADC_MIRROR : origin = 0x000B00, length = 0x000010
XINTF : origin = 0x000B20,
length = 0x000020
CPU_TIMER0 : origin = 0x000C00, length = 0x000008
......
}
CPU_TIMER0存储空间通过MEMORY伪指令指示了其起始地址和长度,也就等于间接确定了结构体CpuTimer0Regs的具体位置,所以通过以上几层映射关系,当向CpuTimer0Regs.
TIM.all写数据时就可以准确的写入DSP内部寄存器所在的存储器的位置。由此看见,CMD的作用就是为程序代码和数据分配存储空间。本节先针对DSP2833x_Headers_nonBIOS.cmd文件做一下解读,后续再分别解读一下CMD用于调试和烧写时需要注意哪些问题。
相关文章推荐
- CentOS 使用yum 安装软件失败
- [Leetcode]Spiral Matrix II
- mysql(索引)
- 常见字符串操作函数内部实现(二)
- MVC使用Entity Framework更新数据库时出现手工添加的校验信息丢失的解决方法使用partial类
- 记录并通过邮件上传App崩溃日志
- CSS实现背景透明,文字不透明,兼容所有浏览器
- Python核心编程笔记 - 第13章 面向对象编程(二)
- Java日期操作(包含Java8)
- 第一层第二题:贪婪的礼物赠送者
- Centos VPS 创建多个网站 二
- HDU5489 Removed Interval LIS
- 实体框架
- 短信智能输入 Trie POJ 1451 T9
- 如何巧妙应对压力面试
- Linux下配置QT环境
- 需要插入子集的时候如何更新父级ID
- 正则表达式
- Hadoop学习笔记(三)Linux环境配置
- JAVA基础--db20_java转换流_file对象&GUI