FSFW Internal Restructuring - Pulling HAL back into FSFW #443

New Issue

muellerr · 2021-07-13T15:01:19+02:00

muellerr commented

2021-07-13 15:01:19 +02:00

I think it would be a good idea to pull the HAL library back into the FSFW because it is tightly bound to the FSFW in some aspects, and compiling it as a separate library makes some steps a lot more complicated when using CMake.

I think it would be a good idea to rethink the internal structure of the FSFW if this is done, also keeping issue #429 in mind. A new internal structure could also be used to avoid using relativ paths in the internal include structure. This would require separating header files fron source files. The new structure could look like this

fsfw
 - core
 -- inc/fsfw
 --- returnvalues
 ---- HasReturnvaluesIF.h
 ---- ...
 -- src
 --- returnvalues
 ---- ...
 - osal
 -- inc/fsfw
 --- linux
 --- freertos
 -- src
 --- linux
 --- freertos
 - hal 
 - doc
 - contrib
 - opt
 - test

opt would contain optional components like RMAP and Datalinklayer. These would only be compiled if the user application explicitely linked against FSFW::DATALINKLAYER or FSFW::RMAP.
osal contains the OSAL, and is linked through a CMake target like FSFW::OSAL::LINUX or FSFW::OSAL::FREERTOS
contribcomponents and thehalwhich would be exposed through targers likeFSFW::HAL::STM32H7, FSFW::HAL::LINUXorFSFW::CONTRIB::SPG4`.
test contains the unittests source files, and would only be compiled when linking again FSFW::TESTS

Separating source from header files allows using something like #include "fsfw/returnvalues/HasReturnvaluesIF.h" in the framework again without changing the API for a user. This increased the number of include paths add by the FSFW (core/inc/fsfw, hal/inc/fsfw) but I don't think this is an issue.

I think it would be a good idea to pull the HAL library back into the FSFW because it is tightly bound to the FSFW in some aspects, and compiling it as a separate library makes some steps a lot more complicated when using CMake. I think it would be a good idea to rethink the internal structure of the FSFW if this is done, also keeping issue #429 in mind. A new internal structure could also be used to avoid using relativ paths in the internal include structure. This would require separating header files fron source files. The new structure could look like this ``` fsfw - core -- inc/fsfw --- returnvalues ---- HasReturnvaluesIF.h ---- ... -- src --- returnvalues ---- ... - osal -- inc/fsfw --- linux --- freertos -- src --- linux --- freertos - hal - doc - contrib - opt - test ``` 1. `opt` would contain optional components like RMAP and Datalinklayer. These would only be compiled if the user application explicitely linked against FSFW::DATALINKLAYER or FSFW::RMAP. 2. `osal` contains the OSAL, and is linked through a CMake target like `FSFW::OSAL::LINUX` or `FSFW::OSAL::FREERTOS` 3. contrib` components and the `hal` which would be exposed through targers like `FSFW::HAL::STM32H7`, `FSFW::HAL::LINUX` or `FSFW::CONTRIB::SPG4`. 4. `test` contains the unittests source files, and would only be compiled when linking again `FSFW::TESTS` Separating source from header files allows using something like `#include "fsfw/returnvalues/HasReturnvaluesIF.h"` in the framework again without changing the API for a user. This increased the number of include paths add by the FSFW (`core/inc/fsfw`, `hal/inc/fsfw`) but I don't think this is an issue.

muellerr added this to the v2.0.0 milestone 2021-07-13 15:19:55 +02:00

muellerr added the

feature

label 2021-07-13 15:20:03 +02:00

muellerr commented

2021-07-13 17:57:50 +02:00

Probably better (for developers especially):

- inc
-- fsfw
--- osal
--- hal
--- returnvalues
--- action
--- ...
- src
-- osal
-- core
-- tests
-- opt
-- hal

- contrib
- doc
- cmake

Probably better (for developers especially): ``` - inc -- fsfw --- osal --- hal --- returnvalues --- action --- ... - src -- osal -- core -- tests -- opt -- hal - contrib - doc - cmake ```

muellerr referenced this issue

2021-07-14 10:55:32 +02:00

FSFW Restructuring #445

muellerr added a new dependency 2021-07-14 11:23:42 +02:00

#445 FSFW Restructuring

muellerr removed a dependency 2021-07-14 11:23:48 +02:00

#445 FSFW Restructuring

muellerr commented

2021-09-06 13:02:24 +02:00

Was merged in #445

muellerr closed this issue

2021-09-06 13:02:24 +02:00