RE: [avr-gcc-list] Re: an idea: adding serial sram to avr to extend heap storage

[Matt.Vandewerken]

Is there a specific requirement for it to be a *serial* SRAM? You can easily 
tie a 32k parallel SRAM to the external memory bus of many atmega devices with 
just a bus latch ('373 or '573) and a single inverter. This xram is trivially 
mappable to the heap and/or bss space using linker directives (or linker 
scripts).

Cheers,
--
Matt van de Werken
Electronics Engineer
Mining Geoscience, CSIRO Earth Science and Resource Engineering
1 Technology Ct   Pullenvale   QLD   4069
P: 07 3327 4142  F: 07 3327 4455  M: 0400 538 608
E: address@hidden
"Those that do not understand UNIX are condemned to reinvent it, poorly"
  - Henry Spencer
-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Raymond Moore
Sent: Monday, 14 March 2011 10:43 AM
To: address@hidden
Subject: Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to extend 
heap storage

On Sun, Mar 13, 2011 at 3:59 PM, David Brown <address@hidden> wrote:
> On 13/03/11 19:01, John Myers wrote:
>>
>> Hi Ray,
>>
>> It sounds like what you want is to create another address space.
>> There is the TR 18037 draft called "Programming Languages - C - 
>> Extensions to support embedded processors".  GCC has some support for
>> it: http://gcc.gnu.org/onlinedocs/gccint/Named-Address-Spaces.html
>>
>
> What would be very neat is if there were some way to have named 
> address spaces defined by the compiler user, rather than the compiler 
> writer. The compiler writer would have to define a few "hookable" 
> extended address spaces, with generic names - something like 
> ADDR_SPACE_1 which called functions like
>
> void ADDR_SPACE_1_WRITE(ADDR_SPACE_1 void * dest, const void * src, 
> size_t n);
>
> void ADDR_SPACE_1_READ(void * dest, const ADDR_SPACE_1 void * src, 
> size_t n);
>
> You could define a few address spaces like this.
>
> It is likely that the size of the pointers would have to be defined at 
> gcc compile time, rather than use time - thus you'd pre-define "hookable"
> address spaces ADDR_SPACE_16_1, ADDR_SPACE_16_2, ADDR_SPACE_32_1, 
> ADDR_SPACE_32_2, etc.
>
>
> To use these, the user would use something like "#define exSRAM 
> ADDR_SPACE_16_1" and define the appropriate read and write functions.  
> A bit of linker file options could then let you define data directly 
> in these address spaces (though initialising the data properly would 
> be more complicated).  Any access to the data would result in calling 
> the appropriate functions.
>
> With enough LTO magic, the function calls may even have their overhead 
> reduced to almost nothing.
>
>
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>

David,
That is exactly the kind of thing I would like to do.

As for the other concerns, I am not really looking at pushing this upstream but 
more a project for myself that I would make available to the world as an 
optional patch.  My inquiry here was mostly an early question of how feasible 
this would be and where should I start looking in the code to get a start on 
it.  As for what project I am wanting to use this for, there are a number of 
them.  It came to mind as I was looking at the python on a chip project that 
wants lots of memory.

I know the xmega chips can do this, using serial ram chips as main memory and 
all, but they are not as easy to use as atmega and attiny chips tend to be.  I 
work with a lot of kids from 10 to 16 years old, teaching them simple 
programming and microcontroller development using AVR microcontrollers and 
working with surface mount chips tends to be a problem.  We have plenty of 
through-hole parts and solderless breadboards and such so we mostly stick with 
what we can easily and cheaply work with.

Thank you all for your help and information,

Ray

_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list