Event Group clarification

Kernel
#1

sasikalaswathi wrote on Monday, November 04, 2019:

Created the event group with one set_task and 3 read_bits_tasks.
vEventBitSettingTask which sets the bit 0,bit 1 and bit 2.
vEventBitReadingTask -wait to read the bit 0
vEventBitReadingTask1 -wait to read the bit 1
vEventBitReadingTask 2-wait to read the bit 2
All tasks are same priority. Here are the things which needs clarfication.

  1. Irrespective of setting and waiting for the bits to set , all tasks will run until particular time slice expires(Switch between tasks of equall priority will occur on every tick interrupt)? but in API xEventGroupSetBits, Setting bits in an event group will automatically unblock tasks that are blocked waiting for the bits.
    While checking the output via printf, i get the following output:
    Setting bit task output -
    AFTER BIT 0 set
    AFTER BIT 1 set:
    AFTER BIT 2 set
    AFTER BIT 0 set
    AFTER BIT 1 set:
    AFTER BIT 2
    read_bit task output:
    bit 0 was set
    bit 1 was set
    bit 2 was set

While saw the output, the task which setting the bits (bit 0, bit 1, bit 2) will executes again even after the bit set right? here after one iteration of event bit set, control will not automatically unblock tasks that are blocked waiting for the bits.

  1. In second case, i slightly change the tasks vEventBitSettingTask,vEventBitSettingTask1 and vEventBitSettingTask2 to wait for the same bit (bit 0) .Here the parameter of xClearOnExit set to pdTRUE.
    As a result, only one task( vEventBitSettingTask) get the chance to read the bits. In other reader tasks(vEventBitSettingTask1 and vEventBitSettingTask2), the value resultant event group value was 0.

Here to get the chance to all reader tasks which waited for one of the bit to set, I changed the value of xClearOnExit to following value
vEventBitSettingTask - xClearOnExit-pdFALSE
vEventBitSettingTask 1- xClearOnExit-pdFALSE
vEventBitSettingTask2 - xClearOnExit-pdTRUE

In that case, i get the following output,
bit 0 -vEventBitReadingTask - first reader output string
bit 0 -vEventBitReadingTask
bit 0 -vEventBitReadingTask
bit 0-vEventBitReadingTask1-second reader output string
bit 0-vEventBitReadingTask1
bit 0-vEventBitReadingTask1
bit 0-vEventBitReadingTask2-third reader output string

Is this the correct way to do? for all reader tasks get the chance to read the set bit / any other way to attain this?
Attached the code for reference.

#2

rtel wrote on Monday, November 04, 2019:

Sorry - not following exactly, need to re-read with a bit more time to study. Hopefully the following will at least start to answer your questions.

If you set a bit that multiple tasks are waiting for then all the tasks will get unblocked. If the unblocked task has a higher priority than the task that set the bit then the unblocked task will run immediately, so the context switch/preemption is immediate. If the unblocked task has the same priority then the context switch will not happen immediately but when the next tick occurs.

#3

sasikalaswathi wrote on Monday, November 04, 2019:

Hi Richard,
Thank you for the response.
From your reply, I got answered for the first question.

  • If the unblocked task has a higher priority than the task that set the bit then the unblocked task will run immediately, so the context switch/preemption is immediate*

For this case, I set the priority of task (which wait for the particular bit to set) to higher than task which actually sets the bit. In this case, the task which setting the bit doesn’t get the chance to set the bit because of the reader task(wait for the particular bit) has higher priority. Do we have to manually introduce the delay (vTaskDelay) in reader task in order to set task get the priority?

#4

rtel wrote on Monday, November 04, 2019:

Normally the task would block reading the bit, so the lower priority
task would be able to run and set the bit.

#5

sasikalaswathi wrote on Monday, November 04, 2019:

Thanks Richard,
I found the problem, i set the xTicksToWait parameter of xEventGroupWaitBits to zero. Now i changed to higher value results in set bit task get the chance to run.

 One more thing needs a confirmation:
 set_bit_task has lower priority than the read_bit_task. In that case purpose of set_bit_task to set two bits. 
 First bit set(bit 0) causes the reader task(higher priority, waiting for only bit 0) to unblock. Here unblock occurs immediately with setting the  remaining bit (say bit 1) / without setting the remaining bit to set?