Its more that Task Notifications can work mostly like a Semaphore. In my case, the device driver is a generic library that runs within any tasks environment, the ISR would need to be told which task to notify to send the notification, and it would mean that the task would need some restrictions on its own use of notifications to avoid the driver possible clearing one that it was using, so an actual semaphore works better here.
Hi @richard-damon ,
If I am using task notification instead of binary semaphore, I can save the RAM also then why exactly do I need to use binary semaphore?
More than that it is not quit clear for me, could you please elaborate it?
As an example, my I2C driver is a series of functions that tasks can call to perform I2C transactions. The driver first uses a Mutex to make sure only one task is accessing the hardware at a time, and then starts the operation, and waits for the ISR to signal completion with a semaphore. If the driver used Task Notifications, then no task using the I2C bus could use the same notification word for other signaling, a the I2C operation might clear that signal, or get confused if the other use happens while it is doing an I2C operation.
Thus, adding a semaphore internal to the I2C driver is a cleaner step. Also, the ISR would need to be given the task handle of the task to notify for the completion, which still uses some (though less) memory.
Task Notification works best when it is a simple task/ISR to known task operation. The semaphore works better if who gets notified might change, or if there is a “pool” of tasks to handle the signal (though that tends to use a Queue with the request, but in FreeRTOS semaphores are just queue that send no data).
2 Likes