CMSIS-FreeRTOS
CMSIS-FreeRTOS copied to clipboard
CMSIS osMessageQueueNew control block allocation issues
Background
The CMSIS-RTOS2 api documentation states that when osMessageQueueNew
is called and osMessageQueueAttr_t
is interpreted, that when the value of cb_mem
and cb_size
in osMessageQueueAttr_t
are NULL
and 0
respectively, that "Automatic Dynamic Allocation" will be used for the message queue control block.
I have a situation where I want to use this behavior and provide a static buffer for a CMSIS osMessageQueue
's underlying storage, but allow the control block for the queue to be dynamically allocated. Therefore, I created a message queue with the following attributes:
osMessageQueueAttr_t mailQueue_attributes;
mailQueue_attributes.name = "mailQueue";
mailQueue_attributes.cb_size = 0;
mailQueue_attributes.cb_mem = NULL;
mailQueue_attributes.mq_mem = <some pointer to a buffer>;
mailQueue_attributes.mq_size = <size of the buffer>;
osMessageQueueId_t mailQueueHandle = osMessageQueueNew(40, 8, &mailQueue_attributes);
But, this does not work in the FreeRTOS implementation of osMessageQueueNew
, and indeed no queue is created at all.
The Issue
This happens because the parsing of osMessageQueueAttr_t
inside osMessageQueueNew
does not appear to support this use case. It does work if a suitable buffer is provided for both mq
and cb
.
This behavior is different from the reference implementation (RTX), where the memory blocks are handled seperately.
My request
Since ARM states that "Automatic Dynamic Allocation" is fully portable across different implementations of CMSIS-RTOS API v2 I would like to assert that this is a bug in the FreeRTOS implementation of the API, and would like to kindly request that the behavior in this situation be slightly modified to match the reference implementation's handling of this.
I would like to thank you as well for providing this CMSIS API for FreeRTOS. I use CMSIS heavily and generally the process of switching from RTX to FreeRTOS was very simple thanks to this API.
Hi,
thank you for pointing this out. The issue is known and listed under limitations.
The reason is in FreeRTOS implementation, which supports only use cases where either:
- all memory is provided and in this case *CreateStatic FreeRTOS API functions are used or
- no statically allocated memory is provided and in this case *Create FreeRTOS API functions are used.
Unfortunately here is no way to get around this limitation in a perfectly clean way. With some additional code and FreeRTOS configuration option configSUPPORT_DYNAMIC_ALLOCATION set to 1 it would be possible to implement this behavior.
I'll take a look and check if we can make a reasonable simple implementation.