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 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
