...
Make code less hack(athon-)y
Re-write in C++ (TBD. Requires more prototyping, determining what the software team will look like and overall avionics team goals for 2024-2025. If we go this route, these are possible libraries (which must be properly designed, discussed and documented before implementation):
Transport - Interface for inter-board communication over various protocols (UDP, LoRa, SLIP)
Event Manager - Monitor and send events over a transport interface
Actors (Pub-Sub) - Have actors/tenants that can subscribe to message ports and send messages over message ports. See about using a zbus implementation with some prototyping. See about standardizing between all ground and flight hardware, which most likely necessitates an auto-gen tool. More on this later. Maybe have actors/tenants be able to share threads, if they access a shared resource?
Sensor - Generic sensor class with subclasses that handle retrieving data automagically
State Machine - Zephyr has a very barebones implemenation. Maybe make an autogen class that other classes inherit from. Concept of events and flags. User defines what are the possible state transitions and what events/flags will trigger these state changes.
Basic CONOPs of how the above should work
Initialize
Configure transports
Set up event manager
Create actors and subscribe to ports
Create tasks and assign actors to a task
“Start the RTOS” - Just starts all the tasks
Start tasks. When each tasks starts running it will go through
Startup() - Initialize stuff
This can include sensors!
Post-Startup() - Initialize stuff that has to be done after startup
Run
Until the end of time (or if we fail out or return early)
Different boolean flags can be set, or events can occur triggering state changes causing run method to change
Sensor classes will automatically grab data if possible and signal when tasks can take that data
etc.
Hardware Simulations
ModSim - Simulate operating a single module
Simplane - Simulate the above, but they all can communicate with each other
Need to determine software stack/tools for this
QEMU
Docker
CI Checks
Unit Tests. Unit Tests. Unit Tests. Easier to do earlier on in the process. Mandate unit tests, especially when we start library development
GTest
Static analysis tools.
Coverity is a good one
Maybe also IKOS?
Address sanitizer
Valgrind
TBD: Significantly slower than address sanitizers. There are trade-offs.
Add a linter and formatter
...