> >What I'm after is basically a way to extend the variables storage >within the gcc/libc framework. To store variables in an external sram >rather than internal sram. My (limited) understanding is that is the >heap storage.
Heap storage is used only for dynamic memory allocation. All local and global variables that are statically allocated go to internal ram (stack incase of local variables) > This would leave the internal sram free for stack. Same comment as above. > I >already have libraries for storing data in external sram but it is not >seamless. Have to go through extra steps to store and retrieve data, >like using eeprom. What I am envisioning is an addon with possibly >compiler option or something to redirect all access to the heap to >another sram segment completely, this particular segment being tied >into the system via spi. Something that would make using this with >existing software more or less seamless beyond maybe adding a link and >compiler option(or something to that effect) to make it happen. > Sounds interesting. But I hope you already thought such a feature cannot extend to all AVR devices. So maybe XMega A series is what you have in mind? Anitha _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
