I am using xEventGroupWaitBits() and xEventGroupSetBitsFromISR() APIs in project,
In ISR:
xResult = xEventGroupSetBitsFromISR(xI2CEventGroupHandle, I2C_EVENT_ISR, &xHigherPriorityTaskWoken_i2c );
if( xResult != pdFAIL )
{
portEND_SWITCHING_ISR(xHigherPriorityTaskWoken_i2c);
}
in Task process:
uxBitsI2C = xEventGroupWaitBits(xI2CEventGroupHandle, 0xF, pdTRUE, pdFALSE, pdMS_TO_TICKS(5));
if (uxBitsI2C & I2C_EVENT_ISR)
{ // process: }
results are not expected occasionally, mostly, this pair works, but sometimes,
1: xEventGroupSetBitsFromISR() is called in ISR, but xEventGroupWaitBits() never gets bit set in uxBitsI2C occasionally, so task process is missed;
2: since 5ms waiting in max (pdMS_TO_TICKS(5)), but uxBitsI2C gets set after 25ms occasionally, delay too long to process;
Setting a bit in an event group is not a deterministic operation because
you don’t know in advance how many tasks will get unblocked. Therefore
the operation is actually deferred to the RTOS daemon task (also known
as the timer task). That means the daemon task must execute before the
bits get set. The priority of the daemon task is set by the
configTIMER_TASK_PRIORITY setting in FreeRTOSConfig.h. What is its
priority compared to the other tasks in your system? What happens if
you set configTIMER_TASK_PRIORITY to (configMAX_PRIORITIES - 1), which
is the highest possible priority, and all your other tasks have a lower
priority? Doing that would ensure the timer task was always the task
returned to from the interrupt if posting to the event group caused a
task to unblock.