Cretating a section for MPC5606S graphics RAM

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Cretating a section for MPC5606S graphics RAM

跳至解决方案
3,170 次查看
fieroluke
Contributor II

Hi everyone,

I am new to the PPC world, so this may be a dumb question, but I would like to know how to define a section for the 160KB on-chip graphics RAM the 5606S features with CW2.9 .The default LCF file only contains sections for regular (ECC) RAM.

I've added the line

graphics_ram : org = 0x60000000, len = 0x00028000

to the MEMORY section, and I defined a group

GROUP : {       graphics : {}    } > graphics_ram

In the code I defined a variable:

#pragma push // save the current state #pragma section RW "graphics"uint8_t buffer[65536];#pragma pop // restore the previous state

But somehow "buffer" still gets allocated in regular internal RAM. What am I doing wrong?

 

0 项奖励
回复
1 解答
2,916 次查看
fieroluke
Contributor II

Apparently CW only allows #pragma section for initialized data, if an uninitialized section is used in the declspec, the compiler issues an error. In effect, all uninitialized data must go into the (single) BSS segment.

Obviously I don't want all uninitialized data to go into graphics memory, so I put the declaration of the graphics memory buffer into a separate file gfx.c:

uint8_t Vram[240*320];

and in the LCF file I added:

MEMORY{        graphics_ram :     org = 0x60000000,   len = 0x00028000}GROUP : {       .graphicsBSS  (BSS) : { gfx.o (.bss) }               } > graphics_ram

Although the compiler only allows a single BSS segment, the linker allows different BSS segments for different files. At least this seems to work, although I now have to put all graphics descriptor data into separate files. If there is another way of creating and using a separate uninitialized data segment, I'd be glad to know it.

在原帖中查看解决方案

0 项奖励
回复
5 回复数
2,916 次查看
fieroluke
Contributor II

It seems I need to add a

__declspec(section "graphics")

to the actual variable declaration, which resulted in a "no uninitialized data" error message.

From other posts I have gathered that I need to change the pragma to:

#pragma section data_type "graphics" "graphics"

I'll try that later and report back...

0 项奖励
回复
2,916 次查看
fieroluke
Contributor II

Ok, this seems to work:

GROUP : {       .graphics  (DATA) : {}                  } > graphics_ram
#pragma push // save the current state #pragma section data_type ".graphics" ".graphics"__declspec(section ".graphics") uint8_t Vram[320*240];#pragma pop // restore the previous state

However: although the code works now, the segment is initialized data as it seems, so the binary file is unnecessarily large.

I also tried:

GROUP : {       .graphics  (BSS) : {}                  } > graphics_ram
#pragma push // save the current state #pragma section data_type ".text" ".graphics"__declspec(section ".graphics") uint8_t Vram[320*240];#pragma pop // restore the previous state

Now the segment seems to be uninitialized data, however the compiler wants to put the variable into the initialized section

Hints anyone?

0 项奖励
回复
2,917 次查看
fieroluke
Contributor II

Apparently CW only allows #pragma section for initialized data, if an uninitialized section is used in the declspec, the compiler issues an error. In effect, all uninitialized data must go into the (single) BSS segment.

Obviously I don't want all uninitialized data to go into graphics memory, so I put the declaration of the graphics memory buffer into a separate file gfx.c:

uint8_t Vram[240*320];

and in the LCF file I added:

MEMORY{        graphics_ram :     org = 0x60000000,   len = 0x00028000}GROUP : {       .graphicsBSS  (BSS) : { gfx.o (.bss) }               } > graphics_ram

Although the compiler only allows a single BSS segment, the linker allows different BSS segments for different files. At least this seems to work, although I now have to put all graphics descriptor data into separate files. If there is another way of creating and using a separate uninitialized data segment, I'd be glad to know it.

0 项奖励
回复
2,916 次查看
TomE
Specialist II

How about decalring a global POINTER to the graphics RAM, and have everything use that. Then initialise the pointer in code.

 

Tom

 

0 项奖励
回复
2,916 次查看
fieroluke
Contributor II
That's what I did at first, but when the application is done, I'll have quite a lot of graphics buffers, and I would like the compiler keep track of where which buffer is, instead of keeping track manually.

The DCU2 is able to blend the graphics layers, so there won't be just one or two static (large) buffers, but also many smaller ones of various sizes.

0 项奖励
回复