[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] an idea: adding serial sram to avr to extend heapstor

From: Raymond Moore
Subject: Re: [avr-gcc-list] an idea: adding serial sram to avr to extend heapstorage
Date: Sun, 13 Mar 2011 11:52:43 -0500

On Sun, Mar 13, 2011 at 10:12 AM, Boyapati, Anitha
<address@hidden> wrote:
>>-----Original Message-----
>>From: address@hidden
>>[mailto:address@hidden On
>>Behalf Of Raymond Moore
>>Sent: Sunday, March 13, 2011 7:44 PM
>>To: address@hidden
>>Subject: [avr-gcc-list] an idea: adding serial sram to avr to extend
>>I am working on several projects that require more sram than most AVRs
>>have.  I don't particularly need more processing power but it would be
>>nice to have much larger variable storage space.  I can work with a
>>serial sram and use it for external storage already but it would be
>>nice to have an option to be able to turn that serial sram into heap
>>Due to the complexity of gcc I am assuming this will be a non-trivial
>>task but it is something I would be willing to work on.  My question
>>is, where in the gcc source would I look to start redirecting heap
> I haven't really understood your requirement, but if you are looking for some 
> heap storage stuff, then avr-libc might be your place. The malloc routines 
> there allocate the memory using heap variables.
> Coming back to the requirement, instead of using external ram via serial 
> interface, you want that to be integrated with SRAM seamlessly...Have I got 
> it right?
> Anitha

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.  This would leave the internal sram free for stack.  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]