rtel wrote on Wednesday, August 12, 2015:
It is a legitimate concern if you are short of RAM, and only you know if that is the case.
An event group will most likely be a viable alternative, but again it depends on your application. If there is only one possible receiving task for your binary semaphore, then the binary semaphore can be replaced by a single bit in the event group. Another bit in the event group can then be used to signal that there is something in the queue. Your task will then block on the event group to know which events occur - if the bit that represents the old binary semaphore gets set, then you take whatever action used to be performed after the binary semaphore was given - if the bit that represents something being in the queue you read from the queue.
In the later case, make sure you read all the data from the queue before returning to block on the event group again, as the event group cannot tell you how much data is in the queue, just that something is in the queue.
The disadvantage of this will be if the binary semaphore is given from an interrupt. Setting a bit in an event group from an interrupt is a longer operation than giving a binary semaphore from an interrupt because the event group operation is deferred to the RTOS daemon task, rather than being performed in the interrupt itself. The rataionale being that setting a bit in an event group is not a deterministic operation (you don’t know how many tasks will get unblocked because the bit is set), and the FreeRTOS implementation standard does not permit any non-deterministic operations to be performed from an interrupt or from within a critical section.
Again, if there is only one receiving task, you may also consider using a direct to task notification with the action set to eSetBits. That action can be performed directly within an interrupt, and is much faster too.