FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [March 2012 Threads] Quee with variable lenghtPosted by Carlo De Bonis on March 26, 2012 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
RE: Quee with variable lenghtPosted by Richard Damon on March 26, 2012 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.
RE: Quee with variable lenghtPosted by Carlo De Bonis on March 26, 2012 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
RE: Quee with variable lenghtPosted by Richard Damon on March 26, 2012 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.
RE: Quee with variable lenghtPosted by Carlo De Bonis on March 26, 2012 This answer is completely satisfactory and comprehensive Thanks for the suggestions and the help provided.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|