Examples from example_common moved to FSFW #507
No reviewers
Labels
No Label
API Change
Breaking API Change
bug
build
cosmetics
Documentation
duplicate
feature
help wanted
hotfix
invalid
question
Refactor
Tests
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: fsfw/fsfw#507
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "mueller/examples-moved-to-fsfw"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I needed access to the TestDeviceHandler to have a Hardware independent way to test TMTC features (service 3 / service 8). The most recent version of it was in
example_common
, and multiple obsolete versions were lying around in the SOURCE and EIVE OBSW because of copying and pasting. The best solution would be to move the example modules to the FSFW so other projects and all example projects can use them as well. A lot of these modules were accumulated over time as the example grew, as part of my thesis to test new FSFW features, or as a way to test and learn the FSFW.I don't know if this is the best architectural solution and maybe you have some other ideas or improvements as well, but I don't think there is a perfect solution here. This PR moves most of the modules which were contained in
example_common
to the FSFW. These modules had some configuration dependant on the OBSWConfig.h file so I created a dedicatedExampleConfig.h.in
which allows to configure the examples (printout etc.).The modules could then be used by the various FSFW examples as well. These examples can also be used to have a way of performing integration testing.
Actually, I do not like to have the examples within the fsfw repo, at least for now.
I prefer them to be in their own repo, as they have a bit different workflow and quality promise.
If some classes are used for unit tests, I would suggest adding only these to the
tests
tree. They can then be used in the examples as well. But still, I think we should discern testing code (belongs definitely into fsfw) from example code (so far not part of fsfw).So, my strategy would be to put boilerplate code which is useful for testing into
tests
and common useful code intohal
(to be renamed at some point) and keep demo code in their own repo which can also use testing and hal code if applicable.I can see that having the examples within the same repo as the fsfw eases version control but I am afraid of too much clutter and specifics tagging along there and am not fully convinced of the maturity of the example code.
Would that be an acceptable interim solution for you?
My first approach was actually to put the TestDeviceHandler and some other modules (this is a really useful class) inside
tests/src/fsfw_tests/integration
. I can do that again and leave most of the example code insidefsfw_common
. It shuld be possible to convert preprocessor define configuration to run time configuration for the test/example classes, there might be the need of a special solution for the class and subsystem IDs though... I'd be happy with that solution.See #508 for adapted PR
I think this can be closed
Pull request closed