You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
Background
The CMSIS-RTOS2 api documentation states that when
osMessageQueueNew
is called andosMessageQueueAttr_t
is interpreted, that when the value ofcb_mem
andcb_size
inosMessageQueueAttr_t
areNULL
and0
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: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
insideosMessageQueueNew
does not appear to support this use case. It does work if a suitable buffer is provided for bothmq
andcb
.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.
The text was updated successfully, but these errors were encountered: