The CommandExecutor helper class can execute shell commands in blocking and non-blocking mode
This class is able to execute processes by using the Linux popen call. It also has the capability of writing
the read output of a process into a provided ring buffer.
The executor works by first loading the command which should be executed and specifying whether
it should be executed blocking or non-blocking. After that, execution can be started with the execute call.
Using non-blocking mode allows to execute commands which might take a longer time in the background,
and allowing the user thread to check completion status with the check function
Moved to HAL like requested in code review and unit tested with failing commands as well.
Also, Linux HAL components are compiled by default now unless explicitely disabled.
This PR adds the packet stack for the CCSDS File Delivery Protocol.
It also refactors the existing TMTC infastructure to allow sending
of CFDP packets to the CCSDS handlers.
This includes the whole PDU (Protocol Data Unit) stack:
- File Data PDUs
and all file directive PDUs
- ACK PDU
- NAK PDU
- Metadata PDU
- Finished PDU
- Prompt PDU
- Keep Alive PDU
- EOF PDU
The PR includes a full set of unittests for the packet stack
with a coverage of 90+ %.
The refactoring of the existing TMTC infastructure includes non-ideal
solutions like diamond inheritance.
Avoiding this solution would require refactoring the packet stack.
This would be a good idea anyway because the existing stack is tightly
coupled to the FSFW, making reuse more difficult if only the stack is
planned to be used without the store functionalities etc.
The PDU implementation provided here is only weakly coupled to the FSFW,
only using components like returnvalues or the Serialization modules.
There are dedicated serializers and deserializers, which also helps in
creating small focused modules which are easy to test.
Some of the modules here were provied by Matthias Tompert.
This PR refactores the tests so they are built as part of the FSFW.
This is done by adding Catch2 with the FetchContent directive.
A future implementation might also use a system installation of Catch2
by first checking whether Catch2 can already be found as a package
The custom configuration folder testcfg was moved from the user folder
to the actual unittest folder.
The tests can be built by setting the CMake FSFW_BUILD_UNITTESTS option
to TRUE/ON. They are built with the static library and dropped inside
the build folders fsfw directory.
1. Further reduces the amount of code the user needs to copy and paste
2. Makes FSFW tests more accessible. This can be used to simplify moving mission unit tests
to the FSFW
3. A lot of include improvements
