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:

1. learn about this could be done and give me exposure to not using C++ features
2. leave the top level structure in case we ever needed to support a platform that doesn't support C++

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.

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

class AbstractBoard {
public:
   virtual void sample(); 
   virtual void transmit(); 
};
 
class AppleBoard : public AbstractBoard{
public:
   void sample(); 
   void transmit(); 
};

The main:

loop(){
   board = AppleBoard();
   board.Sample();
   board.Transmit();
 
   // 60s sample frequency
   delay(60*1000);
}

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:

1. Review the current code and create the abstract base class
2. Implement a class for one board (apple?) that inherits from the abstract base class (essentially implementing it)
3. Test it
4. 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)

Contributing authors:

Created by kluong on 2020/10/06 14:51.