Expanding heap with GCC

Why???

Newlib is for deeply embedded systems, where you presumably know all the memory resources during link time, and assign the size of the heap there. So if you start with all the memory available, where is the extra heap going to come from?

Conversely, if you have a system that has enough layers between the application and the underlying hardware that it makes sense to request more heap space, why use newlib?

If you must have this, you can always write your own heap management. I'm pretty sure that you just need to write your own malloc and free, but a little bit of digging in map files will tell you.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

That was exactly my thought; when I read that post about allowing not just dynamic memory allocation but dynamic _heap resizing_ in an embedded system I physically cringed.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

In small embedded system the stack and heap share the same RAM section. On processors in which the stack grows downwards, the stack pointer is initialized at top of RAM and grows downwards, the static variables are allocated at the bottom of the RAM and the heap grows upwards towards the stack. At least during development, the function entry stack frame allocation routine should check that the stack does not overlap the heap and the heap allocation should check that it is below the stack frames.

Or at least, at startup fill the whole stack+heap area with a known pattern, such as 0xDEADBEEF and after program execution, check that there is some unused RAM space between the stack and heap areas.

For processors, in which the stack grows upwards, the order of RAM regions is of course reversed.

Dynamic heap extension makes sense mainly in systems with virtual memory, thus, the heap allocation routine can ask for zeroed pages from the OS and get a (possibly noncontiguous) region of _virtual_ memory pages. The heap allocation is done incrementally, so that only those pages that are actually needed by malloc are also reserved space from the page file.

It depends on what you consider the heap to be and how you use it.

In some systems, the heap is a fixed size piece of memory. All

*remaining* memory is effectively used by The Stack.

I tend to work things the other way around: all unallocated memory becomes part of The (Main) Heap and I allocate stacks out of that Heap (since almost all my work is in multithreaded environments, there is a need for a mechanism to allocate stacks for each thread created).

If you have dynamic tasks that come and go (in terms of "existence"), then the memory set aside for their Stacks can be returned to The Heap once they are destroyed -- and, potentially, reallocated later if they are subsequently re-created.

I also tend to allocate a Heap per task if that task will be doing any sort of memory allocation and *needs* to be assured of the availability of that memory (having a single Heap requires you to implement "reserves", otherwise). In those cases, the task_create() typically creates a Heap for the task and then allocates the task's Stack out of that particular Heap.

In this way, the memory requirements of individual tasks can be isolated from each other as well as being "assured" of existing.

[my latest memory manager allows any number of heaps to be created and adds a "Heap*" parameter to all memory allocation requests to indicate to which heap the request should be directed. This allows me, for example, to create heaps that are used as "partitions" (buffer pools) and managed by the same bit of code]

As to the idea of "dynamic memory management" in embedded systems... let's not get into that, again :> I rely on this mechanism in almost every product I create (are all of your tasks "static"? Can you afford to set aside resources for them even when they are not "active"?)

My need depends on the fact that:

- RAM is not all contiguous but scattered.

- No MMU is present so no hw virtual memory is possible.

BTW. I found it: _sbrk_r.

Thx for your thoughts!