Using Queue of string in FreeRTOS

Question

I am using Ardunio/ESP32 and I am very new to FreeRTOS. I want to have a task that is solely responsible for printing text on serial port and other tasks can push messages. So, I decided to use a Queue of char arrays (or std::string) with 10 item capacity. But I am not sure how the queue storage allocation works for elements with different lengths!

Can you enlighten me on how I should create and consume the queue and what consideration I should take into account?

Answer 1

TL;DR: create a Queue of pointers to std::string and handle new/delete on either side. Make sure both producer and consumer are using a shared memory space.

The problem with using std::string in a "raw" memory API like FreeRTOS Queue isn't actually an issue with the size of the object. In fact the std::string object size is fixed, regardless of the size of the character array stored by the object. Don't believe me? Try compiling and running this simple program on your own machine:

#include <iostream>

int main(int argc, char **argv)
{
    std::string str1 = "short";
    std::string str2 = "very very very very very very long";

    std::cout << "str1 length = " << sizeof(str1) << "\n";
    std::cout << "str2 length = " << sizeof(str2) << "\n";
    return 0;
}

You'll get something like this (actual size will vary depending on your platform):

str1 length = 24
str2 length = 24

Note that this result would be different if you used str1.size().

The reason for this is that standard library containers like std::string usually store their contents in malloc'ed blocks, so the std::string object itself will just store a pointer to an array that contains the character data in the string. The sizeof() in this case tells you the size of the object from the compiler's perspective, which would be the size of the pointer and other fixed metadata (i.e. the fields of the struct). The .size() method tells you the size of the string from the implementation, which will include a string length calculation on the allocated character array.

The reason you can't just copy a std::string object into the xQueueSend() variants is a problem of lifecycle management. The FreeRTOS API does *Send and *Receive via raw memcpy. Standard library containers are usually not POD types, which means they must be copied via a dedicated copy constructor. If you don't do this, you're likely to invalidate some internal state of the object unless you really know what you're doing.

So the easiest way to make this work would look something like this:

1. On xQueueCreate(), set your object size to sizeof(std::string *):

xQueue = xQueueCreate(NUM_OBJECTS, sizeof(std::string *));

2. On xQueueSend(), create a std::string via operator new, and pass an address to this pointer to be copied. Do not delete the object.

std::string *pStr = new std::string("hello world!");
xQueueSend(xQueue, &pStr, (TickType_t)0);

3. On xQueueReceive(), copy out the pointer. Do what you need to do with this pointer, and then delete it.

std::string *pStr = NULL;
xQueueReceive(xQueue, &pStr, (TickType_t)10);
// do stuff with pStr
delete pStr;

Answer 2

Hi in This example I'll send a string data in the queue using a struct :

First We create the Struct:

typedef struct log_payload_t
{
    uint8_t message[256];
} log_payload_t;

Create the Queue:

xQueueHandle log_queue;
int main(int argc, char **argv)
{
   log_queue = xQueueCreate(10, sizeof(log_payload_t));
}

Send to String to the Queue:

log_payload_t payload;

memset(payload.message, 0, 256);
memcpy(payload.message, "Example text", strlen(str));

if (xQueueSend(log_queue, &payload, 0))
    {
            printf("added message to log queue  \n");
    }
    else
    {
            printf("failed to add message to log queue\n");
        
    }

Receive from Queue:

log_payload_t payload;
if (xQueueReceive(log_queue, &payload, 0))
{
    printf("Log Queue Data %s \n", payload.message);

}
else
{
    vTaskDelay(10);
}           

Answer 3

From my point of view, using a container of a fixed size buffer can be less that sub-optimal. Each operation of sending/receiving to/from a queue will involve a full copy of the whole buffer. It would also require larger and carefully selected stack sizes.

freeRTOS message buffers seem to me very convenient to solve your needs of sending chunks of data of nearly arbitrary sizes from one task to another.