john579 wrote on Friday, August 17, 2018:
It’s not clear from the documentation if this is the correct method to use for peripheral handling of SPI, I2C, etc. A task is created with a FreeRTOS input queue that receives requests from other tasks. If the queue is empty, the task is blocked. When a request is received, the task unblocks and the peripheral is started. The task blocks until the peripheral has responded. When the peripheral completes its job, it signals using a interrupt. A FreeRTOS notification is employed to unblock the task. The task continues and if the input queue is empty, it blocks once again waiting for another request.
The question is: what happens if another request is received before the peripheral has completed its job? The new request might unblock the task when the task is waiting for the notification. This could produce a false notification that the peripheral has finished its work, which is not the intended behaviour and would cause unexpected results.
Of course, if the task is waiting for a notification, and only a notification could unblock it, regardless of how many new requests were received, then there would be correct behaviour. This would be a guess. Any confirmation would be greatly appreciated.
Regards, john579