Differences

This shows you the differences between two versions of the page.

--- user:kluong:refactoring_the_firmware [2020/10/06 15:24]
kluong
+++ user:kluong:refactoring_the_firmware [2021/09/19 21:59] (current)
@@ Line 20: / Line 20: @@
 The whole point of having a top level structure is to be able to abstract the differences between each hardware generation away. Having a high level structure that is shared among different boards allow us to enforce certain things and make sure they happen in each different flavor of firmware. For example, each board should sample data and send data through an XBee.
+This could be accomplished in C++ by something that looks like
+Definitions
+<code cpp>
+class AbstractBoard {
+public:
+   virtual void sample();
+   virtual void transmit();
+};
+class AppleBoard : public AbstractBoard{
+public:
+   void sample();
+   void transmit();
+};
+</code>
+The main:
+<code cpp>
+loop(){
+   board = AppleBoard();
+   board.Sample();
+   board.Transmit();
+   // 60s sample frequency
+   delay(60*1000);
+}
+</code>
+====== Implementation notes ======
+Normally, in professional software engineering environments - work is planned so that it is non-disruptive to the current production setup. We'll try to do the same here to not leave the current code in a half-working state. This is especially important if work takes longer than expected, and there needs to be a transition for the next semester/year.
+Generally, here's how we can approach this:
+  - Review the current code and create the abstract base class
+  - Implement a class for one board (apple?) that inherits from the abstract base class (essentially implementing it)
+  - Test it
+  - Finish migrating the other boards
+Two notes:
+  * Tasks should be committed and merged as soon as they're complete
+  * At no period of time should the original firmware be unavailable (in case some teams need to deploy boxes)