Why does vSemaphoreCreateBinary(xSemaphoreHandle) effectively use pass by reference rather than return a value like xSemaphoreCreateMutex()? Is there some reason this has not been retired and replaced it with an xSemaphoreCreateBinary() that returns an xSemaphoreHandle like xSemaphoreCreateMutex()? I ask because mocking out vSemaphoreCreateBinary() for testing (with CMock) is very cumbersome compared to mocking out xSemaphoreCreateMutex().

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. Regards.

xSemaphoreCreateBinary() is now checked into the head revision. Regards.