xEventGroupWaitBits vs vTaskDelay in a loop

Kernel
1

willemmerson wrote on Friday, September 20, 2019:

I don’t really understand why xEventGroupWaitBits is better than just looping over vTaskDelay. They are both pausing a task at a particular point until some variable changes, but the second way seems simpler.

e.g.

static EventGroupHandle_t ethernet_event_group;
const static int CONNECTED_BIT = BIT0;
...
EventBits_t uxBits = xEventGroupWaitBits(ethernet_event_group, CONNECTED_BIT, false, true, timeout);

vs

bool is_connected = false;
...
while (!is_connected){
        vTaskDelay(100 / portTICK_PERIOD_MS);
}
2

richard_damon wrote on Friday, September 20, 2019:

Using xEventGroupWaitBits allows setting the event right after changing the flag you are waiting for, allowing the task to process the change right away. Using vTaskDelay, the task will wait the full timeout period before it checks again, thus delaying the response.

3

rtel wrote on Friday, September 20, 2019:

As per Richard D - when using an event group the task waiting for the
event group will unblock immediately that the bit or bits it is waiting
for are set and will therefore be responsive and not waste any CPU time
unblocking when there is nothing to do. Blocking on a task delay will
not be responsive as it will not unblock until the block time expires
and it will also unblock when there is nothing to do.

4

willemmerson wrote on Friday, September 20, 2019:

Thanks!