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.

RTOS/TMS320C6670: Handling multiple heaps

Part Number: TMS320C6670
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hello!

We are developing a system on C6670. At certain point of the development we realized we need to have multiple heaps. Before that malloc() and free() were conveniently routed to their actual implementations, and developers did not bother about that. Now as we wish more than default heap we need to use some other API.

As I understood, what was MEM_alloc and MEM_free in DSP/BIOS now is superseded by Memory_alloc and Memory_free of SYSBIOS.

I know how to create other heap through configuration script. What I wonder is what is intended usage of Memory_alloc and Memory_free. With the former things are relatively clear, heap handle, block size and alignment all looks relevant and reasonable. What makes me stuck is intended usage of Memory free. I could understand passing heap handle argument explicitly, but why this API requires explicit specification of the block size to free? People used to malloc() rarely keep track of block sizes were requested. Does it mean, that using multiple heaps, and hence using Memory_free one have to keep records of blocks were allocated?

Of course, I know that right before the pointer returned there is "hidden" record about this allocation and peeping there I could find the block size. However, I have a feeling that was not intended usage of API.

I understand the question I am asking is very lame and basic, but please direct me to some guideline or example of practical usage of Memory_free().

Thanks in advance.

  • Well, it seems the question was asked before as "Why do we need size as the last parameter for Memory_free".

    As I understood, Memory_alloc(), mapped to xdc_runtime_Memory_alloc() does not make hidden record about block size was requested. In the same time if I follow the definition of malloc(), it will land me to some proj_h_pe66.c, which looks pretty much as generated to me. There I see

    Void ATTRIBUTE *malloc(SizeT size)
    {
        Header *packet;
        xdc_runtime_Error_Block eb;
    
        xdc_runtime_Error_init(&eb);
    
        if (size == 0) {
            return (NULL);
        }
    
        packet = (Header *)xdc_runtime_Memory_alloc(NULL,
            (SizeT)(size + sizeof(Header)), 0, &eb);
    
        if (packet == NULL) {
            return (NULL);
        }
    
        packet->header.actualBuf = (Ptr)packet;
        packet->header.size = size + sizeof(Header);
    
        return (packet + 1);
    }

    Thus it looks to me that malloc() implementation adds this extra hidden record function above  xdc_runtime_Memory_alloc().

    I am just curious, is it OK to create similar implementation, say other_malloc() and internally implement that hidden record in other heap.