打印

CMD文件使用的空间为什么看起来比实际的大

[复制链接]
755|3
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
拿起书本|  楼主 | 2014-10-30 12:37 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
mb, se, COM, RAM, ge
最近帮别人解决了一个问题,在此分享一下,主要是数据分页的原因:


在cmd里定义:
        RAMM1       : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */
        commbuf             : > RAMM1        PAGE = 1
在main.c里定义以下几个变量
#pragma DATA_SECTION(sendT, "commbuf")
Uint16 sendT[260];
#pragma DATA_SECTION(receT, "commbuf")
Uint16 receT[260];
#pragma DATA_SECTION(CntPPR, "commbuf")
Uint32 CntPPR[250];
表面上共需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)



原因是RAM存储的时候,page被划分为64word的小单元,而数组被存储在连续的、整块的单元上,未使用到的空间不会再分配给其它数组或者变量使用(所以存储空间有hole)。
所以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块缺少的地址更多。

相关帖子

沙发
edishen| | 2014-10-30 14:03 | 只看该作者
哦哦 学习啦

使用特权

评论回复
板凳
lijiabaobei| | 2014-10-30 14:39 | 只看该作者
楼主强大

使用特权

评论回复
地板
jxmzzr| | 2014-11-12 15:36 | 只看该作者
哦,看了楼主的资料恍然大悟,原来是这样的,用到了  group  by   数据挺复杂的。

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

个人签名:好好学习,天天向上!

519

主题

4195

帖子

31

粉丝