AW: [En-Nut-Discussion] Adding another 4K SRAM to ICC projects for FREE; )

[Oliver Schulz]

Hi Brett,

I don't know exaclty what ICCAVR does with two stacks (SW and HW) but one
thing is for sure, NutOS uses its own stack handling. There is one stack for
each thread, which is allocated from available heap memory on thread
creation.

If ICCAVR really "forgets" SRAM if data+bss does not fit in it, perhaps this
can be a first try in nutinit:

#ifdef __ICCAVR__
   if ((u_short) __data_start__ > (u_short) RAMEND)
      NutHeapAdd((void *) 0x0100, 0xf00);
#endif
[Note: code not tested]

However, perhaps ICCAVR uses this area for something I don't know, so the
ICCAVR gurus are now asked..

In gcc the data section starts usually always at 0x100 with .data, .bss and
.noinit section. The remaining memory (starting from end of .noinit) is
added to available heap memory.

the avr-libc library initially sets the stack pointer (SP) to RAMEND, which
defines the end of INTERNAL ram. nutinit resets SP to end of EXTERNAL ram
(if available) to avoid overwriting .data or .bss sections while
initializing the system. After idle thread is started, NutOS is resposible
for stack handling and the the previous stack at end of xram is just added
to available heap mem.

Cheers,
Oliver.


-----Ursprungliche Nachricht-----
Von: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Brett Abbott
Gesendet: Samstag, 24. Januar 2004 02:30
An: en-nut-discussion at egnite.de
Betreff: [En-Nut-Discussion] Adding another 4K SRAM to ICC projects for
FREE; )


Hi

I always need more SRAM.  Whilst trying to tune my use of this precious
resource, I found myself adding numbers which always came up 4K short of
32K.  When using external SRAM with ICC and when you have lots of variables
assigned (ie. more than the 4K internal), ICC moves the bss and data area
into external SRAM leaving only the HW and SW Stack in internal SRAM.  (This
is a rough paraphrase of what actually happens, I know it isnt quite like
this)

I have used the following statement to make use of the unallocated memory at
the top of my main function.

    NutHeapAdd((void *) 0x100, 0xf00); // f00= 1k - 256 bytes for stacks

While it is only a small chunk of memory, fragmentation isnt too much of an
issue and 3.5+K gives me a very nice overhead.

Is this something we could add to nutinit.c?  Have I missed something
critical (ie. should I leave this space untouched for system use?) Does
anyone know if we can parameterise this to be driven by compiler/linker
flags rather than hard coded as I have.

I am uncertain if this "forgotten" memory occurs in gcc, or even if it only
occurs on my version of ICC.

Hope this is of use.
Cheers
Brett

--
-----------------------------------------------------------------
Brett Abbott, Managing Director, Digital Telemetry Limited
Email: Brett.Abbott at digital-telemetry.com
PO Box 24 036 Manners Street, Wellington, New Zealand
Phone +64 (4) 5666-860  Mobile +64 (21) 656-144
------------------- Commercial in confidence --------------------