Re: [lwip-users] memory management

[Krzysztof Wesołowski]

Just to continue with off-topic :)

AFAIK all solution are toolchain specific, for GCC we use:

#define MEMORY_EXSRAM1_ORIGIN 0x60000000

#define MEMORY_EXSRAM1_LENGTH 4194304 /* 4M */

#define MEMORY_EXSRAM1_ATTRIBUTE __attribute__((section(".exsram1")))

And in linker script:

.exsram1 (NOLOAD) : 

{

    . = ALIGN(4);

    __exsram1_start = .;

    *(.exsram1);

    __exsram1_end = .;

} > EXSRAM1

PROVIDE(__exsram1_start = __exsram1_start);

PROVIDE(__exsram1_end = __exsram1_end);

We don't initialize data there (so only bss style variables are stored), but multiple memory buffers go there and in long term its much easier for us to maintain than fixed memory map.

Pozdrawiam,
Krzysztof Wesołowski,
tel. +48 721 337 238

On Fri, Aug 21, 2015 at 4:45 PM, Sergio R. Caprile <address@hidden> wrote:

> It's much safer to integrate this with linker script (for example
> with attributes on gcc).  Casting number to pointer does not
> guarantee that other variable will no be placed in the same area (by
> linker or other Dev using such tricks). Happy debugging when it
> happens :)

Yes.
However, in this particular example, since by definition of external
memory there is no on-chip memory at that location, the linker will not
assign any variable to that memory space. As for other Devs... well,
let's say all developers know the external memory map...

Had that "double allocation" happening once when toying with fixed
addresses in internal memory though, don't remember what I was doing and
why I did that... Nice pointing that out anyway!

AFAIK there is no CMSIS way of assigning segments, is it ? (but that is
completely off-topic)

--


_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users