Re: [avr-libc-dev] FAQ addition?

[Joerg Wunsch]

As E. Weddington wrote:

> How do you setup a project to use external RAM?

Well, basically it's already in the FAQ. ;-)

http://savannah.nongnu.org/download/avr-libc/doc/avr-libc-user-manual/FAQ.html#faq_startup

As Theodore A. Roth wrote:

> The only gotcha is that you need to set it up early on in the startup
> procedure.

Only if you want to put your .data/.bss there, or your stack (which
would not be very wise anyway).  If you only want to use it for
additional memory or heap, you could do it at run-time as well.

> I'll write something up for this later today.

You already wrote, see above. :)

As E. Weddington wrote:

> And so one does not have to monkey around with link scripts and such 
> to add external RAM support?

No, the current linker scripts no longer limit the amount of RAM to
the internal RAM, instead they only impose the overall limit the
device could address in total.  (At the downside, if your .data
overflows the internal SRAM region, you won't get a warning since the
linker simply cannot know whether you intend to use external RAM or
not.)  So the only linker tweaks required are symbol assignments to
move .data/.bss into external RAM.

We probably shouldn't even mention to put the stack there.  As the
above FAQ entry mentions, there are devices where the errata prevent
this from working, and due to the penalty imposed when accessing
external RAM, it's almost always a bad idea.

> And would one have to manually set up the stack pointer? How is that 
> done?

Well, you can even manually assign it at the start of main().  Unlike
C programs in hosted environments (e. g. your typical Unix or Windows
system), there's no calling environment anyway, so the startup
framework doesn't allocate a stack frame, and actually "call" main().
Instead main() is simply entered using some black compiler magic at
application startup, without already leaving anything on the stack by
that time.  Likewise, if your main() "return"s, the compiler notices
this, and will compile a jump into an infinite loop (labeled "_exit")
provided by the .fini0 section for this (as opposed to an actual "ret"
instruction as in normal functions).  Thus, it's perfectly safe to
reset the stack pointer to another value at the beginning of main(),
using standard IO instructions.

As Theodore A. Roth wrote:

> I haven't. But if you need to put the heap in xmem, you might need to do
> something. See the dox for malloc in the user manual for more info since I
> think Joerg has nice discussion of that.

Yep, maybe we should simply write a "meta FAQ" entry, just pointing to
the locations inside the doc discussing the handling of external RAM
(i. e., pointing to the MCUCR initialization, to the chapter about
memory sections, and to the chapter explaining malloc()).  Just put
the letters "external SRAM" in boldface above it, to make sure people
will find it if they rush to start without studying the entire
documentation. ;-)

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/