Skip to content
This repository has been archived by the owner on Sep 27, 2021. It is now read-only.

Move Notification.h into the Common/app directory #188

Open
rfairley opened this issue Feb 24, 2019 · 1 comment
Open

Move Notification.h into the Common/app directory #188

rfairley opened this issue Feb 24, 2019 · 1 comment

Comments

@rfairley
Copy link
Member

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.

@rfairley
Copy link
Member Author

rfairley commented Mar 3, 2019

A related issue is this: #143 . If UartDriver used semaphores we can avoid using the hardcoded notification flags.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant