智能车制作

 找回密码
 注册

扫一扫,访问微社区

查看: 3661|回复: 1
打印 上一主题 下一主题

用CODEWARRIOR碰到的一些疑问

[复制链接]

0

主题

1

帖子

0

精华

中级会员

Rank: 3Rank: 3

积分
328
威望
238
贡献
66
兑换币
44
注册时间
2009-2-10
在线时间
12 小时
跳转到指定楼层
1#
发表于 2009-2-20 18:29:22 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
大家好,我在建工程的时候碰到以下问题:
1. 当不用监控程序时:“另外还需要对于工程文件中 Start12.c中函数 :
void __interrupt 0 _Startup(void) 中

#ifdef _HCS12_SERIALMON
___INITRG = 0x00;  /* lock registers block to 0x0000 */
   ___INITRM = 0x39;  /* lock Ram to end at 0x3FFF */
   ___INITEE = 0x09;  /* lock EEPROM block to end at 0x0fff */  
#endif
两句宏命令注释掉,使得其中的对于EEPROM,RAM起始位置控制寄存器初始化语句有效。这样,下载后程序可以运行正常。”以上这句话摘自清华大学写的一篇文章,另网上一篇文章又说把Start12.c中
#ifdef _HCS12_SERIALMON
      /* for Monitor based software remap the RAM & EEPROM to adhere
         to EB386. Edit RAM and EEPROM sections in PRM file to match these. */
#define ___INITRM      (*(volatile unsigned char *) 0x0010)
#define ___INITRG      (*(volatile unsigned char *) 0x0011)
#define ___INITEE      (*(volatile unsigned char *) 0x0012)
#endif的宏去掉,可是我查看其他例程发现他们都没有把以上宏注释掉,非监控模式用BDM下载程序照样可以跑,不知道原因在哪里?

2.prm 文件默认MC9S12DG128 的RAM 在:
     RAM = READ_WRITE 0x0400 TO 0x1FFF;
在这一空间有 1K 的I/O 寄存器空间 和2K EEPROM 空间。使用默认定义会丢失1K RAM 和 2K EEPROM。

这个默认区间必须修改吗?比如修改成RAM = READ_WRITE 0x2000 TO 0x3FFF;或RAM = READ_WRITE 0x1000 TO 0x2FFF?
如果一定有必要修改,可是为什么许多例程当中还是用的是默认的RAM定义。
3.假设我把RAM = READ_WRITE 0x0400 TO 0x1FFF修改成了RAM = READ_WRITE 0x1000 TO 0x2FFF,INITRM这个寄存器的值应该要设置成和RAM = READ_WRITE 0x1000 TO 0x2FFF相匹配吧。小弟刚入门,忘大侠们多多指教。谢谢了。

14

主题

929

帖子

1

精华

功勋会员

WJ

Rank: 10Rank: 10Rank: 10

积分
6304

特殊贡献奖章

威望
1456
贡献
4674
兑换币
17
注册时间
2008-4-6
在线时间
87 小时
2#
发表于 2009-2-21 09:40:18 | 只看该作者
___INITRG = 0x00;  /* lock registers block to 0x0000 */
   ___INITRM = 0x39;  /* lock Ram to end at 0x3FFF */
   ___INITEE = 0x09;  /* lock EEPROM block to end at 0x0fff */  
这三个是设置RAM EEPROM 映射区的.registers block 是存放和单片机硬件寄存器相关的信息.
你若用监控,那么监控程序要置入FLASH中,需要重新分配.
若是BDM模式烧写程序,PRM文文件的地址映射不用改.

PRM的地址映射和INITEE \INITRM\INITRG 要配合起来改,这点你理解是对的.
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

关于我们|联系我们|小黑屋|智能车制作 ( 黑ICP备2022002344号

GMT+8, 2025-1-11 06:01 , Processed in 0.146635 second(s), 30 queries , Gzip On.

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表