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 introduces the generation of documentation based on
this excellent blog post: https://devblogs.microsoft.com/cppblog/clear-functional-c-documentation-with-sphinx-breathe-doxygen-cmake/
It combines the tools Sphinx, Doxygen and Breathe to generate good
looking HTML documentation conveniently which can be hosted easily.
The helper scripts were unified and there is now one helper.py script
which can be used to create, build and open both tests and documentation.
"./helper.py -h" can be used to get the different options.
This PR also contains some smaller fixes which were necessary for the docs
to build
- Added unittests for `PeriodicOperationDivider` and the `bitutil` helpers
- Some API changes: Removed redundant bit part, because these functions are already in a namespace
- Some bugfixes for `PeriodicOperationDivider`
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
