• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 3119 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SYSBIOS heaps basics

cobsonchael
Mastermind 7930 points
Other Parts Discussed in Thread: SYSBIOS

ok so i am sort of new to heaps in SYSBIOS and looking at what little documentation i can find i have some questions:

1) if i want to use basic heap calls like alloc, free, realloc, etc it will use the "system" heap that is defined in the runtime tab in sysbios.  if i have 2 tasks that are at different priorities using that heap at the same time will there be issues? i see in the ROV window that the system heap is listed under Heapmem. when i looked up heapmem it says there was a gatemutex on heap mems by default and that you can change that if you want.  i looked up gatemutex and it appears that it is a gate for tasks.  so does this all apply to the system heap as well or does it not since it is listed under heapmems or is ti a special heapmem since it uses a different API? if not how do i apply a gate to the system heap? do i have to have "use heapmem" enabled in my .cfg file to get the full functionality or a heapmem or does that just come automatically? right now i have the NDK and another 3rd party software module running at the same time and i fear they are fighting for the heap space.

2) if i want to use my own heapmem instance for something then i have to call special free, alloc, etc functions.  i see that free has a size parameter in this instance but the system free does not.  does this mean i have to maintain a table of all allocs so i know how much was allocated to a block when i try to free it? is there info on how to free memory without keeping track of all the allocs? is the size part of the alloc?

3) i see that sysbios heaps don't have realloc. from what i can tell it is basically a "free" followed by an "alloc," is that essentially right?

4) the system heap has a "heap section" which is by default "null" and it says you can reassign this anyway you want.  what is entered in this spot? can i basically put whatever i want or am i supposed to use the defined memory sections in my platform?

5) what if i don't define an error block in my alloc call?

6) when using heap tracker it says it uses up a little more of the memory allocated so you have to adjust for that.  if a 3rd party is using the heap and we have no control over the allocs then will they likely overrun their heap? or do we have to adjust for the heap total size and 24 bytes is tacked on in addition to the original amount so the original alloc call will be fine?

  • 0
    TI__Mastermind 20805 points

    (1)  HeapMem uses a GateMutex by default.   This allows a single HeapMem instance to be used by multiple Tasks.   If the Task module is disabled (not common and not allowed when using NDK), then HeapMem will use 'GateSwi'.   If both Task and Swi modules are disabled (even more uncommon and unlikely), then HeapMem will use GateHwi.    So, if you call memory allocation at Task level, then you should be safe.   If you try to call malloc() or Memory_alloc() from an Swi or Hwi ISR, then GateMutex will raise an assert().    You should not need to do any special configuration options to get this default behavior.

    (2)  We do not keep track of the allocation size within the heap itself.   You need to maintain the allocated size within the application itself.   We do this to allow for unlimited allocations on more memory constrained systems.   For example, on some older DSP devices, there was small blocks (16K) of very fast on-chip memory.   If we kept the size of the allocation within the memory block itself, we would not be able to allocate 4 4K blocks of memory.   It is pretty inconvenient to have to maintain this size in the application, but that's the reason.   Note that malloc() allocates a few extra words and stores the size of the block just in front of the returned pointer.  This allows free() to quickly find the size of the free block before freeing it.

    (3) realloc() is actually an alloc of a new larger block, copy of the original to the new, free the original.   BIOS does not have such an API.

    (4) By default, the heaps is placed into the ".far" section on the C6x.   If you want to place your heap somewhere else, you need to enter another name like "myheap".  And you then need to make sure that you place this new section into one of the available memory regions.   See section 6.3.2 of the User's Guide.

    (5) If you pass 'NULL' as the 'eb' and the allocation fails, your program will abort.    This is useful for small apps that don't want to save code space and not do any error checking.   You should probably pass a non-NULL eb.   See Section 8.3 of the User's Guide.

    (6) You need to adjust the size of the heap to support 24-additional bytes for every allocation.   If the 3rd party code does a lot of allocations, then you need to increase the heap accordingly.   If they do 'n' allocations, then you need to increase the heap by 'n * 24'.    HeapTrack is optional and can be useful for finding memory leaks or to find out which tasks are doing the memory allocations.    You will need to increase your heap to accomodate.   If you are low on memory and cannot afford the extra memory required, then you cannot use this feature.