Please let me know if there is a way to create variable-sized memory pool. We want to statically allocate memory for TLS library rather than using malloc / free apis. The issue is that at times TLS library will ask for 4,8, 33, 15 .. etc size of memory.
However I understand that creating variable-sized memory pool is not possible. Using xQueueCreate / xQueueCreateStatic we always need to specify the length and item size. So lets say item size provided in 255 and length 100, so whenever we will get memory from the pool it will give of size 255 but we do not need 255 in our code implementation , as mentioned earlier we would need of variying size.
How we can achive the same - something like cyg_mempool_var_create is a function in the eCos real-time operating system that creates a variable-sized memory pool in eCos?
cyg_mempool_var_create is an eCos kernel function that creates a pool of memory from which blocks of any size can be allocated from it.
and in the freertos book there is a chapter “5.5 Working with Large or Variable Sized Data”
in the end you will also create a static buffer which is handled dynamicaly (depends on the heap implementation you use)
but regarding your xQueueCreate mention: you want to use variable sized queue messages which is not possible directly (at least as far as i know)
you have to use use a struct which holds a pointer to your dynamically allocated buffer of any size and the size infos itself.
these messages can be sent via the queue but you have to handle the memory managment yourself. so these message structs always have a fixed size with a pointer pointing to your messagedata of varrying size
Can you please provide some refernces of how to implement this? I actually do not require xQueueCreate - my requirement is that for a service I need to statically reserve some memory and then from that allocated memory based on requirement whenever memory is required / free to a service it does so. The intention is avoid malloc / free during run time to avoid scenarios like in case system is out of memory. So we have already calculated the maximum size of memory required sand reserved statically
I would think the simplest solution would be to take one of the existing heap managers, rename the entries points so they are a distinct set for this application, and just we them. All the heap functions (other than heap3 which just wraps malloc/free) are based on a static buffer.
My first guess would be heap4 would meet your needs, unless this is an application that is allocate once and never free, in which case heap1 would work.
This IS just dynamic allocation, but you are making a specialized pool that no one else can exhaust.
Thanks - well my requirement is allocate the memory in big chunck size and then from that chunk give slice of memory (of variying size) when required and gain back when it is not. The freed can again be re-assigned to service - so in all when my application statrs it reserves the memory if not fail to start. Once reserved do all allocation and deallocation (varying size) using that already allocated chunck of buffer
Can you please provide some example for using heap4 as suggested?
Thanks a ton for all info priovided. I am trying out the same.
Can you please let me know do we need to use vTaskSuspendAll / xTaskResumeAll as in pvPortMalloc - this will lead to application performance issues since there will be mutiples times malloc would be called instead can we use a mutex and exclude all mtCOVERAGE_TEST_MARKER call?
I think the code uses vTaskSuspendAll/ResumeAll because in the original code, to create a Mutex might require allocating memory for that Mutex, but this is the function to allocate memory for these operations. With a bit of changes to the code, we could have made a Mutex and just make sure it happens before the scheduler starts to avoid problems.
One other issue is that if you use a Mutex, you can’t make the call inside a vTaskSuspendAll block, and you might need to check if the scheduler isn’t running before making a possibly blocking call, as that wouldn’t be allowed.
As to mtCOVERAGE_TEST_MARKER, in normal running, that is a nothing, and I beleive it is only used for testing purposes.
your example suggested to me you want to change/handle different sized objects during runtime. than you should read the chapter in the freertos book i mentioned.
the rest: what Richard says.
and i think you have to read the memory managment pages to get a clearer understanding. depending on the heap manager you use there is one big chunk of memory allocated(like 32kb or whatever you want)and the freertos api reseveres smaller chunks of that big fat chunk four you queues, mutexes whatever. so freertos offeres everything you want
if you malloc/free dynamically during runtime from that big chunk or allocate the space of that big chunk during startup statically is up to you