Task for peripheral handling that uses an interrupt.

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

hs2sf wrote on Friday, August 17, 2018:

If you ensure (by your task state machine) to block on the peripheral ISR notification after the peripheral was started, there is no problem. After completion of the peripheral transaction the task might wait for another request from it’s input queue. Regardless if meanwhile a number of requests were put into the task input queue. They remain pending and will immediately unblock the task on receive. That’s the main difference between a ‘binary’ notification and a queue.