External memory section

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!

Is there a section for external memory space? This is important, because I would like to make a library, and would like to make usage transparent, so that the user wouldn't have to worry about overlaps, the linker will do that for him...

So that I could do something like this:

__attribute__ ((section (".xmem")));
char buf[20480];

or in asm:

.section .xmem
.global buf
.type buf, @object
buf: .space 20480

Regards,
axos88

axos88

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's no .xmem in the default .x files - so no there is no such standard memory section.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You'll have to do this with your own custom linker script.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried passing "-Xlinker --section-start -Xlinker .xmem=0x800260" to gcc when compiling, but it didn't work. tried with and without the dot before xmem.

Can you help me out?

My code is:

.section .xmem
.global buf
.type buf, @object
buf: .space buf_SIZE

axos88

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

axos88 wrote:
I tried passing "-Xlinker --section-start -Xlinker .xmem=0x800260" to gcc when compiling, but it didn't work. tried with and without the dot before xmem.
Where did you get that syntax? That's not what shows in my makefiles.

I'll give you the syntax below, but first I also want to comment on the location. Which processor are you using? RAM address 0x260 seems very small. Does your processor only have 512 bytes of internal SRAM?

Okay, assuming your address is right, try including:

-Wl,--section-start=.xmem=0x800260

Make sure that is passed on the line that links the app.

You can then set up your variable as

char buf[20480] __attribute__ ((section (".xmem"))); 

One final warning: You will never be able to define any array larger than 32767 elements as there is a limit in GCC.

I have not tried this, but similar code/make entries in my code works.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using an atmega 8515, so yeah, it has only 512Bytes of SRAM.

i am linking like this:

$(CC) $(LDFLAGS) $(OBJS) $(LIBFLAGS) -o $(TARGET)

and tried adding that line to LDFLAGS.

I tried the lines you said, and works. Thanks a lot :)

Regards,
axos88

axos88

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

Stu, I'm using the same strategy you suggest, but for external EEPROM variables (.eeprom_ext section).
At the beginning I had all working ok with all external eeprom variables in the same unit (*.c file).

When I put an external eeprom variable in another unit, it was created another section: .eeprom_ext.1 starting at the same address as the .bss.

I guess it's a linker problem, because when I change the unit compilation order in the makefile, .eeprom_ext.1 is applied to the other unit.

Any suggestion?

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

Just to tell that the solution for this problem is editing the ldscript,

So, if more than one unit is used, then you have to change the ld script, which will be working just like .eeprom does.
For atmega128 and gcc 4.1.2, add to this file: (...)/AVR/avr/lib/ldscripts/avr5.x
eeext (rw!x) : ORIGIN = 0x820000, LENGTH = 64K
...
.eeext :
{
*(.eeext*)
__eeext_end = . ;
} > eeext