Have one interface per state machine

[jonapap]

So I've gone ahead and split the interface to be per state machine. In short:

• No more global interface configured using #if flags. Each state machine has its own interface.
• This allows a lot of #if to be removed.
• Add a DESKTOP_COMPAT flag. In the future, the intent is for this to be the only configurable flag (along with HOTFIRE_TEST and other project flags)

More refactoring/changes can still be done. However, those will probably be reserved for other PRs:

• Have 1 state object per interface/state-machine (e.g. HotFireState instead of StateData)
• Decide if SensorLogger should output CSV or Protobuf
• Move conversion from SensorLogger to each state object
• Remove TestingInterface and add the testing code to Interface.h

This is related to changes discussed here: https://avwiki.uorocketry.ca/en/Avionics/Software/Proposals/Interface-Overhaul. I figured no matter the direction we decide to take (async vs sync), we need one way or another to do this change.

[seofernando25]

What a dream <3 Good stuff, thanks!

- #if 
- #endif

What do you think of using cfg/ini files or cli args instead of defines in the future?
That way we could cut down even futher on using #ifdef USE_XXXX and even #define INTERFACE SomeInterface and that would also help to solve #142

[jonapap]

What a dream <3 Good stuff, thanks!

- #if 
- #endif

What do you think of using cfg/ini files or cli args instead of defines in the future? That way we could cut down even futher on using #ifdef USE_XXXX and even #define INTERFACE SomeInterface and that would also help to solve #142

Maybe? The thing with cfg/ini files is that they are parsed at runtime. Ideally, all those things should be figured out at compile time in some way. This produces a single binary, prevents runtime issues, and allows the compiler to optimize away unneeded stuff. Right now, my main goal is to reduce preprocessor flags to a more manageable level. I believe having a small amount of #defines is fine, as long as there isn't really another way to achieve the same behaviour.

[seofernando25]

When I run the octoberSky test, it seems the program never halts. That doesn't seem like the expected behaviour. Is it something with the state machine, threads, etc?

[jonapap]

When I run the octoberSky test, it seems the program never halts. That doesn't seem like the expected behaviour. Is it something with the state machine, threads, etc?

Are you on the latest commit? I was sure I fixed that issue. Those CI tests now pass fine.

[seofernando25]

That's weird 🤔 nevermind then...