rtel wrote on Monday, November 04, 2013:
It is a purely historical anomaly - and agree it is a nuisance as the calling semantics are different to any other function (it is a macro, not a function, for a start).
It cannot be retired because to do so would break lots of peoples code, including hundreds of demo applications we maintain ourselves…
…however, there is no reason why we don’t introduce an xSemaphoreCreateBinary() function then deprecate the vSemaphoreCreateBinary() macro. xSemaphoreCreateBinary() would be a macro to, but mapped to a call to a call to xQueueGenericCreate(), just as vSemaphoreCreateBinary() calls xQueueGenericCreate() now.
If you want to try this please add the following line to semphr.h, underneath the definition of vSemaphoreCreateBinary():
#define xSemaphoreCreateBinary() xQueueGenericCreate( ( unsigned portBASE_TYPE ) 1, semSEMAPHORE_QUEUE_ITEM_LENGTH, queueQUEUE_TYPE_BINARY_SEMAPHORE )
Let me know if that works for you.
A word of warning though - vSemaphoreCreateBinary() creates the semaphore in such a way that the first call to xSemaphoreTake() will pass, whereas the definition above would create the semaphore such that the first call to xSemaphoreTake() would fail, and not pass until something first ‘gave’ the semaphore.