Skip to main content
Marco1
Marco1
Associate III
February 22, 2017
Question

Bug on cmsis_os.h on stmcubemx 4.19.0 ?

  • February 22, 2017
  • 6 replies
  • 959 views
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
    This topic has been closed for replies.

    6 replies

    Adalgiso
    Adalgiso
    Associate III
    February 22, 2017
    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
    Marco1Author
    Associate III
    February 22, 2017
    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
    Adalgiso
    Associate III
    February 22, 2017
    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
    Marco1Author
    Associate III
    February 22, 2017
    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
    Gustavo.Laureano
    Senior
    March 23, 2017
    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
    Gustavo.Laureano
    Senior
    March 23, 2017
    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

     
    Terms & ConditionsAccessibility statement