Examples from example_common moved to FSFW #507

muellerr · 2021-10-13T11:45:26+02:00

muellerr commented

2021-10-13 11:45:26 +02:00

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

e3fb9d308c

added integration test modules

c0d560afe4

added option to add/not add integration test modules

6978869a42

moved examples modules to fsfw

mohr commented

2021-10-15 17:31:02 +02:00

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?

muellerr commented

2021-10-15 18:31:33 +02:00

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.

muellerr commented

2021-10-17 23:29:40 +02:00

See #508 for adapted PR

muellerr added 1 commit 2021-10-18 14:44:08 +02:00

c23976f8b7 Merge remote-tracking branch 'origin/development' into mueller/examples-moved-to-fsfw

gaisser added 1 commit 2021-10-18 15:13:27 +02:00

c68ac2312d Merge branch 'development' into mueller/examples-moved-to-fsfw

muellerr commented

2021-10-26 17:30:38 +02:00

I think this can be closed

muellerr closed this pull request

2021-10-28 09:21:03 +02:00