EEPROM Memory management on AVR XMEGAs

1
votes

I'm having some difficulties understanding how EEPROM address space is managed. Fact is (as far as I understood):

  • it is possible to have local variables on the EEPROM (e.g. using the EEMEM macro of avr-gcc)
  • it is possible to have recursive function calls
  • hence I can have recursive functions with local variables residing in the EEPROM memory space
  • this means it is (in this case) unknown at compile time how much EEPROM space I'll use

So, how is this managed? Is there a stack-like something on the EEPROM?

Also, if there is something like this: how does it deal with user-forced fixed-address variables? Say I force to compiler to give me a variable x at address 0x0FFF. If the EEPROM stack (assuming there is something like this) starts at 0x000, how does it avoid overwriting x?

Probably this nothing people normally worry about, but I'm just curious and want to understand the details...

Cheers! Philipp

1
memory-managementavravr-gccatmeleeprom

1 Answers

2
votes

You have missed a key point in your fact list.

It is true that the EEMEM macro can cause a variable to be placed in EEPROM

#define EEMEM __attribute__((section(".eeprom")))

But the section attribute is only for global variables, not local ones like those used in recursive functions. So, no, there is no stack in the EEPROM. The stack is always in SRAM.

Since EEPROM is only for global variables, it is known at compile time how much is used. If you also force a memory location, that will not cause a problem. The compiler will make sure the addresses it chooses for the other global variables will not be in conflict.