Heap size with malloc

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I include stdlib.h in my code, malloc is included as well as the heap of SRAM. Is there an easy way to see how large the heap is? Is it based on the uC/SRAM size or is it fixed?

I know roughly how much memory I need malloc to create so, leaving a healthy safety margin for dead space from realloc and what not, I should be able to adjust the size to fit. According to the avrlib docs, you can move the heap start and end points, either at link time or run time but I did not see anything that would tell me WHERE those pointers start.

Also, if it helps, I am using an AT90USB1287 but I would like to know the general heap size if there is a doc or list somewhere.

Thanks in advance,

John Edwards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is nothing like a "default heap size". The heap grows dynamically at run time. If you try to allocate memory and there is no sufficient free space on the heap, then the heap is expanded. It expands up to the limit given by you at link time (default is RAMEND), but not further than the current position of the stack pointer (with a configurable safety margin in between).

http://www.nongnu.org/avr-libc/user-manual/malloc.html

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Avoid malloc like the plague.

Quote:
I know roughly how much memory I need
Then define a global or static variable holding the memory.

Quote:
but I did not see anything that would tell me WHERE those pointers start.

http://www.nongnu.org/avr-libc/u... wrote:
The so-called "heap" available for the dynamic memory allocator will be placed beyond the end of .bss.
...
The variables __malloc_heap_start and __malloc_heap_end can be used to restrict the malloc() function to a certain memory region. These variables are statically initialized to point to __heap_start and __heap_end, respectively, where __heap_start is filled in by the linker to point just beyond .bss, and __heap_end is set to 0 which makes malloc() assume the heap is below the stack.
...
The default value of __malloc_margin is set to 32.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ArnoldB wrote:
Avoid malloc like the plague.
I would formulate it slightly less offensively.

On "big" systems, there is a "school" of dynamically creating most of the [larger] variables runtime. However, in small embedded systems, resources - especially RAM - are severely limited, and this strategy is not to be used. Dynamic variables shoudl be therefore used only in justified cases - e.g. when a structures have to be allocated as imposed run-time by an other, connected, system.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My application running on Atmega 644p use malloc/free, almost all SRAM is used (~4kb). So far, I got no problem with fragmentation.
To know the max size of the heap, I use this:

void * __imalloc(uint16_t s)
{
	void * p = malloc(s); 
	glob_max_heap = ((uint16_t)p+s > glob_max_heap)?(uint16_t) p+s:glob_max_heap;
	return p;
}

void __ifree(void *ptr)
{
	if (ptr) free (ptr);
}

and call these functions in the code instead of malloc/free (or #define).
Olivier

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obor00 wrote:
To know the max size of the heap, I use this:
Why not watching __brkval instead?

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obor00 wrote:

void __ifree(void *ptr)
{
	if (ptr) free (ptr);
}


Actually, passing NULL-pointer to free() would be perfectly legal. It means that nothing will be done.