Differences

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

--- user:kluong:refactoring_the_firmware [2020/10/06 14:52]
kluong
+++ user:kluong:refactoring_the_firmware [2021/09/19 21:59] (current)
@@ Line 1: / Line 1: @@
 **Note: In draft.**
 Here are some of my notes on how to refactor the firmware. First, make sure that you have the environment setup and can upload firmware to a microcontroller.
-One thing that would be nice to have is to redo the current high level structure to use C++ features instead of using C structures. I originally wrote the firmware using C organizational structures to:
+====== Background ======
+One thing that would be nice to have is to redo the current high level structure to use C++ features instead of using C structures. I originally wrote the firmware using C organizational structures to:
@@ Line 10: / Line 13: @@
   - leave the top level structure in case we ever needed to support a platform that doesn't support C++
-I think point #1 is valid, but since the underlying structures use C++ already, there is added complexity by not just using C++ for the top level organization.
+I think learning more C is a good thing (point #1), but it's probably better to have structures that are easier for maintenance. Considering all of the libraries underneath also use C++, it's probably easier to just have to deal with all C++ instead of mixing C/C++ structures.
+Point #2 is probably not really a valid usecase anymore - there will be cases where you'll be working on a project that is ONLY c, but I think that's more rare nowadays (if you're working in linux code for example). Pretty much every MCU toolchain should support C++ nowadays, so it's probably not worth it to have this as a requirement.
+====== Design notes ======
+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)