I am planning to use a linked list to create a data buffer with elements of different sizes. For this I need to be able to allocate memory with pvPortMalloc, problem is that I am running out of heap quite easy. Which heap-allocation file should I use?? Since the list will be used frequently, alloc and free will be used a lot, and with different sizes I shouldn’t use heap_2. Heap_1 can’t free memory. Heap_3 uses ordinary alloc/free.
Is it a bad idea to implement a dynamic data buffer using freeRTOS??
Embedded systems have a wide variety of memory allocation requirements. A scheme that is good for one system will be terrible for another. The three schemes that come in the download are just intended to be examples of possible solutions. It is common that they are not suited to a particular application.
The pvPortMalloc() and vPortFree() functions are used by the kernel to allocate memory actually required by the kernel. For example when a task is created memory is allocated for the task stack. The kernel heap (sized by configTOTAL_HEAP_SIZE) must be large enough for the kernel needs - but there is no reason why you do not have another memory area for your application needs.
You have a couple of alternatives:
1) If you define configTOTAL_HEAP_SIZE to be the size required by the kernel, then calls to pvPortMalloc() within the kernel code will use this memory area with the heap_1, heap_c or heap_3 implementation. You could then define another memory area that uses [for example] MyMalloc() and MyFree() to allocate and free memory using any other scheme of your choice. Your application heap and the kernel heap are then separate.
2) Replace the scheme in heap_1 or heap_2 either with one of your own writing, or with another open source scheme if you can find one appropriate. For example, take a look at the wizC PIC18 FreeRTOS port pages on the WEB site. These include a link to a memory allocation scheme written by Marcel Van Lieshout for use with his port. Maybe this is useful to you?
Take care when choosing an implementation as many generic implementations are very slow and nondeterministic.