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

2019-08-01 17:10发布

最近帮别人解决了一个问题,在此分享一下,主要是数据分页的原因:


在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块缺少的地址更多。
友情提示: 此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。
该问题目前已经被作者或者管理员关闭, 无法添加新回复
3条回答
edishen
1楼-- · 2019-08-01 18:26
 精彩回答 2  元偷偷看……
lijiabaobei
2楼-- · 2019-08-01 22:51
楼主强大
jxmzzr
3楼-- · 2019-08-01 23:56
哦,看了楼主的资料恍然大悟,原来是这样的,用到了  group  by   数据挺复杂的。

一周热门 更多>