Examples from example_common moved to FSFW #507

Closed
muellerr wants to merge 5 commits from mueller/examples-moved-to-fsfw into development
Owner

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 dedicated ExampleConfig.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.

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 dedicated `ExampleConfig.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.
muellerr added 3 commits 2021-10-13 11:45:27 +02:00
Owner

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 into hal (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?

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 into `hal` (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?
Author
Owner

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 inside fsfw_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.

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 inside `fsfw_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.
Author
Owner

See #508 for adapted PR

See #508 for adapted PR
muellerr added 1 commit 2021-10-18 14:44:08 +02:00
gaisser added 1 commit 2021-10-18 15:13:27 +02:00
Author
Owner

I think this can be closed

I think this can be closed
muellerr closed this pull request 2021-10-28 09:21:03 +02:00

Pull request closed

Sign in to join this conversation.
No description provided.