Describe the feature
Comes from #185 (see comment there).
Notification.h defines values used for synchronization, such as the NOTIFIED_FROM_ flags that indicate if an rx, tx, or task woke up a thread.
#define NOTIFIED_FROM_TX_ISR 0x80 /**< Notification from a transmitter ISR */
#define NOTIFIED_FROM_RX_ISR 0x20 /**< Notification from a receiver ISR */
#define NOTIFIED_FROM_TASK 0x40 /**< Notification from another task */
The values of the macros are application-specific values that we chose. To make components reusable, we should avoid components using these to reduce risk of collision with an application that might not necessarily use these values for synchonization macros.
Currently, UartDriver and MPU6050 are dependent on the above macros, to indicate whether an rx or tx event occurred when waiting for a transmission to finish.
After discussion with @tygamvrelis , we decided that this dependency issue would be solved by:
1) Abstracting the synchronization for any component code away from the code using it (Common/app/freertos.cpp). This would mean callback functions like HAL_UART_RxCpltCallback would instead loop over the UartDriver objects, check the UART handle, and call some public method on UartDriver that releases a semaphore to indicate the transaction completed if the handle matches.
2) Using other means of synchronization; instead of task notifications, use semaphores which are private members of the component class
An alternative mentioned was to have UartDriver have the NOTIFIED_FROM_* numbers as private const member variables, which app configures. However, app still needs to configure these, and thus think about them. We will try the semaphore implementation first.
Reason for request
Make components reusable, and simplify top level application logic.
Timeline
Tentatively mid-march so that we can get this done with the other maintenance tasks.
Describe the feature Comes from #185 (see comment there).
Notification.h defines values used for synchronization, such as the
NOTIFIED_FROM_
flags that indicate if an rx, tx, or task woke up a thread.The values of the macros are application-specific values that we chose. To make components reusable, we should avoid components using these to reduce risk of collision with an application that might not necessarily use these values for synchonization macros.
Currently, UartDriver and MPU6050 are dependent on the above macros, to indicate whether an rx or tx event occurred when waiting for a transmission to finish.
After discussion with @tygamvrelis , we decided that this dependency issue would be solved by: 1) Abstracting the synchronization for any component code away from the code using it (
Common/app/freertos.cpp
). This would mean callback functions likeHAL_UART_RxCpltCallback
would instead loop over the UartDriver objects, check the UART handle, and call some public method on UartDriver that releases a semaphore to indicate the transaction completed if the handle matches. 2) Using other means of synchronization; instead of task notifications, use semaphores which are private members of the component classAn alternative mentioned was to have
UartDriver
have theNOTIFIED_FROM_*
numbers as private const member variables, whichapp
configures. However,app
still needs to configure these, and thus think about them. We will try the semaphore implementation first.Reason for request Make components reusable, and simplify top level application logic.
Timeline Tentatively mid-march so that we can get this done with the other maintenance tasks.