semphr.
h
vSemaphoreCreateBinary( xSemaphoreHandle xSemaphore )
Macro that implements a semaphore by using the existing queue mechanism. The queue length is 1 as this is a binary semaphore. The data size is 0 as we don't want to actually store any data - we just want to know if the queue is empty or full.
This type of semaphore can be used for pure synchronisation between tasks or between an interrupt and a task. The semaphore need not be given back once obtained, so one task/interrupt can continuously 'give' the semaphore while another continuously 'takes' the semaphore. For this reason this type of semaphore does not use a priority inheritance mechanism. For an alternative that does use priority inheritance see xSemaphoreCreateMutex().
| xSemaphore | Handle to the created semaphore. Should be of type xSemaphoreHandle. |
Example usage:
xSemaphoreHandle xSemaphore;
void vATask( void * pvParameters )
{
Semaphore cannot be used before a call to vSemaphoreCreateBinary ().
This is a macro so pass the variable in directly.
vSemaphoreCreateBinary( xSemaphore ); if( xSemaphore != NULL )
{
The semaphore was created successfully.
The semaphore can now be used.
}
}
h
vSemaphoreCreateBinary( SemaphoreHandle_t xSemaphore )
In many usage scenarios it is faster and more memory efficient to use a direct to task notification in place of a binary semaphore! http://www.freertos.org/RTOS-task-notifications.html
This old vSemaphoreCreateBinary() macro is now deprecated in favour of the xSemaphoreCreateBinary() function. Note that binary semaphores created using the vSemaphoreCreateBinary() macro are created in a state such that the first call to 'take' the semaphore would pass, whereas binary semaphores created using xSemaphoreCreateBinary() are created in a state such that the the semaphore must first be 'given' before it can be 'taken'.
Macro that implements a semaphore by using the existing queue mechanism. The queue length is 1 as this is a binary semaphore. The data size is 0 as we don't want to actually store any data - we just want to know if the queue is empty or full.
This type of semaphore can be used for pure synchronisation between tasks or between an interrupt and a task. The semaphore need not be given back once obtained, so one task/interrupt can continuously 'give' the semaphore while another continuously 'takes' the semaphore. For this reason this type of semaphore does not use a priority inheritance mechanism. For an alternative that does use priority inheritance see xSemaphoreCreateMutex().
| xSemaphore | Handle to the created semaphore. Should be of type SemaphoreHandle_t. |
Example usage:
SemaphoreHandle_t xSemaphore = NULL;
void vATask( void * pvParameters )
{
Semaphore cannot be used before a call to vSemaphoreCreateBinary ().
This is a macro so pass the variable in directly.
vSemaphoreCreateBinary( xSemaphore ); if( xSemaphore != NULL )
{
The semaphore was created successfully.
The semaphore can now be used.
}
}
h
vSemaphoreCreateBinary( SemaphoreHandle_t xSemaphore )
This old vSemaphoreCreateBinary() macro is now deprecated in favour of the xSemaphoreCreateBinary() function. Note that binary semaphores created using the vSemaphoreCreateBinary() macro are created in a state such that the first call to 'take' the semaphore would pass, whereas binary semaphores created using xSemaphoreCreateBinary() are created in a state such that the the semaphore must first be 'given' before it can be 'taken'.
Macro that implements a semaphore by using the existing queue mechanism. The queue length is 1 as this is a binary semaphore. The data size is 0 as we don't want to actually store any data - we just want to know if the queue is empty or full.
This type of semaphore can be used for pure synchronisation between tasks or between an interrupt and a task. The semaphore need not be given back once obtained, so one task/interrupt can continuously 'give' the semaphore while another continuously 'takes' the semaphore. For this reason this type of semaphore does not use a priority inheritance mechanism. For an alternative that does use priority inheritance see xSemaphoreCreateMutex().
| xSemaphore | Handle to the created semaphore. Should be of type SemaphoreHandle_t. |
Example usage:
SemaphoreHandle_t xSemaphore = NULL;
void vATask( void * pvParameters )
{
Semaphore cannot be used before a call to vSemaphoreCreateBinary ().
This is a macro so pass the variable in directly.
vSemaphoreCreateBinary( xSemaphore ); if( xSemaphore != NULL )
{
The semaphore was created successfully.
The semaphore can now be used.
}
}
h
SemaphoreHandle_t xSemaphoreCreateBinary( void )
The old vSemaphoreCreateBinary() macro is now deprecated in favour of this xSemaphoreCreateBinary() function. Note that binary semaphores created using the vSemaphoreCreateBinary() macro are created in a state such that the first call to 'take' the semaphore would pass, whereas binary semaphores created using xSemaphoreCreateBinary() are created in a state such that the the semaphore must first be 'given' before it can be 'taken'.
Function that creates a semaphore by using the existing queue mechanism. The queue length is 1 as this is a binary semaphore. The data size is 0 as nothing is actually stored - all that is important is whether the queue is empty or full (the binary semaphore is available or not).
This type of semaphore can be used for pure synchronisation between tasks or between an interrupt and a task. The semaphore need not be given back once obtained, so one task/interrupt can continuously 'give' the semaphore while another continuously 'takes' the semaphore. For this reason this type of semaphore does not use a priority inheritance mechanism. For an alternative that does use priority inheritance see xSemaphoreCreateMutex().
Example usage:
SemaphoreHandle_t xSemaphore = NULL;
void vATask( void * pvParameters )
{
Semaphore cannot be used before a call to vSemaphoreCreateBinary ().
This is a macro so pass the variable in directly.
xSemaphore = xSemaphoreCreateBinary(); if( xSemaphore != NULL )
{
The semaphore was created successfully.
The semaphore can now be used.
}
}
1.8.5