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] [April 2009 Threads] xQueueReceive without a buffer?Posted by Ricky on April 17, 2009 I have an interesting problem that I don't think I've seen in the forum.
I have a task that's sending a buffer of data to another task via a queue. The buffer is 200 bytes long and is sent very infrequently.
Due to space constraints, both the sending and receiving tasks allocate buffers to hold their data and free them as soon as possible. For the sending task, that's not a problem. It allocates a buffer, fills it, sends it via an xQueueSend, and then frees the buffer.
The problem is with the receiving task. It's blocked waiting for the queue, and it doesn't have a buffer waiting because it takes up too much space.
Ideally, when the task becomes unblocked, it would allocate a buffer to hold the data and then receive it. This could be done with xQueuePeek to wait for the queue to come in, and then the task could allocate a buffer and use xQueueReceive to retrieve the data into the newly allocated buffer.
But the problem is that xQueuePeek also requires a buffer pointer, and the buffer hasn't been allocated at this point. I can't send it a null pointer because that would point to the exception vector table in RAM and blow it out of the water.
So I have a few things I could do:
1. Ask the denizens of the FreeRTOS forum if I'm missing something and there's a simple way of doing this.
2. Add one line of code to Queue.c that would check for a null pointer right before the copy and skip the copy if null. This would let me use xQueuePeek to wait for a queue without wasting valuable resources. This would also let me use xQueueReceive to discard an unwanted queue item using a null pointer (a very nice feature!).
3. If there isn't an easier way to do this, ask Richard Barry if he would be so kind as to add this feature into the next release.
I suppose I could send xQueuePeek a pointer to the start of ROM so that it would dump the data into the bit bucket. But I don't think that's a very good idea since it would waste the cycles performing the copy.
I've already checked the xQueueReceive code (which also handles xQueuePeek) and it does the copy regardless. I even checked the implementation of memcpy in IAR EWARM v4.42 and it does the copy as well (expected, since I moved the exception vector table to address 0 in RAM using memcpy).
I'm currently using FreeRTOS version 5.0.0.
TIA,
-Ricky
RE: xQueueReceive without a buffer?Posted by Alain Mouette on April 17, 2009 Just my humble opinion:
greate a queue of pointers (2/4 bytes), allocate the buffer it in the sender thread and dealocate it in the receiving thread.
Pros: only one buffer *total*, important as you said that memory is small.
Cons: it looks like this is frowned upon in embeddeds... but if used with care it is no problem.
Alain
RE: xQueueReceive without a buffer?Posted by Dave on April 17, 2009 I agree with Alain with the added reason that doing that way (queueing pointers) is also much faster.
RE: xQueueReceive without a buffer?Posted by Richard Damon on April 17, 2009 As others have said, normally only small items should be passed on a queue since they are passed by value.
I would also add that if you are so low on available memory that the receiving task can't have a buffer available sounds like that buffer really shouldn't be dynamically allocated (unless the total lose of that data packet is ok). Dynamic memory allocations in a tight memory situation is fraught with peril as it is very hard to prove ahead of time that a needed memory block will always be available. Pre-allocating the blocks helps to make sure you always have it when you need it, then you just need to prove that the block gets back to you in time.
RE: xQueueReceive without a buffer?Posted by Ricky on April 17, 2009 Thanks for the help from everyone. Sending the pointer solved the problem.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|