Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMSIS osMessageQueueNew control block allocation issues #81

Open
ad3154 opened this issue Aug 30, 2023 · 1 comment
Open

CMSIS osMessageQueueNew control block allocation issues #81

ad3154 opened this issue Aug 30, 2023 · 1 comment

Comments

@ad3154
Copy link

ad3154 commented Aug 30, 2023

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.

@VladimirUmek
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants