richard_damon wrote on Saturday, May 15, 2010:
As Edwards says, FreeRTOS is based on a task waiting for one thing at a time. If the two queue are providing similar types of data you can do as Edwards says. If the queue hold very different types (and size) of data, then this might not make as much sense, but normally these would go to different tasks. If there is a good reason just one task will be processing this sort of mixed data, O can see two good options to handle this.
Method 1 adds a third queue, where each producer, after putting the data on its respective queue, puts a flag on the third queue with a value to tell the consumer which queue to take the data from. If you want to save a bit of memory, and the order the queue are serviced isn’t critical, it could be replaced with a single semaphore. the producers raise the semaphore after adding their data to the queue, (this raise may fail, but that is ok. that just means there is some other data waiting to be processed), and the consumer waits on the semaphore, and when it gets it, it checks each of the queues with a 0 timeout retrieval, until all the queue are empty. At that point, it wait on the semaphore again.