Variable length message being stored in a Queue

paulgigliotti wrote on Friday, February 03, 2017:

I have set up my queue to pass message packets around the system. The maximum message size is 1024, but most messages will be much smaller. The first two bytes in the packet contain the message length. I would like to be able to add a parameter to the Queue send, PacketLength. When calling QueueSend with NULL in this position, it would behave as it does now, else it would move PacketLength bytes of date into the that queue location, leaving the last (1024 minus PacketLength) uninitialized. I would then have modified QueueRecieve, lets say QueueRecieveModified, that when called would use the first two byte in the queue being read to tell it how many bytes to move out or the queue into the destination address.

Or does something llike this exist - I am new to all of this.

rtel wrote on Friday, February 03, 2017:

See the “Working with Large or Variable Sized Data” section in the book.
http://www.freertos.org/Documentation/RTOS_book.html

paulgigliotti wrote on Saturday, February 04, 2017:

I foujnd this comment - Variable sized messages can be sent by defining queues to hold structures that contain a member that points to the queued message, and another member that holds the size of the queued message.

I am not sure which book you are referring to with the “Working with Large or Variable Sized Data” section…

rtel wrote on Saturday, February 04, 2017:

I am not sure which book you are referring to with the “Working with
Large or Variable Sized Data” section…

Did you see the link in my last post?

paulgigliotti wrote on Tuesday, February 07, 2017:

Yes, I did. I clicked on the link and see nothing about “Working with Large or Variable Sized Data” on that page.

paulgigliotti wrote on Tuesday, February 07, 2017:

I opened both books listed on that page and searched on “Working with Large or Variable Sized Data” and got no hits. BTW, it is important that when sending to the gue that the data is copied, and not passed by reference.

rtel wrote on Tuesday, February 07, 2017:

Section 4.5, page 126.

paulgigliotti wrote on Wednesday, February 08, 2017:

It seems that it is passing the structure, which has a reference to the data, but is not actually passing the data itself. Am I wrong? I have multiple hardware interfaces, each with their own buffers, that I need to move the data out of. The buffers are 1k, but the messages can be shorter than that. The first few bytes in the buffer contain the length of the message. When I get an interrupt on the interface, I do a bit of processes, to determine the RX queue to put the message into. I am fine with the queues items being 1k each, but I would like to have the QueueSend to have an additional arguement, xMessgeLength. When QueueSend is executed it only moves the first xMessgeLength items from the source buffer into the queue. Conversely, I would like to have QueueReceive with an additonal arguement, xMessageLengthBytes (or something named more clever than that). When this field is populated it tells QueueReceive that the first xMessageLengthBytes in the queue contain the length of the message, and only that number of bytes need to be copied out from that queue item into the destination buffer. Is there anything that works similar to this?

rtel wrote on Wednesday, February 08, 2017:

It seems that it is passing the structure, which has a reference to the
data, but is not actually passing the data itself. Am I wrong?

Not wrong, I think that is clear in the text.

I am fine
with the queues items being 1k each,

Ok - as long as you are fine with the inefficiency of having over sized
buffers, just make sure the buffer is big enough for the largest
possible message.

What you are wanting is not the way the queues work. You could just
have the queue always write 1K into the queue, no matter how much of the
data is actually required, so you write a bit of junk in too, but there
is no mechanism for knowing how much to read out again at the other end

  • you will just read 1K out as well and not know where the valid data ends.

If your original messages have the length at the start of the message,
then why not write the entire message, including the length, into the
queue. Then when you read from the queue you will also read out the
length of the data, so you know the start and end of the valid data.

In the TCP/IP stack we use a thread safe circular buffer to do this.
First the length is written into the buffer, then the data. Reading is
then done in two steps - the first read gets the length of the data then
we read the actual data.

paulgigliotti wrote on Thursday, February 09, 2017:

paulgigliotti wrote on Saturday, February 11, 2017:

The problem is that you are writing the the whole queue length and reading the whole queue length. The iniefficency that I do not mind, is the wasted memory space. It is the loss of processor bandwidth that is the issue. The processor spends time moving garbage data!. That is why I was thinking it would be advantageous to add another arguement to the send and recieve functions to tell how many bytes are being sent on the send, and how many bytes make up the length, at the start of the receive message, for the QueueReceive!