I found the below definition in the source code of FreeRTOS v7.0.2.

I have known that vSemaphoreCreateBinary has been replaced by xSemaphoreCreateBinary now and won't 'give' the semaphore after created it, but I still want to know why vSemaphoreCreateBinary does this.

~~~~

{																																			\
	( xSemaphore ) = xQueueGenericCreate( ( unsigned portBASE_TYPE ) 1, semSEMAPHORE_QUEUE_ITEM_LENGTH, queueQUEUE_TYPE_BINARY_SEMAPHORE );	\
	if( ( xSemaphore ) != NULL )																											\
	{																																		\
		( void ) xSemaphoreGive( ( xSemaphore ) );																									\
	}																																		\
}

~~~~

Thanks!

Probably because the [now defunct, as you point out] macro is very old, and dates back to a time before there was a separate mutex object - meaning binary semaphores were sometimes used as a mutexes. When a semaphore is used for mutual exclusion, you assume the resource being protected starts in the available state, so the mutex starts in the available state. Now there are separate binary semaphore and mutex objects, so when the very old semaphore macro was replaced by a function (so its semantics were consistent with the newer functions) it is created in the not available state - which is more logical when the semaphore is used for signalling. In more recent versions of FreeRTOS it is preferable to use direct to task notifications for signalling, as they are faster and use less RAM, so binary semaphores don't get much use in new applications.

Got it, thanks very much ^_^