Allocating an array from 0x8000 to 0xFFFF

Hi there..

I have a Mega 2560 with the 512K addon. Using the magic of bank switching I can bank out the lower half of memory and replace it with something else. Is there a good way to allocate the last 32K of memory with an array that won't get stomped on by my variables above it.

For example:

char memory[0x8000];

This will allocate 32k, but I assume that this is thrown somewhere in the heap. I need this array to be at the bottom of memory (0x8000 to 0xFFFF) because I plan to swap out banks under the array. I also want the ability to grab data from this array by de-referencing a char pointer within it.

Any ideas?

From my limited knowledge I think you'd have to use a linker script

char * memory = 0x8000;

Now dereference it.

WizenedEE:
From my limited knowledge I think you'd have to use a linker script

There's a ...linker?
That seems overly complected. In the memory examples we have this really useful function.

void bankfill(void)
{
  uint8_t *addr;
  uint8_t val;
  uint16_t count;

  for (addr=STARTADDR, count=COUNT; count; addr++, count--) {
    val = (uint8_t)random(256);
    *addr = val;
    if ((count & 0xFFFU) == 0) blinkfast();
  }
}

that plugs data directly into the memory by way of *addr. I'm willing to use that, but I also want to let the system "know" not to write there.

Is it OK to assume that because the bank is so low, using up the bottom 32k of memory, that nothing will overwrite because any program will assume only 8k memory space (The default for a 250 mega). I'm only using a maximum of < 50 bytes for my "normal" variables, so I would think that those should stay near the "top" of memory and nothing would ever get down to the 32k mark.

What was wrong with my suggestion?

halkun:
Is it OK to assume that because the bank is so low, using up the bottom 32k of memory, that nothing will overwrite because any program will assume only 8k memory space (The default for a 250 mega). I'm only using a maximum of < 50 bytes for my "normal" variables, so I would think that those should stay near the "top" of memory and nothing would ever get down to the 32k mark.

I think that's true. Nothing checks to see if the stack is about to collide with something, so you just have to "worry" about malloc. check out this page: avr-libc: Memory Areas and Using malloc() especially this quote:

The variables __malloc_heap_start and __malloc_heap_end can be used to restrict the malloc() function to a certain memory region. These variables are statically initialized to point to __heap_start and __heap_end, respectively, where __heap_start is filled in by the linker to point just beyond .bss, and __heap_end is set to 0 which makes malloc() assume the heap is below the stack.