2835|1

1

帖子

0

TA的资源

一粒金砂(初级)

楼主
 

变量空间分配奇怪问题(CCS4.2 DSP28027) [复制链接]

本帖最后由 wjckzdh 于 2014-9-24 12:15 编辑

敢问各位, 最近遇到很奇怪的一个问题:

所使用DSP为28027,cmd中定义数据段(显然空间大小1024字)
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];
其它无涉及到commbuf的变量,精打细算,共需260+260+250*2=1020,commbuf正好放得下.

但编译结果空间不够(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  详情 回复 发表于 2014-10-24 11:48
点赞 关注(1)
 

回复
举报

84

帖子

0

TA的资源

一粒金砂(中级)

沙发
 
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块缺少的地址更多
个人签名我的新书:《TMS320F2833x DSP应用开发与实践》
 
 

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

随便看看
查找数据手册?

EEWorld Datasheet 技术支持

相关文章 更多>>
关闭
站长推荐上一条 1/10 下一条
【有奖直播】2025是德科技数字月-数字新品来助阵
直播时间:3月19日(周三)14:00
直播奖励:小米口红充电宝、倍思充电线、是德科技十周年鼠标垫

查看 »

 
EEWorld订阅号

 
EEWorld服务号

 
汽车开发圈

 
机器人开发圈

About Us 关于我们 客户服务 联系方式 器件索引 网站地图 最新更新 手机版

站点相关: 国产芯 安防电子 汽车电子 手机便携 工业控制 家用电子 医疗电子 测试测量 网络通信 物联网

北京市海淀区中关村大街18号B座15层1530室 电话:(010)82350740 邮编:100190

电子工程世界版权所有 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号 Copyright © 2005-2025 EEWORLD.com.cn, Inc. All rights reserved
快速回复 返回顶部 返回列表