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);
}