How to solve the following scenario with FreeRTOS? I have 3 instances of a task that receives messages from the host. The message
is structured and contains an address that identifies the task that must
receive an decode the message. Each of these 3 tasks, depending on the type of
message received, provides a response of variable length.
Each of these 3 tasks sends a request to the task n. 4, GATEKEEPER type, that
provides to transmit the answers to the host.
How do you reconcile with the constraint that the Quee, when creating, has a
defined length?
Thank you

If I need to queue up messages of variable length (or messages of large size), what I do is put on the queue a pointer to the message, and have some method of handling these message buffers. That way the queue stores a fixed size message (the pointer). The other option, if all the messages are fairly small, is to set the queue up for the largest message, and just live with a bit of wasted space inside the queue. The task receiving the message needs a buffer big enough for this largest message, but it would anyway as it doesn’t know what sort of message it really is until it gets it.

Your first solution (pointer with ixed lenght)  requires managing a more memory than the one described in heap_x.c that is a block partitioned memory to be seen as a common resource shared by  mutex semaphores
Thank you

The blocks could be allocated as needed with pvPortMalloc by the sending task and then release with pvPortFree by the receiving task. Depending on your usage patterns, you may need to worry about heap fragmentation here. Since there are just a few different sizes, there could also just be an array (possibly of size 1 if you can count on the receiver to finish with the buffer before the sender needs another) for each size with a method to keep track of which ones are owned by the sending and which by the receiving task. This method could be as simple as making another queue which you push all the buffers addresses (of a give size) onto, and to get a buffer of that size, request one off. The receiving task then just pushes the addresses of the buffer when it is done.

This answer is completely satisfactory and comprehensive
Thanks for the suggestions and the help provided.