CMSIS Memory Pool management

[Vishnuchander90]

Hello Team,

In our project, we are using CMSIS RTOSv2 as generic interface layer for RTOS functionality.
Regarding the memory pool management, interface API's supports only fixed block size allocation mechanism. I feel it's not really flexible enough and might result in more internal fragmentation. Although it has it's own pros and cons.
Can you provide a direction if there is a way to make it more flexible irrespective of allocation mechanism? For example: To provide the size for allocation(to support first or best fit kind of memory manager).
Thanks for sharing your view/future roadmap on this topic.

[JonatanAntoni]

Hi @Vishnuchander90,

You can still use standard C/C++ library memory allocation (heap) if their drawbacks are not an issue for you.

Cheers,
Jonatan

[gilogil]

Hello Jonatan,

Thanks for your feedback.

May I bring some more information. It's indeed an issue for us ;-(

Using stdlib is not satisfying for us as it's not predictable (for instance we cannot define specific memory area for a specific purpose). We've many projects that need to "prove" memory usage and location and hence the predictability of the system (we might fail in certification because of this)

We see an advantage to get benefit from underneath RTOS memory management facilities dedicated to predictable memory pool that are defined in predictable way (we're using ThreadX ) with the flexibility of variable allocation size.

Is this topic already requested hence investigated by some of you ? Is there something in the pipe ?
If it's not the case, we can make a proposal that would fit our needs (and maybe others) without breaking the current paradigm. Is it OK with you ?

Thanks for your support and best regards.

Gilles

[gilogil]

Hello Jonatan,

any feedback about my query ?

Thanks in advance.

Gilles.

[JonatanAntoni]

Hi @gilogil,

The CMSIS-RTOS2 API currently does not expose an implementation independent interface for such features. We struggle a bit because of various pitfalls dynamic memory allocation has. But I can confirm, we have dynamic pools implemented in RTX5, internally. Once only used for initially allocating memory which is never freed this is reliable and deterministic.

One could access these internal APIs directly without using CMSIS-RTOS2 abstraction. The same should be possible when using ThreadX. This comes at the price of loosing full RTOS abstraction of course. Nevertheless, this could be solved with one's own enhancement to RTOS2 API.

The RTX5 API is declared here:

CMSIS_5/CMSIS/RTOS2/RTX/Source/rtx_lib.h

Lines 206 to 208 in dde5bac

	extern uint32_t osRtxMemoryInit (void *mem, uint32_t size);
	extern void *osRtxMemoryAlloc(void *mem, uint32_t size, uint32_t type);
	extern uint32_t osRtxMemoryFree (void *mem, void *block);

Would this API fit your purpose? If we could know that such an API can be implemented for multiple RTOSes (e.g., ThreadX and FreeRTOS) we might think about adding them to CMSIS-RTOS2 at some point.

Cheers,
Jonatan

[gilogil]

Hello Jonatan,

Current CMSIS-RTOSv2 is proposing a "block pool" memory allocation. This is definitively more predictable because no fragmentation coming along the time as it's a block by block allocation strategy.
IMHO, a byte pool allocation is missing. It's the one you're referring to in your answer. Great.

AFA ThreadX is concerned, byte pool allocation is supported (see here)

• UINT tx_byte_allocate(TX_BYTE_POOL *pool_ptr, VOID **memory_ptr, ULONG memory_size, ULONG wait_option);
• UINT tx_byte_pool_create(TX_BYTE_POOL *pool_ptr, CHAR *name_ptr, VOID *pool_start, ULONG pool_size);
• UINT tx_byte_pool_delete(TX_BYTE_POOL *pool_ptr);

Similar to RTX here.

AFA freeRTOS is concerned, I don't see any suitable external API to get access to this feature I'm afraid.

What's the possibility to imporve CMSIS RTOSv2 to enable such feature ? Is there a dedicated process ?

Thanks.

[JonatanAntoni]

No, there is no established process. You could raise a PR showing your proposal. Todays CMSIS-RTOS2 APIs use a control block instead of a raw pointer. We might need to discuss if we need a new type of control block for byte-pools. And I need to further discuss the idea with the team not to overlook any concern.