RAM/Variables at fixed memory locations

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

Howdy All,

I have some variables at fixed memory locations using

unsigned char spriteRam[256*8]  __attribute__ ((section (".spriteram")));
unsigned char vram[32*28] __attribute__ ((section (".vram")));
unsigned char trigtable[64] __attribute__ ((section (".trigtable")));

and a makefile with this

LDFLAGS += -Wl,--section-start=.spriteram=0x00800400
LDFLAGS += -Wl,--section-start=.vram=0x00800C00
LDFLAGS += -Wl,--section-start=.trigtable=0x00800F80

I had an issue with the HEX file having the 0x8n000000 memory locations in it.

So I did a bit of searching and reading and worked out I could add this to the avr-objcopy section of the makefile

HEX_FLASH_FLAGS += -R .spriteram
HEX_FLASH_FLAGS += -R .vram
HEX_FLASH_FLAGS += -R .trigtable

I tried to find out in the manual pages for avr-objcopy but did not find anything. Is there a way to just remove/ignore the RAM/EEPROM addresses when making a hex file. Or do i have to add each section I create?

It does not really kill me to add them. I just would like to do it the "preferred way" if there is one.

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

Quote:

Or do i have to add each section I create?

There are two ways you can operate avr-objcopy. Either you use -R's to say what's in the ELF that you don't want in the output file or you use -j's to say which if the sections in the ELF you do want in the output.

As the usual use of sections is to add code sections then most Makefiles use -R to remove the few sections that don't belong in the flash (.fuse, .lock, .eeprom) but if there's a lot of those it might be better to switch round and use -j to list only the sections you do want (.text, .data).

But to be honest, unless you are talking about 10's or 100's of new RAM sections I'd just continue with your working solution of -Removing them.

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

Thanks.

I'll keep using -R

There should only be 3 or 4 sections I will have in RAM.

The two video related ones above that were created for speed reasons.

The Trig one was to use the now dead space above the VRAM because I plonked something down in the middle of the RAM on the compiler.