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

[E. Weddington]

On 25 Nov 2002 at 20:44, Joerg Wunsch wrote:

> 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

Duh. So it is.
 
> 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. :)

So I see in the FAQ about having to write an assembly file, but 
didn't I read somewhere on this list that you don't have to do that 
method necessarily; you could write C code and put it into the init1 
section? If so, could that alternative be written up as the standard 
way of doing it and deprecate the assembly?

> 
> 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. ;-)
> 

I like that idea. Thanks!

Thanks Ted and Joerg for your informative answers!

Eric