Bug on cmsis_os.h on stmcubemx 4.19.0 ?

Marco1 · ‎2017-02-22

Posted on February 22, 2017 at 10:18

Hi,

i'm using stmcubemx 4.19.0 for my project on stm32f415vgt.

But i think it's present a little bug inside cmsis_os.h

When i create queue, the item size is never 0x04.

&sharpdefine osMessageQDef(name, queue_sz, type) \

const osMessageQDef_t os_messageQ_def_♯&sharpname = \

{ (queue_sz), sizeof (type) } << BUG ? This return ever 0x04

&sharpendif

Bye

Sorry for my english

#stm32

Adalgiso · ‎2017-02-22

Posted on February 22, 2017 at 10:25

There is no bug you have to use it like this

osMessageQDef(RTLQueueIn, 20, uint32_t);

and it will create a queue with the length of 20.

In example type is uin32_t so 4 bytes, and this is the size of item in the queue.

Marco1 · ‎2017-02-22

Posted on February 22, 2017 at 11:11

Hi, thank for reply,

I have a struct like this:

typedef struct

{

float a;

float b;

float c;

float d;

} MyMessage;

MyMessage pippo[ 10 ];

For example i need to send pippo[ 0 ] with queue from one task to other task.

Which is the way to create queue for this struct ?

I never worked with freertos and this part is not clear for me.

Adalgiso · ‎2017-02-22

Posted on February 22, 2017 at 11:21

osMessageQDef(

QueueDef

, 20, uint32_t);

QueueID= osMessageCreate(osMessageQ(

QueueDef

), NULL);

osMessagePut(

QueueID

, (uint32_t)&pipo[0], 1);

and to receive

event = osMessageGet(

QueueID

, osWaitForever);

Marco1 · ‎2017-02-22

Posted on February 22, 2017 at 12:29

Thank you,

i solved, but this cmsis is not realy clear for me !

Bye Bye

Gustavo.Laureano · ‎2017-03-23

Posted on March 23, 2017 at 14:02

I think the real question here is about the way osMessage works, because under the hood it uses xQueue from FreeRTOS and queues in FreeRTOS are managed by copy, this means that every FreeRTOS queue object that are created already have enough space to hold the item (because it already was allocated in the queue creation), in this way you dont need to manage dynamic memory allocation/release to pass the item by reference (pointer to the item), which could lead to memory fragmentation...

Modus operandi of queues in FreeRTOS here:

http://www.freertos.org/Embedded-RTOS-Queues.html

The way FreeRTOS works is great because you can send messages that were temporalily created inside a function (as stack variables) because it's content will be copied in the queue item, without bother about the the descrution of the message when the function returns (and stack is released)

In the way osMessage works, you need to allocate memory to the message item and pass its reference in the message, and the receiver should take this reference, access the item and free it after finish processing, throwing away the 'pass by copy' advantage of the FreeRTOS's xQueue

Gustavo.Laureano · ‎2017-03-23

Posted on March 23, 2017 at 14:14

I also made this post about a possible bug in the cmsis_os message implementation:

https://community.st.com/0D50X00009XkewgSAB