[En-Nut-Discussion] Large Arrays -- automatic change of starting??

JasonG jas_g at yahoo.com
Mon Feb 10 20:04:26 CET 2003


--- Harald Kipp <harald.kipp at egnite.de> wrote:

> >Any ideas on how much space is available for global vars out of the
> 4k
> >after ethernut (ie. the httpd app) takes what it needs?  Is there
> >anyway that the compiler could auto-inform of inherently breaking
> the
> >beginning of the SRAM that NutHeapAdd() assumes is available, or
> maybe
> >a flag that NutHeapAdd() uses to know where the end of the
> >compiler-used SRAM begins so NutHeapAdd() calculates this
> automagically
> >and doesn't try to share this area with what the compiler has used?
> 
> Best way to determine the available static RAM is to check
> the map file of the linker. The heap is initialized in nutinit.c
> (previous init.c). All external RAM is added to the heap. If you
> don't want this, you need to make a local copy of nutinit.c and
> modify it.
> 
> The initialization makes use of _bss_end, which is defined by the
> compiler's runtime lib and points to the end of the global data
> area.

Hi Harald, thanks for your response.  

So it looks like the beginning of the Nut avaialble Heap will never be
at a greater address than the beginning of external memory, but could
be less than the beginning of external memory depending on how many
global vars are lying in the bss area.  That's what I've been seeing on
querying the addresses of vars that have been allocated from the heap. 


So the moral is just to make sure that the compiler defined variables
never grow over 0x10FF into the external SRAM.


=====
JasonG
jas_g at yahoo.com

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



More information about the En-Nut-Discussion mailing list