[En-Nut-Discussion] Heap and external RAM
Harald Kipp
harald.kipp at egnite.de
Sat Sep 9 10:38:45 CEST 2006
Hello Marc,
At 23:08 08.09.2006 +0200, you wrote:
>Hi list
>
>Is the following comment still true in 4.0.3 ?
>
>/* Then add the remaining RAM to heap.
> *
> * 20.Aug.2004 haraldkipp: This had been messed up somehow. It'snice to
>have
> * one continuous heap area, but we lost the ability to have systems
>with
> * a gap between internal and external RAM.
> */
Yes, this is still true.
>I tried to modify (quick & dirty) the heap initialization to the
>following:
>
>//add internal memory to heap
>if ((u_short)NUTMEM_SIZE - 1 - (u_short) (&__heap_start) > 384) {
> NutHeapAdd(&__heap_start, (u_short) NUTMEM_SIZE -
> 1-(u_short)(&__heap_start));
>}
>//add external RAM to heap
>u_short mst = NUTXMEM_START;
>if ((u_short)NUTMEM_END - (u_short) (NUTXMEM_START) > 384) {
> NutHeapAdd(&mst, (u_short) NUTMEM_END - 256 -(u_short)(NUTXMEM_START));
>}
Due to lack of time I'm not able to check your calculations
right now. But it's not that easy. Note, that the compiler
can't handle gaps as well, it will put all variables in .bss
and .data by default and the linker will not be able to
split these segments afterwards.
>I'm not sure what 384 (NUT_THREAD_IDLESTACK ?) and 256 stands for, so I
>defined the same conditions. Now, if I print out NutHeapAvailable I get
>257 ?!
>What am I doing wrong?
First make sure that your calculations above are correct.
Then you may check the linker map file. Probably it would be
a good idea to exclude the internal RAM from variable
usage. You can still use it as heap memory.
The 384 will avoid adding too small fragments in the first
place. Beside that, at that point the stack is still
controlled by the compiler's runtime and is indeed located
at the top of RAM (as the linker knows it). The 256 bytes
spare allows this.
>Another question:
>With this configuration where is the stack located? At the end
>of external RAM?
While in NutInit(), yes. Later Nut/OS will modify the stack pointer.
(See my emails to Rob van Lieshout).
Harald
More information about the En-Nut-Discussion
mailing list