fsfw/fsfw
11
3
Fork 6
Code Issues 32 Pull Requests 4 Releases 10 Wiki Activity

FSFW Internal Restructuring - Pulling HAL back into FSFW #443

New Issue
Closed
opened 2021-07-13 15:01:19 +02:00 by muellerr · 2 comments
muellerr commented 2021-07-13 15:01:19 +02:00
Owner
Copy Link

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. contribcomponents and thehalwhich would be exposed through targers likeFSFW::HAL::STM32H7, FSFW::HAL::LINUXorFSFW::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.

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
Author
Owner
Copy Link

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 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
Author
Owner
Copy Link

Was merged in #445

Was merged in #445
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
API Change
Changes the API, so Users need to adapted
 Breaking API Change
Changes the API in a non backwards compatible way
 bug
Something is not working
 build
Issues related to the buildsystem, including CI
 cosmetics
Small change most users won't notice
 Documentation
Improvement of code documentation
 duplicate
This issue or pull request already exists
 feature
New feature
 help wanted
Need some help
 hotfix
Quick or important fix that is merged directly into master, causing a new revision
 invalid
#worksforme
 question
More information is needed
 Refactor
Contains a refactoring of some code
 Tests
Issues related to testing code
 wontfix
This won't be fixed
No Label feature
Milestone
No items
No Milestone v2.0.0
Assignees
Clear assignees
ahinkel dwoodward gaisser hanke jenkins_buildfix lrajer meierj mohr muellerr taheran tbaumgartl
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fsfw/fsfw#443
Delete Branch "%!s()"

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?