Merge branch 'development' into mueller/cfdp-pdus
This commit is contained in:
commit
c3a0aabfb8
@ -4,6 +4,9 @@ set(FSFW_VERSION 2)
|
|||||||
set(FSFW_SUBVERSION 0)
|
set(FSFW_SUBVERSION 0)
|
||||||
set(FSFW_REVISION 0)
|
set(FSFW_REVISION 0)
|
||||||
|
|
||||||
|
# Add the cmake folder so the FindSphinx module is found
|
||||||
|
set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH})
|
||||||
|
|
||||||
option(FSFW_GENERATE_SECTIONS
|
option(FSFW_GENERATE_SECTIONS
|
||||||
"Generate function and data sections. Required to remove unused code" ON
|
"Generate function and data sections. Required to remove unused code" ON
|
||||||
)
|
)
|
||||||
@ -12,6 +15,7 @@ if(FSFW_GENERATE_SECTIONS)
|
|||||||
endif()
|
endif()
|
||||||
|
|
||||||
option(FSFW_BUILD_UNITTESTS "Build unittest binary in addition to static library" OFF)
|
option(FSFW_BUILD_UNITTESTS "Build unittest binary in addition to static library" OFF)
|
||||||
|
option(FSFW_BUILD_DOCS "Build documentation with Sphinx and Doxygen" OFF)
|
||||||
if(FSFW_BUILD_UNITTESTS)
|
if(FSFW_BUILD_UNITTESTS)
|
||||||
option(FSFW_TESTS_GEN_COV "Generate coverage data for unittests" ON)
|
option(FSFW_TESTS_GEN_COV "Generate coverage data for unittests" ON)
|
||||||
endif()
|
endif()
|
||||||
@ -36,7 +40,9 @@ option(FSFW_ADD_SGP4_PROPAGATOR "Add SGP4 propagator code" OFF)
|
|||||||
|
|
||||||
set(LIB_FSFW_NAME fsfw)
|
set(LIB_FSFW_NAME fsfw)
|
||||||
set(FSFW_TEST_TGT fsfw-tests)
|
set(FSFW_TEST_TGT fsfw-tests)
|
||||||
|
set(FSFW_DUMMY_TGT fsfw-dummy)
|
||||||
|
|
||||||
|
project(${LIB_FSFW_NAME})
|
||||||
add_library(${LIB_FSFW_NAME})
|
add_library(${LIB_FSFW_NAME})
|
||||||
|
|
||||||
if(FSFW_BUILD_UNITTESTS)
|
if(FSFW_BUILD_UNITTESTS)
|
||||||
@ -59,7 +65,6 @@ if(FSFW_BUILD_UNITTESTS)
|
|||||||
set(FSFW_CONFIG_PATH tests/src/fsfw_tests/unit/testcfg)
|
set(FSFW_CONFIG_PATH tests/src/fsfw_tests/unit/testcfg)
|
||||||
configure_file(tests/src/fsfw_tests/unit/testcfg/FSFWConfig.h.in FSFWConfig.h)
|
configure_file(tests/src/fsfw_tests/unit/testcfg/FSFWConfig.h.in FSFWConfig.h)
|
||||||
configure_file(tests/src/fsfw_tests/unit/testcfg/TestsConfig.h.in tests/TestsConfig.h)
|
configure_file(tests/src/fsfw_tests/unit/testcfg/TestsConfig.h.in tests/TestsConfig.h)
|
||||||
configure_file(tests/src/fsfw_tests/unit/testcfg/OBSWConfig.h.in OBSWConfig.h)
|
|
||||||
|
|
||||||
project(${FSFW_TEST_TGT} CXX C)
|
project(${FSFW_TEST_TGT} CXX C)
|
||||||
add_executable(${FSFW_TEST_TGT})
|
add_executable(${FSFW_TEST_TGT})
|
||||||
@ -147,7 +152,7 @@ else()
|
|||||||
set(OS_FSFW "host")
|
set(OS_FSFW "host")
|
||||||
endif()
|
endif()
|
||||||
|
|
||||||
if(FSFW_BUILD_UNITTESTS)
|
if(FSFW_BUILD_UNITTESTS OR FSFW_BUILD_DOCS)
|
||||||
configure_file(src/fsfw/FSFW.h.in fsfw/FSFW.h)
|
configure_file(src/fsfw/FSFW.h.in fsfw/FSFW.h)
|
||||||
configure_file(src/fsfw/FSFWVersion.h.in fsfw/FSFWVersion.h)
|
configure_file(src/fsfw/FSFWVersion.h.in fsfw/FSFWVersion.h)
|
||||||
else()
|
else()
|
||||||
@ -163,6 +168,9 @@ if(FSFW_ADD_HAL)
|
|||||||
add_subdirectory(hal)
|
add_subdirectory(hal)
|
||||||
endif()
|
endif()
|
||||||
add_subdirectory(contrib)
|
add_subdirectory(contrib)
|
||||||
|
if(FSFW_BUILD_DOCS)
|
||||||
|
add_subdirectory(docs)
|
||||||
|
endif()
|
||||||
|
|
||||||
if(FSFW_BUILD_UNITTESTS)
|
if(FSFW_BUILD_UNITTESTS)
|
||||||
if(FSFW_TESTS_GEN_COV)
|
if(FSFW_TESTS_GEN_COV)
|
||||||
@ -234,9 +242,11 @@ endif()
|
|||||||
# The project CMakeLists file has to set the FSFW_CONFIG_PATH and add it.
|
# The project CMakeLists file has to set the FSFW_CONFIG_PATH and add it.
|
||||||
# If this is not given, we include the default configuration and emit a warning.
|
# If this is not given, we include the default configuration and emit a warning.
|
||||||
if(NOT FSFW_CONFIG_PATH)
|
if(NOT FSFW_CONFIG_PATH)
|
||||||
message(WARNING "Flight Software Framework configuration path not set!")
|
|
||||||
set(DEF_CONF_PATH misc/defaultcfg/fsfwconfig)
|
set(DEF_CONF_PATH misc/defaultcfg/fsfwconfig)
|
||||||
message(WARNING "Setting default configuration from ${DEF_CONF_PATH} ..")
|
if(NOT FSFW_BUILD_DOCS)
|
||||||
|
message(WARNING "Flight Software Framework configuration path not set!")
|
||||||
|
message(WARNING "Setting default configuration from ${DEF_CONF_PATH} ..")
|
||||||
|
endif()
|
||||||
add_subdirectory(${DEF_CONF_PATH})
|
add_subdirectory(${DEF_CONF_PATH})
|
||||||
set(FSFW_CONFIG_PATH ${DEF_CONF_PATH})
|
set(FSFW_CONFIG_PATH ${DEF_CONF_PATH})
|
||||||
endif()
|
endif()
|
||||||
|
|||||||
18
README.md
18
README.md
@ -42,7 +42,7 @@ There are some functions like `printChar` which are different depending on the t
|
|||||||
and need to be implemented by the mission developer.
|
and need to be implemented by the mission developer.
|
||||||
|
|
||||||
A template configuration folder was provided and can be copied into the project root to have
|
A template configuration folder was provided and can be copied into the project root to have
|
||||||
a starting point. The [configuration section](doc/README-config.md#top) provides more specific
|
a starting point. The [configuration section](docs/README-config.md#top) provides more specific
|
||||||
information about the possible options.
|
information about the possible options.
|
||||||
|
|
||||||
## Adding the library
|
## Adding the library
|
||||||
@ -109,14 +109,14 @@ The `coverage.py` script located in the `script` folder can also be used to do t
|
|||||||
|
|
||||||
## Index
|
## Index
|
||||||
|
|
||||||
[1. High-level overview](doc/README-highlevel.md#top) <br>
|
[1. High-level overview](docs/README-highlevel.md#top) <br>
|
||||||
[2. Core components](doc/README-core.md#top) <br>
|
[2. Core components](docs/README-core.md#top) <br>
|
||||||
[3. Configuration](doc/README-config.md#top) <br>
|
[3. Configuration](docs/README-config.md#top) <br>
|
||||||
[4. OSAL overview](doc/README-osal.md#top) <br>
|
[4. OSAL overview](docs/README-osal.md#top) <br>
|
||||||
[5. PUS services](doc/README-pus.md#top) <br>
|
[5. PUS services](docs/README-pus.md#top) <br>
|
||||||
[6. Device Handler overview](doc/README-devicehandlers.md#top) <br>
|
[6. Device Handler overview](docs/README-devicehandlers.md#top) <br>
|
||||||
[7. Controller overview](doc/README-controllers.md#top) <br>
|
[7. Controller overview](docs/README-controllers.md#top) <br>
|
||||||
[8. Local Data Pools](doc/README-localpools.md#top) <br>
|
[8. Local Data Pools](docs/README-localpools.md#top) <br>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
13
cmake/FindSphinx.cmake
Normal file
13
cmake/FindSphinx.cmake
Normal file
@ -0,0 +1,13 @@
|
|||||||
|
# Look for an executable called sphinx-build
|
||||||
|
find_program(SPHINX_EXECUTABLE
|
||||||
|
NAMES sphinx-build
|
||||||
|
DOC "Path to sphinx-build executable")
|
||||||
|
|
||||||
|
include(FindPackageHandleStandardArgs)
|
||||||
|
|
||||||
|
# Handle standard arguments to find_package like REQUIRED and QUIET
|
||||||
|
find_package_handle_standard_args(
|
||||||
|
Sphinx
|
||||||
|
"Failed to find sphinx-build executable"
|
||||||
|
SPHINX_EXECUTABLE
|
||||||
|
)
|
||||||
66
docs/CMakeLists.txt
Normal file
66
docs/CMakeLists.txt
Normal file
@ -0,0 +1,66 @@
|
|||||||
|
# This is based on this excellent posting provided by Sy:
|
||||||
|
# https://devblogs.microsoft.com/cppblog/clear-functional-c-documentation-with-sphinx-breathe-doxygen-cmake/
|
||||||
|
find_package(Doxygen REQUIRED)
|
||||||
|
find_package(Sphinx REQUIRED)
|
||||||
|
|
||||||
|
get_target_property(LIB_FSFW_PUBLIC_HEADER_DIRS ${LIB_FSFW_NAME} INTERFACE_INCLUDE_DIRECTORIES)
|
||||||
|
# TODO: Add HAL as well
|
||||||
|
file(GLOB_RECURSE LIB_FSFW_PUBLIC_HEADERS ${PROJECT_SOURCE_DIR}/src/*.h)
|
||||||
|
file(GLOB_RECURSE RST_DOC_FILES ${PROJECT_SOURCE_DIR}/docs/*.rst)
|
||||||
|
|
||||||
|
set(DOXYGEN_INPUT_DIR ${PROJECT_SOURCE_DIR}/src)
|
||||||
|
set(DOXYGEN_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR}/doxygen)
|
||||||
|
set(DOXYGEN_INDEX_FILE ${DOXYGEN_OUTPUT_DIR}/xml/index.xml)
|
||||||
|
set(DOXYFILE_IN ${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in)
|
||||||
|
set(DOXYFILE_OUT ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile)
|
||||||
|
|
||||||
|
# Replace variables inside @@ with the current values
|
||||||
|
configure_file(${DOXYFILE_IN} ${DOXYFILE_OUT} @ONLY)
|
||||||
|
|
||||||
|
# Doxygen won't create this for us
|
||||||
|
file(MAKE_DIRECTORY ${DOXYGEN_OUTPUT_DIR})
|
||||||
|
|
||||||
|
# Only regenerate Doxygen when the Doxyfile or public headers change
|
||||||
|
add_custom_command(
|
||||||
|
OUTPUT ${DOXYGEN_INDEX_FILE}
|
||||||
|
DEPENDS ${LIB_FSFW_PUBLIC_HEADERS}
|
||||||
|
COMMAND ${DOXYGEN_EXECUTABLE} ${DOXYFILE_OUT}
|
||||||
|
MAIN_DEPENDENCY ${DOXYFILE_OUT} ${DOXYFILE_IN}
|
||||||
|
COMMENT "Generating docs"
|
||||||
|
VERBATIM
|
||||||
|
)
|
||||||
|
|
||||||
|
# Nice named target so we can run the job easily
|
||||||
|
add_custom_target(Doxygen ALL DEPENDS ${DOXYGEN_INDEX_FILE})
|
||||||
|
|
||||||
|
set(SPHINX_SOURCE ${CMAKE_CURRENT_SOURCE_DIR})
|
||||||
|
set(SPHINX_BUILD ${CMAKE_CURRENT_BINARY_DIR}/sphinx)
|
||||||
|
set(SPHINX_INDEX_FILE ${SPHINX_BUILD}/index.html)
|
||||||
|
|
||||||
|
# Only regenerate Sphinx when:
|
||||||
|
# - Doxygen has rerun
|
||||||
|
# - Our doc files have been updated
|
||||||
|
# - The Sphinx config has been updated
|
||||||
|
add_custom_command(
|
||||||
|
OUTPUT ${SPHINX_INDEX_FILE}
|
||||||
|
COMMAND
|
||||||
|
${SPHINX_EXECUTABLE} -b html
|
||||||
|
# Tell Breathe where to find the Doxygen output
|
||||||
|
-Dbreathe_projects.fsfw=${DOXYGEN_OUTPUT_DIR}/xml
|
||||||
|
${SPHINX_SOURCE} ${SPHINX_BUILD}
|
||||||
|
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
|
||||||
|
DEPENDS
|
||||||
|
# Other docs files you want to track should go here (or in some variable)
|
||||||
|
${RST_DOC_FILES}
|
||||||
|
${DOXYGEN_INDEX_FILE}
|
||||||
|
MAIN_DEPENDENCY ${SPHINX_SOURCE}/conf.py
|
||||||
|
COMMENT "Generating documentation with Sphinx"
|
||||||
|
)
|
||||||
|
|
||||||
|
# Nice named target so we can run the job easily
|
||||||
|
add_custom_target(Sphinx ALL DEPENDS ${SPHINX_INDEX_FILE})
|
||||||
|
|
||||||
|
# Add an install target to install the docs
|
||||||
|
include(GNUInstallDirs)
|
||||||
|
install(DIRECTORY ${SPHINX_BUILD}
|
||||||
|
DESTINATION ${CMAKE_INSTALL_DOCDIR})
|
||||||
7
docs/Doxyfile.in
Normal file
7
docs/Doxyfile.in
Normal file
@ -0,0 +1,7 @@
|
|||||||
|
INPUT = "@DOXYGEN_INPUT_DIR@"
|
||||||
|
|
||||||
|
RECURSIVE = YES
|
||||||
|
|
||||||
|
OUTPUT_DIRECTORY = "@DOXYGEN_OUTPUT_DIR@"
|
||||||
|
|
||||||
|
GENERATE_XML = YES
|
||||||
20
docs/Makefile
Normal file
20
docs/Makefile
Normal file
@ -0,0 +1,20 @@
|
|||||||
|
# Minimal makefile for Sphinx documentation
|
||||||
|
#
|
||||||
|
|
||||||
|
# You can set these variables from the command line, and also
|
||||||
|
# from the environment for the first two.
|
||||||
|
SPHINXOPTS ?=
|
||||||
|
SPHINXBUILD ?= sphinx-build
|
||||||
|
SOURCEDIR = .
|
||||||
|
BUILDDIR = _build
|
||||||
|
|
||||||
|
# Put it first so that "make" without argument is like "make help".
|
||||||
|
help:
|
||||||
|
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||||
|
|
||||||
|
.PHONY: help Makefile
|
||||||
|
|
||||||
|
# Catch-all target: route all unknown targets to Sphinx using the new
|
||||||
|
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
|
||||||
|
%: Makefile
|
||||||
|
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||||
@ -31,7 +31,9 @@ cohesive pool variables. These sets simply iterator over the list of variables a
|
|||||||
`read` and `commit` functions of each variable. The following diagram shows the
|
`read` and `commit` functions of each variable. The following diagram shows the
|
||||||
high-level architecture of the local data pools.
|
high-level architecture of the local data pools.
|
||||||
|
|
||||||
<img align="center" src="./images/PoolArchitecture.png" width="50%"> <br>
|
.. image:: ../misc/logo/FSFW_Logo_V3_bw.png
|
||||||
|
:alt: FSFW Logo
|
||||||
|
|
||||||
|
|
||||||
An example is shown for using the local data pools with a Gyroscope.
|
An example is shown for using the local data pools with a Gyroscope.
|
||||||
For example, the following code shows an implementation to access data from a Gyroscope taken
|
For example, the following code shows an implementation to access data from a Gyroscope taken
|
||||||
16
docs/api.rst
Normal file
16
docs/api.rst
Normal file
@ -0,0 +1,16 @@
|
|||||||
|
API
|
||||||
|
====
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 4
|
||||||
|
|
||||||
|
api/objectmanager
|
||||||
|
api/task
|
||||||
|
api/ipc
|
||||||
|
api/returnvalue
|
||||||
|
api/event
|
||||||
|
api/modes
|
||||||
|
api/health
|
||||||
|
api/action
|
||||||
|
api/devicehandler
|
||||||
|
api/controller
|
||||||
15
docs/api/action.rst
Normal file
15
docs/api/action.rst
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
Action Module API
|
||||||
|
=================
|
||||||
|
|
||||||
|
``ActionHelper``
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
.. doxygenclass:: ActionHelper
|
||||||
|
:members:
|
||||||
|
|
||||||
|
``HasActionsIF``
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
.. doxygenclass:: HasActionsIF
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
16
docs/api/controller.rst
Normal file
16
docs/api/controller.rst
Normal file
@ -0,0 +1,16 @@
|
|||||||
|
Controller API
|
||||||
|
=================
|
||||||
|
|
||||||
|
``ControllerBase``
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: ControllerBase
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
|
|
||||||
|
``ExtendedControllerBase``
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: ExtendedControllerBase
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
16
docs/api/devicehandler.rst
Normal file
16
docs/api/devicehandler.rst
Normal file
@ -0,0 +1,16 @@
|
|||||||
|
Device Handler Base API
|
||||||
|
=========================
|
||||||
|
|
||||||
|
``DeviceHandlerBase``
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: DeviceHandlerBase
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
|
|
||||||
|
``DeviceHandlerIF``
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: DeviceHandlerIF
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
6
docs/api/event.rst
Normal file
6
docs/api/event.rst
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
.. _eventapi:
|
||||||
|
|
||||||
|
Event API
|
||||||
|
============
|
||||||
|
|
||||||
|
.. doxygenfile:: Event.h
|
||||||
9
docs/api/health.rst
Normal file
9
docs/api/health.rst
Normal file
@ -0,0 +1,9 @@
|
|||||||
|
Health API
|
||||||
|
===========
|
||||||
|
|
||||||
|
``HasHealthIF``
|
||||||
|
------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: HasHealthIF
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
9
docs/api/ipc.rst
Normal file
9
docs/api/ipc.rst
Normal file
@ -0,0 +1,9 @@
|
|||||||
|
IPC Module API
|
||||||
|
=================
|
||||||
|
|
||||||
|
``MessageQueueIF``
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: MessageQueueIF
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
10
docs/api/modes.rst
Normal file
10
docs/api/modes.rst
Normal file
@ -0,0 +1,10 @@
|
|||||||
|
Modes API
|
||||||
|
=========
|
||||||
|
|
||||||
|
|
||||||
|
``HasModesIF``
|
||||||
|
---------------
|
||||||
|
|
||||||
|
.. doxygenclass:: HasModesIF
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
30
docs/api/objectmanager.rst
Normal file
30
docs/api/objectmanager.rst
Normal file
@ -0,0 +1,30 @@
|
|||||||
|
Object Manager API
|
||||||
|
=========================
|
||||||
|
|
||||||
|
``SystemObject``
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: SystemObject
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
|
|
||||||
|
``ObjectManager``
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: ObjectManager
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
|
|
||||||
|
``SystemObjectIF``
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: SystemObjectIF
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
|
|
||||||
|
``ObjectManagerIF``
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: ObjectManagerIF
|
||||||
|
:members:
|
||||||
|
:protected-members:
|
||||||
10
docs/api/returnvalue.rst
Normal file
10
docs/api/returnvalue.rst
Normal file
@ -0,0 +1,10 @@
|
|||||||
|
.. _retvalapi:
|
||||||
|
|
||||||
|
Returnvalue API
|
||||||
|
==================
|
||||||
|
|
||||||
|
.. doxygenfile:: HasReturnvaluesIF.h
|
||||||
|
|
||||||
|
.. _fwclassids:
|
||||||
|
|
||||||
|
.. doxygenfile:: FwClassIds.h
|
||||||
8
docs/api/task.rst
Normal file
8
docs/api/task.rst
Normal file
@ -0,0 +1,8 @@
|
|||||||
|
Task API
|
||||||
|
=========
|
||||||
|
|
||||||
|
``ExecutableObjectIF``
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
.. doxygenclass:: ExecutableObjectIF
|
||||||
|
:members:
|
||||||
56
docs/conf.py
Normal file
56
docs/conf.py
Normal file
@ -0,0 +1,56 @@
|
|||||||
|
# Configuration file for the Sphinx documentation builder.
|
||||||
|
#
|
||||||
|
# This file only contains a selection of the most common options. For a full
|
||||||
|
# list see the documentation:
|
||||||
|
# https://www.sphinx-doc.org/en/master/usage/configuration.html
|
||||||
|
|
||||||
|
# -- Path setup --------------------------------------------------------------
|
||||||
|
|
||||||
|
# If extensions (or modules to document with autodoc) are in another directory,
|
||||||
|
# add these directories to sys.path here. If the directory is relative to the
|
||||||
|
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||||
|
#
|
||||||
|
# import os
|
||||||
|
# import sys
|
||||||
|
# sys.path.insert(0, os.path.abspath('.'))
|
||||||
|
|
||||||
|
|
||||||
|
# -- Project information -----------------------------------------------------
|
||||||
|
|
||||||
|
project = 'Flight Software Framework'
|
||||||
|
copyright = '2021, Institute of Space Systems (IRS)'
|
||||||
|
author = 'Institute of Space Systems (IRS)'
|
||||||
|
|
||||||
|
# The full version, including alpha/beta/rc tags
|
||||||
|
release = '2.0.1'
|
||||||
|
|
||||||
|
|
||||||
|
# -- General configuration ---------------------------------------------------
|
||||||
|
|
||||||
|
# Add any Sphinx extension module names here, as strings. They can be
|
||||||
|
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||||
|
# ones.
|
||||||
|
extensions = [ "breathe" ]
|
||||||
|
|
||||||
|
breathe_default_project = "fsfw"
|
||||||
|
|
||||||
|
# Add any paths that contain templates here, relative to this directory.
|
||||||
|
templates_path = ['_templates']
|
||||||
|
|
||||||
|
# List of patterns, relative to source directory, that match files and
|
||||||
|
# directories to ignore when looking for source files.
|
||||||
|
# This pattern also affects html_static_path and html_extra_path.
|
||||||
|
exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
|
||||||
|
|
||||||
|
|
||||||
|
# -- Options for HTML output -------------------------------------------------
|
||||||
|
|
||||||
|
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||||
|
# a list of builtin themes.
|
||||||
|
#
|
||||||
|
html_theme = 'alabaster'
|
||||||
|
|
||||||
|
# Add any paths that contain custom static files (such as style sheets) here,
|
||||||
|
# relative to this directory. They are copied after the builtin static files,
|
||||||
|
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||||
|
html_static_path = []
|
||||||
41
docs/config.rst
Normal file
41
docs/config.rst
Normal file
@ -0,0 +1,41 @@
|
|||||||
|
Configuring the FSFW
|
||||||
|
=====================
|
||||||
|
|
||||||
|
The FSFW can be configured via the ``fsfwconfig`` folder. A template folder has been provided in
|
||||||
|
``misc/defaultcfg`` to have a starting point for this. The folder should be added
|
||||||
|
to the include path. The primary configuration file is the ``FSFWConfig.h`` folder. Some
|
||||||
|
of the available options will be explained in more detail here.
|
||||||
|
|
||||||
|
Auto-Translation of Events
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
The FSFW allows the automatic translation of events, which allows developers to track triggered
|
||||||
|
events directly via console output. Using this feature requires:
|
||||||
|
|
||||||
|
1. ``FSFW_OBJ_EVENT_TRANSLATION`` set to 1 in the configuration file.
|
||||||
|
2. Special auto-generated translation files which translate event IDs and object IDs into
|
||||||
|
human readable strings. These files can be generated using the
|
||||||
|
`fsfwgen Python scripts <https://egit.irs.uni-stuttgart.de/fsfw/fsfw-gen>`_.
|
||||||
|
3. The generated translation files for the object IDs should be named ``translatesObjects.cpp``
|
||||||
|
and ``translateObjects.h`` and should be copied to the ``fsfwconfig/objects`` folder
|
||||||
|
4. The generated translation files for the event IDs should be named ``translateEvents.cpp`` and
|
||||||
|
``translateEvents.h`` and should be copied to the ``fsfwconfig/events`` folder
|
||||||
|
|
||||||
|
An example implementations of these translation file generators can be found as part
|
||||||
|
of the `SOURCE project here <https://git.ksat-stuttgart.de/source/sourceobsw/-/tree/develop/generators>`_
|
||||||
|
or the `FSFW example <https://egit.irs.uni-stuttgart.de/fsfw/fsfw-example-hosted/src/branch/master/generators>`_
|
||||||
|
|
||||||
|
Configuring the Event Manager
|
||||||
|
----------------------------------
|
||||||
|
|
||||||
|
The number of allowed subscriptions can be modified with the following
|
||||||
|
parameters:
|
||||||
|
|
||||||
|
.. code-block:: cpp
|
||||||
|
|
||||||
|
namespace fsfwconfig {
|
||||||
|
//! Configure the allocated pool sizes for the event manager.
|
||||||
|
static constexpr size_t FSFW_EVENTMGMR_MATCHTREE_NODES = 240;
|
||||||
|
static constexpr size_t FSFW_EVENTMGMT_EVENTIDMATCHERS = 120;
|
||||||
|
static constexpr size_t FSFW_EVENTMGMR_RANGEMATCHERS = 120;
|
||||||
|
}
|
||||||
2
docs/controllers.rst
Normal file
2
docs/controllers.rst
Normal file
@ -0,0 +1,2 @@
|
|||||||
|
Controllers
|
||||||
|
=============
|
||||||
70
docs/core.rst
Normal file
70
docs/core.rst
Normal file
@ -0,0 +1,70 @@
|
|||||||
|
.. _core:
|
||||||
|
|
||||||
|
Core Modules
|
||||||
|
=============
|
||||||
|
|
||||||
|
The core modules provide the most important functionalities of the Flight Software Framework.
|
||||||
|
|
||||||
|
Clock
|
||||||
|
------
|
||||||
|
|
||||||
|
- This is a class of static functions that can be used at anytime
|
||||||
|
- Leap Seconds must be set if any time conversions from UTC to other times is used
|
||||||
|
|
||||||
|
Object Manager
|
||||||
|
---------------
|
||||||
|
|
||||||
|
- Must be created during program startup
|
||||||
|
- The component which handles all references. All :cpp:class:`SystemObject`\s register at this
|
||||||
|
component.
|
||||||
|
- All :cpp:class:`SystemObject`\s needs to have a unique Object ID. Those can be managed like
|
||||||
|
framework objects.
|
||||||
|
- A reference to an object can be retrieved by calling the ``get`` function of
|
||||||
|
:cpp:class:`ObjectManagerIF`. The target type must be specified as a template argument.
|
||||||
|
A ``nullptr`` check of the returning pointer must be done. This function is based on
|
||||||
|
run-time type information.
|
||||||
|
|
||||||
|
.. code-block:: cpp
|
||||||
|
|
||||||
|
template <typename T> T* ObjectManagerIF::get(object_id_t id);
|
||||||
|
|
||||||
|
- A typical way to create all objects on startup is a handing a static produce function to the
|
||||||
|
ObjectManager on creation. By calling ``ObjectManager::instance()->initialize(produceFunc)`` the
|
||||||
|
produce function will be called and all :cpp:class:`SystemObject`\s will be initialized
|
||||||
|
afterwards.
|
||||||
|
|
||||||
|
Event Manager
|
||||||
|
---------------
|
||||||
|
|
||||||
|
- Component which allows routing of events
|
||||||
|
- Other objects can subscribe to specific events, ranges of events or all events of an object.
|
||||||
|
- Subscriptions can be done during runtime but should be done during initialization
|
||||||
|
- Amounts of allowed subscriptions can be configured in ``FSFWConfig.h``
|
||||||
|
|
||||||
|
Health Table
|
||||||
|
---------------
|
||||||
|
|
||||||
|
- A component which holds every health state
|
||||||
|
- Provides a thread safe way to access all health states without the need of message exchanges
|
||||||
|
|
||||||
|
Stores
|
||||||
|
--------------
|
||||||
|
|
||||||
|
- The message based communication can only exchange a few bytes of information inside the message
|
||||||
|
itself. Therefore, additional information can be exchanged with Stores. With this, only the
|
||||||
|
store address must be exchanged in the message.
|
||||||
|
- Internally, the FSFW uses an IPC Store to exchange data between processes. For incoming TCs a TC
|
||||||
|
Store is used. For outgoing TM a TM store is used.
|
||||||
|
- All of them should use the Thread Safe Class storagemanager/PoolManager
|
||||||
|
|
||||||
|
Tasks
|
||||||
|
---------
|
||||||
|
|
||||||
|
There are two different types of tasks:
|
||||||
|
|
||||||
|
- The PeriodicTask just executes objects that are of type ExecutableObjectIF in the order of the
|
||||||
|
insertion to the Tasks.
|
||||||
|
- FixedTimeslotTask executes a list of calls in the order of the given list. This is intended for
|
||||||
|
DeviceHandlers, where polling should be in a defined order. An example can be found in
|
||||||
|
``defaultcfg/fsfwconfig/pollingSequence`` folder
|
||||||
|
|
||||||
3
docs/devicehandlers.rst
Normal file
3
docs/devicehandlers.rst
Normal file
@ -0,0 +1,3 @@
|
|||||||
|
Device Handlers
|
||||||
|
==================
|
||||||
|
|
||||||
115
docs/getting_started.rst
Normal file
115
docs/getting_started.rst
Normal file
@ -0,0 +1,115 @@
|
|||||||
|
Getting Started
|
||||||
|
================
|
||||||
|
|
||||||
|
|
||||||
|
Getting started
|
||||||
|
----------------
|
||||||
|
|
||||||
|
The `Hosted FSFW example`_ provides a good starting point and a demo to see the FSFW capabilities.
|
||||||
|
It is recommended to get started by building and playing around with the demo application.
|
||||||
|
There are also other examples provided for all OSALs using the popular embedded platforms
|
||||||
|
Raspberry Pi, Beagle Bone Black and STM32H7.
|
||||||
|
|
||||||
|
Generally, the FSFW is included in a project by providing
|
||||||
|
a configuration folder, building the static library and linking against it.
|
||||||
|
There are some functions like ``printChar`` which are different depending on the target architecture
|
||||||
|
and need to be implemented by the mission developer.
|
||||||
|
|
||||||
|
A template configuration folder was provided and can be copied into the project root to have
|
||||||
|
a starting point. The [configuration section](docs/README-config.md#top) provides more specific
|
||||||
|
information about the possible options.
|
||||||
|
|
||||||
|
Adding the library
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
The following steps show how to add and use FSFW components. It is still recommended to
|
||||||
|
try out the example mentioned above to get started, but the following steps show how to
|
||||||
|
add and link against the FSFW library in general.
|
||||||
|
|
||||||
|
1. Add this repository as a submodule
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
git submodule add https://egit.irs.uni-stuttgart.de/fsfw/fsfw.git fsfw
|
||||||
|
|
||||||
|
2. Add the following directive inside the uppermost ``CMakeLists.txt`` file of your project
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
add_subdirectory(fsfw)
|
||||||
|
|
||||||
|
3. Make sure to provide a configuration folder and supply the path to that folder with
|
||||||
|
the `FSFW_CONFIG_PATH` CMake variable from the uppermost `CMakeLists.txt` file.
|
||||||
|
It is also necessary to provide the `printChar` function. You can find an example
|
||||||
|
implementation for a hosted build
|
||||||
|
`here <https://egit.irs.uni-stuttgart.de/fsfw/fsfw-example-hosted/src/branch/master/bsp_hosted/utility/printChar.c>`_.
|
||||||
|
|
||||||
|
4. Link against the FSFW library
|
||||||
|
|
||||||
|
.. code-block:: cmake
|
||||||
|
|
||||||
|
target_link_libraries(<YourProjectName> PRIVATE fsfw)
|
||||||
|
|
||||||
|
|
||||||
|
5. It should now be possible use the FSFW as a static library from the user code.
|
||||||
|
|
||||||
|
Building the unittests
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
The FSFW also has unittests which use the `Catch2 library`_.
|
||||||
|
These are built by setting the CMake option ``FSFW_BUILD_UNITTESTS`` to ``ON`` or `TRUE`
|
||||||
|
from your project `CMakeLists.txt` file or from the command line.
|
||||||
|
|
||||||
|
The fsfw-tests binary will be built as part of the static library and dropped alongside it.
|
||||||
|
If the unittests are built, the library and the tests will be built with coverage information by
|
||||||
|
default. This can be disabled by setting the `FSFW_TESTS_COV_GEN` option to `OFF` or `FALSE`.
|
||||||
|
|
||||||
|
You can use the following commands inside the ``fsfw`` folder to set up the build system
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
mkdir build-tests && cd build-tests
|
||||||
|
cmake -DFSFW_BUILD_UNITTESTS=ON -DFSFW_OSAL=host ..
|
||||||
|
|
||||||
|
|
||||||
|
You can also use ``-DFSFW_OSAL=linux`` on Linux systems.
|
||||||
|
|
||||||
|
Coverage data in HTML format can be generated using the `Code coverage`_ CMake module.
|
||||||
|
To build the unittests, run them and then generare the coverage data in this format,
|
||||||
|
the following command can be used inside the build directory after the build system was set up
|
||||||
|
|
||||||
|
.. code-block:: console
|
||||||
|
|
||||||
|
cmake --build . -- fsfw-tests_coverage -j
|
||||||
|
|
||||||
|
|
||||||
|
The ``helper.py`` script located in the ``script`` folder can also be used to create, build
|
||||||
|
and open the unittests conveniently. Try ``helper.py -h`` for more information.
|
||||||
|
|
||||||
|
Building the documentation
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
The FSFW documentation is built using the tools Sphinx, doxygen and breathe based on the
|
||||||
|
instructions provided in `this blogpost <https://devblogs.microsoft.com/cppblog/clear-functional-c-documentation-with-sphinx-breathe-doxygen-cmake/>`_. You can set up a
|
||||||
|
documentation build system using the following commands
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
mkdir build-docs && cd build-docs
|
||||||
|
cmake -DFSFW_BUILD_DOCS=ON -DFSFW_OSAL=host ..
|
||||||
|
|
||||||
|
Then you can generate the documentation using
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
cmake --build . -j
|
||||||
|
|
||||||
|
You can find the generated documentation inside the ``docs/sphinx`` folder inside the build
|
||||||
|
folder. Simply open the ``index.html`` in the webbrowser of your choice.
|
||||||
|
|
||||||
|
The ``helper.py`` script located in the ``script`` folder can also be used to create, build
|
||||||
|
and open the documentation conveniently. Try ``helper.py -h`` for more information.
|
||||||
|
|
||||||
|
.. _`Hosted FSFW example`: https://egit.irs.uni-stuttgart.de/fsfw/fsfw-example-hosted
|
||||||
|
.. _`Catch2 library`: https://github.com/catchorg/Catch2
|
||||||
|
.. _`Code coverage`: https://github.com/bilke/cmake-modules/tree/master
|
||||||
149
docs/highlevel.rst
Normal file
149
docs/highlevel.rst
Normal file
@ -0,0 +1,149 @@
|
|||||||
|
.. _highlevel:
|
||||||
|
|
||||||
|
High-level overview
|
||||||
|
===================
|
||||||
|
|
||||||
|
Structure
|
||||||
|
----------
|
||||||
|
|
||||||
|
The general structure is driven by the usage of interfaces provided by objects.
|
||||||
|
The FSFW uses C++11 as baseline. The intention behind this is that this C++ Standard should be
|
||||||
|
widely available, even with older compilers.
|
||||||
|
The FSFW uses dynamic allocation during the initialization but provides static containers during runtime.
|
||||||
|
This simplifies the instantiation of objects and allows the usage of some standard containers.
|
||||||
|
Dynamic Allocation after initialization is discouraged and different solutions are provided in the
|
||||||
|
FSFW to achieve that. The fsfw uses run-time type information but exceptions are not allowed.
|
||||||
|
|
||||||
|
Failure Handling
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Functions should return a defined :cpp:type:`ReturnValue_t` to signal to the caller that something has
|
||||||
|
gone wrong. Returnvalues must be unique. For this the function :cpp:func:`HasReturnvaluesIF::makeReturnCode`
|
||||||
|
or the :ref:`macro MAKE_RETURN_CODE <retvalapi>` can be used. The ``CLASS_ID`` is a unique ID for that type of object.
|
||||||
|
See the :ref:`FSFW Class IDs file <fwclassids>`. The user can add custom ``CLASS_ID``\s via the
|
||||||
|
``fsfwconfig`` folder.
|
||||||
|
|
||||||
|
OSAL
|
||||||
|
------------
|
||||||
|
|
||||||
|
The FSFW provides operation system abstraction layers for Linux, FreeRTOS and RTEMS.
|
||||||
|
The OSAL provides periodic tasks, message queues, clocks and semaphores as well as mutexes.
|
||||||
|
The :ref:`OSAL README <osal>` provides more detailed information on provided components
|
||||||
|
and how to use them.
|
||||||
|
|
||||||
|
Core Components
|
||||||
|
----------------
|
||||||
|
|
||||||
|
The FSFW has following core components. More detailed informations can be found in the
|
||||||
|
:ref:`core component section <core>`:
|
||||||
|
|
||||||
|
1. Tasks: Abstraction for different (periodic) task types like periodic tasks or tasks
|
||||||
|
with fixed timeslots
|
||||||
|
2. ObjectManager: This module stores all `SystemObjects` by mapping a provided unique object ID
|
||||||
|
to the object handles.
|
||||||
|
3. Static Stores: Different stores are provided to store data of variable size (like telecommands
|
||||||
|
or small telemetry) in a pool structure without using dynamic memory allocation.
|
||||||
|
These pools are allocated up front.
|
||||||
|
4. Clock: This module provided common time related functions
|
||||||
|
5. EventManager: This module allows routing of events generated by `SystemObjects`
|
||||||
|
6. HealthTable: A component which stores the health states of objects
|
||||||
|
|
||||||
|
Static IDs in the framework
|
||||||
|
--------------------------------
|
||||||
|
|
||||||
|
Some parts of the framework use a static routing address for communication.
|
||||||
|
An example setup of IDs can be found in the example config in ``misc/defaultcfg/fsfwconfig/objects``
|
||||||
|
inside the function ``Factory::setStaticFrameworkObjectIds``.
|
||||||
|
|
||||||
|
Events
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Events are tied to objects. EventIds can be generated by calling the
|
||||||
|
:ref:`macro MAKE_EVENT <eventapi>` or the function :cpp:func:`event::makeEvent`.
|
||||||
|
This works analog to the returnvalues. Every object that needs own Event IDs has to get a
|
||||||
|
unique ``SUBSYSTEM_ID``. Every :cpp:class:`SystemObject` can call
|
||||||
|
:cpp:func:`SystemObject::triggerEvent` from the parent class.
|
||||||
|
Therefore, event messages contain the specific EventId and the objectId of the object that
|
||||||
|
has triggered.
|
||||||
|
|
||||||
|
Internal Communication
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
Components communicate mostly via Messages through Queues.
|
||||||
|
Those queues are created by calling the singleton ``QueueFactory::instance()->create`` which
|
||||||
|
will create `MessageQueue` instances for the used OSAL.
|
||||||
|
|
||||||
|
External Communication
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
The external communication with the mission control system is mostly up to the user implementation.
|
||||||
|
The FSFW provides PUS Services which can be used to but don't need to be used.
|
||||||
|
The services can be seen as a conversion from a TC to a message based communication and back.
|
||||||
|
|
||||||
|
TMTC Communication
|
||||||
|
~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The FSFW provides some components to facilitate TMTC handling via the PUS commands.
|
||||||
|
For example, a UDP or TCP PUS server socket can be opened on a specific port using the
|
||||||
|
files located in ``osal/common``. The FSFW example uses this functionality to allow sending
|
||||||
|
telecommands and receiving telemetry using the
|
||||||
|
`TMTC commander application <https://github.com/robamu-org/tmtccmd>`_.
|
||||||
|
|
||||||
|
Simple commands like the PUS Service 17 ping service can be tested by simply running the
|
||||||
|
``tmtc_client_cli.py`` or ``tmtc_client_gui.py`` utility in
|
||||||
|
the `example tmtc folder <https://egit.irs.uni-stuttgart.de/fsfw/fsfw_example_public/src/branch/master/tmtc>`_
|
||||||
|
while the `fsfw_example` application is running.
|
||||||
|
|
||||||
|
More generally, any class responsible for handling incoming telecommands and sending telemetry
|
||||||
|
can implement the generic ``TmTcBridge`` class located in ``tmtcservices``. Many applications
|
||||||
|
also use a dedicated polling task for reading telecommands which passes telecommands
|
||||||
|
to the ``TmTcBridge`` implementation.
|
||||||
|
|
||||||
|
CCSDS Frames, CCSDS Space Packets and PUS
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
If the communication is based on CCSDS Frames and Space Packets, several classes can be used to
|
||||||
|
distributed the packets to the corresponding services. Those can be found in ``tcdistribution``.
|
||||||
|
If Space Packets are used, a timestamper has to be provided by the user.
|
||||||
|
An example can be found in the ``timemanager`` folder, which uses ``CCSDSTime::CDS_short``.
|
||||||
|
|
||||||
|
Device Handlers
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
DeviceHandlers are another important component of the FSFW. The idea is, to have a software
|
||||||
|
counterpart of every physical device to provide a simple mode, health and commanding interface.
|
||||||
|
By separating the underlying Communication Interface with
|
||||||
|
``DeviceCommunicationIF``, a device handler (DH) can be tested on different hardware.
|
||||||
|
The DH has mechanisms to monitor the communication with the physical device which allow
|
||||||
|
for FDIR reaction. Device Handlers can be created by implementing ``DeviceHandlerBase``.
|
||||||
|
A standard FDIR component for the DH will be created automatically but can
|
||||||
|
be overwritten by the user. More information on DeviceHandlers can be found in the
|
||||||
|
related [documentation section](doc/README-devicehandlers.md#top).
|
||||||
|
|
||||||
|
Modes and Health
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
The two interfaces ``HasModesIF`` and ``HasHealthIF`` provide access for commanding and monitoring
|
||||||
|
of components. On-board mode management is implement in hierarchy system.
|
||||||
|
|
||||||
|
- Device handlers and controllers are the lowest part of the hierarchy.
|
||||||
|
- The next layer are assemblies. Those assemblies act as a component which handle
|
||||||
|
redundancies of handlers. Assemblies share a common core with the top level subsystem components
|
||||||
|
- The top level subsystem components are used to group assemblies, controllers and device handlers.
|
||||||
|
For example, a spacecraft can have a atttitude control subsystem and a power subsystem.
|
||||||
|
|
||||||
|
Those assemblies are intended to act as auto-generated components from a database which describes
|
||||||
|
the subsystem modes. The definitions contain transition and target tables which contain the DH,
|
||||||
|
Assembly and Controller Modes to be commanded.
|
||||||
|
Transition tables contain as many steps as needed to reach the mode from any other mode, e.g. a
|
||||||
|
switch into any higher AOCS mode might first turn on the sensors, than the actuators and the
|
||||||
|
controller as last component.
|
||||||
|
The target table is used to describe the state that is checked continuously by the subsystem.
|
||||||
|
All of this allows System Modes to be generated as Subsystem object as well from the same database.
|
||||||
|
This System contains list of subsystem modes in the transition and target tables.
|
||||||
|
Therefore, it allows a modular system to create system modes and easy commanding of those, because
|
||||||
|
only the highest components must be commanded.
|
||||||
|
|
||||||
|
The health state represents if the component is able to perform its tasks.
|
||||||
|
This can be used to signal the system to avoid using this component instead of a redundant one.
|
||||||
|
The on-board FDIR uses the health state for isolation and recovery.
|
||||||
|
Before Width: | Height: | Size: 52 KiB After Width: | Height: | Size: 52 KiB |
69
docs/index.rst
Normal file
69
docs/index.rst
Normal file
@ -0,0 +1,69 @@
|
|||||||
|
.. Flight Software Framework documentation master file, created by
|
||||||
|
sphinx-quickstart on Tue Nov 30 10:56:03 2021.
|
||||||
|
You can adapt this file completely to your liking, but it should at least
|
||||||
|
contain the root `toctree` directive.
|
||||||
|
|
||||||
|
Flight Software Framework (FSFW) documentation
|
||||||
|
================================================
|
||||||
|
|
||||||
|
.. image:: ../misc/logo/FSFW_Logo_V3_bw.png
|
||||||
|
:alt: FSFW Logo
|
||||||
|
|
||||||
|
The Flight Software Framework is a C++ Object Oriented Framework for unmanned,
|
||||||
|
automated systems like Satellites.
|
||||||
|
|
||||||
|
The initial version of the Flight Software Framework was developed during
|
||||||
|
the Flying Laptop Project by the University of Stuttgart in cooperation
|
||||||
|
with Airbus Defence and Space GmbH.
|
||||||
|
|
||||||
|
Quick facts
|
||||||
|
---------------
|
||||||
|
|
||||||
|
The framework is designed for systems, which communicate with external devices, perform control
|
||||||
|
loops, receive telecommands and send telemetry, and need to maintain a high level of availability.
|
||||||
|
Therefore, a mode and health system provides control over the states of the software and the
|
||||||
|
controlled devices. In addition, a simple mechanism of event based fault detection, isolation and
|
||||||
|
recovery is implemented as well.
|
||||||
|
|
||||||
|
The FSFW provides abstraction layers for operating systems to provide a uniform operating system
|
||||||
|
abstraction layer (OSAL). Some components of this OSAL are required internally by the FSFW but is
|
||||||
|
also very useful for developers to implement the same application logic on different operating
|
||||||
|
systems with a uniform interface.
|
||||||
|
|
||||||
|
Currently, the FSFW provides the following OSALs:
|
||||||
|
|
||||||
|
- Linux
|
||||||
|
- Host
|
||||||
|
- FreeRTOS
|
||||||
|
- RTEMS
|
||||||
|
|
||||||
|
The recommended hardware is a microprocessor with more than 1 MB of RAM and 1 MB of non-volatile
|
||||||
|
memory. For reference, current applications use a Cobham Gaisler UT699 (LEON3FT), a
|
||||||
|
ISISPACE IOBC or a Zynq-7020 SoC. The ``fsfw`` was also successfully run on the
|
||||||
|
STM32H743ZI-Nucleo board and on a Raspberry Pi and is currently running on the active
|
||||||
|
satellite mission Flying Laptop.
|
||||||
|
|
||||||
|
Index
|
||||||
|
-------
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 2
|
||||||
|
:caption: Contents:
|
||||||
|
|
||||||
|
getting_started
|
||||||
|
highlevel
|
||||||
|
core
|
||||||
|
config
|
||||||
|
osal
|
||||||
|
pus
|
||||||
|
devicehandlers
|
||||||
|
controllers
|
||||||
|
localpools
|
||||||
|
api
|
||||||
|
|
||||||
|
Indices and tables
|
||||||
|
==================
|
||||||
|
|
||||||
|
* :ref:`genindex`
|
||||||
|
* :ref:`modindex`
|
||||||
|
* :ref:`search`
|
||||||
181
docs/localpools.rst
Normal file
181
docs/localpools.rst
Normal file
@ -0,0 +1,181 @@
|
|||||||
|
Local Data Pools
|
||||||
|
=========================================
|
||||||
|
|
||||||
|
The following text is targeted towards mission software developers which would like
|
||||||
|
to use the local data pools provided by the FSFW to store data like sensor values so they can be
|
||||||
|
used by other software objects like controllers as well. If a custom class should have a local
|
||||||
|
pool which can be used by other software objects as well, following steps have to be performed:
|
||||||
|
|
||||||
|
1. Create a ``LocalDataPoolManager`` member object in the custom class
|
||||||
|
2. Implement the ``HasLocalDataPoolIF`` with specifies the interface between the local pool
|
||||||
|
manager and the class owning the local pool.
|
||||||
|
|
||||||
|
The local data pool manager is also able to process housekeeping service requests in form
|
||||||
|
of messages, generate periodic housekeeping packet, generate notification and snapshots of changed
|
||||||
|
variables and datasets and process notifications and snapshots coming from other objects.
|
||||||
|
The two former tasks are related to the external interface using telemetry and telecommands (TMTC)
|
||||||
|
while the later two are related to data consumers like controllers only acting on data change
|
||||||
|
detected by the data creator instead of checking the data manually each cycle. Two important
|
||||||
|
framework classes ``DeviceHandlerBase`` and ``ExtendedControllerBase`` already perform the two steps
|
||||||
|
shown above so the steps required are altered slightly.
|
||||||
|
|
||||||
|
Storing and Accessing pool data
|
||||||
|
-------------------------------------
|
||||||
|
|
||||||
|
The pool manager is responsible for thread-safe access of the pool data, but the actual
|
||||||
|
access to the pool data from the point of view of a mission software developer happens via proxy
|
||||||
|
classes like pool variable classes. These classes store a copy
|
||||||
|
of the pool variable with the matching datatype and copy the actual data from the local pool
|
||||||
|
on a ``read`` call. Changed variables can then be written to the local pool with a ``commit`` call.
|
||||||
|
The ``read`` and ``commit`` calls are thread-safe and can be called concurrently from data creators
|
||||||
|
and data consumers. Generally, a user will create a dataset class which in turn groups all
|
||||||
|
cohesive pool variables. These sets simply iterator over the list of variables and call the
|
||||||
|
``read`` and ``commit`` functions of each variable. The following diagram shows the
|
||||||
|
high-level architecture of the local data pools.
|
||||||
|
|
||||||
|
.. image:: ../docs/images/PoolArchitecture.png
|
||||||
|
:alt: Pool Architecture
|
||||||
|
|
||||||
|
An example is shown for using the local data pools with a Gyroscope.
|
||||||
|
For example, the following code shows an implementation to access data from a Gyroscope taken
|
||||||
|
from the SOURCE CubeSat project:
|
||||||
|
|
||||||
|
.. code-block:: cpp
|
||||||
|
|
||||||
|
class GyroPrimaryDataset: public StaticLocalDataSet<3 * sizeof(float)> {
|
||||||
|
public:
|
||||||
|
/**
|
||||||
|
* Constructor for data users
|
||||||
|
* @param gyroId
|
||||||
|
*/
|
||||||
|
GyroPrimaryDataset(object_id_t gyroId):
|
||||||
|
StaticLocalDataSet(sid_t(gyroId, gyrodefs::GYRO_DATA_SET_ID)) {
|
||||||
|
setAllVariablesReadOnly();
|
||||||
|
}
|
||||||
|
|
||||||
|
lp_var_t<float> angVelocityX = lp_var_t<float>(sid.objectId,
|
||||||
|
gyrodefs::ANGULAR_VELOCITY_X, this);
|
||||||
|
lp_var_t<float> angVelocityY = lp_var_t<float>(sid.objectId,
|
||||||
|
gyrodefs::ANGULAR_VELOCITY_Y, this);
|
||||||
|
lp_var_t<float> angVelocityZ = lp_var_t<float>(sid.objectId,
|
||||||
|
gyrodefs::ANGULAR_VELOCITY_Z, this);
|
||||||
|
private:
|
||||||
|
|
||||||
|
friend class GyroHandler;
|
||||||
|
/**
|
||||||
|
* Constructor for data creator
|
||||||
|
* @param hkOwner
|
||||||
|
*/
|
||||||
|
GyroPrimaryDataset(HasLocalDataPoolIF* hkOwner):
|
||||||
|
StaticLocalDataSet(hkOwner, gyrodefs::GYRO_DATA_SET_ID) {}
|
||||||
|
};
|
||||||
|
|
||||||
|
There is a public constructor for users which sets all variables to read-only and there is a
|
||||||
|
constructor for the GyroHandler data creator by marking it private and declaring the ``GyroHandler``
|
||||||
|
as a friend class. Both the atittude controller and the ``GyroHandler`` can now
|
||||||
|
use the same class definition to access the pool variables with ``read`` and ``commit`` semantics
|
||||||
|
in a thread-safe way. Generally, each class requiring access will have the set class as a member
|
||||||
|
class. The data creator will also be generally a ``DeviceHandlerBase`` subclass and some additional
|
||||||
|
steps are necessary to expose the set for housekeeping purposes.
|
||||||
|
|
||||||
|
Using the local data pools in a ``DeviceHandlerBase`` subclass
|
||||||
|
--------------------------------------------------------------
|
||||||
|
|
||||||
|
It is very common to store data generated by devices like a sensor into a pool which can
|
||||||
|
then be used by other objects. Therefore, the ``DeviceHandlerBase`` already has a
|
||||||
|
local pool. Using the aforementioned example, the ``GyroHandler`` will now have the set class
|
||||||
|
as a member:
|
||||||
|
|
||||||
|
.. code-block:: cpp
|
||||||
|
|
||||||
|
class GyroHandler: ... {
|
||||||
|
|
||||||
|
public:
|
||||||
|
...
|
||||||
|
private:
|
||||||
|
...
|
||||||
|
GyroPrimaryDataset gyroData;
|
||||||
|
...
|
||||||
|
};
|
||||||
|
|
||||||
|
|
||||||
|
The constructor used for the creators expects the owner class as a parameter, so we initialize
|
||||||
|
the object in the `GyroHandler` constructor like this:
|
||||||
|
|
||||||
|
.. code-block:: cpp
|
||||||
|
|
||||||
|
GyroHandler::GyroHandler(object_id_t objectId, object_id_t comIF,
|
||||||
|
CookieIF *comCookie, uint8_t switchId):
|
||||||
|
DeviceHandlerBase(objectId, comIF, comCookie), switchId(switchId),
|
||||||
|
gyroData(this) {}
|
||||||
|
|
||||||
|
|
||||||
|
We need to assign the set to a reply ID used in the ``DeviceHandlerBase``.
|
||||||
|
The combination of the ``GyroHandler`` object ID and the reply ID will be the 64-bit structure ID
|
||||||
|
``sid_t`` and is used to globally identify the set, for example when requesting housekeeping data or
|
||||||
|
generating update messages. We need to assign our custom set class in some way so that the local
|
||||||
|
pool manager can access the custom data sets as well.
|
||||||
|
By default, the ``getDataSetHandle`` will take care of this tasks. The default implementation for a
|
||||||
|
``DeviceHandlerBase`` subclass will use the internal command map to retrieve
|
||||||
|
a handle to a dataset from a given reply ID. Therefore,
|
||||||
|
we assign the set in the ``fillCommandAndReplyMap`` function:
|
||||||
|
|
||||||
|
.. code-block:: cpp
|
||||||
|
|
||||||
|
void GyroHandler::fillCommandAndReplyMap() {
|
||||||
|
...
|
||||||
|
this->insertInCommandAndReplyMap(gyrodefs::GYRO_DATA, 3, &gyroData);
|
||||||
|
...
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
Now, we need to create the actual pool entries as well, using the ``initializeLocalDataPool``
|
||||||
|
function. Here, we also immediately subscribe for periodic housekeeping packets
|
||||||
|
with an interval of 4 seconds. They are still disabled in this example and can be enabled
|
||||||
|
with a housekeeping service command.
|
||||||
|
|
||||||
|
.. code-block:: cpp
|
||||||
|
|
||||||
|
ReturnValue_t GyroHandler::initializeLocalDataPool(localpool::DataPool &localDataPoolMap,
|
||||||
|
LocalDataPoolManager &poolManager) {
|
||||||
|
localDataPoolMap.emplace(gyrodefs::ANGULAR_VELOCITY_X,
|
||||||
|
new PoolEntry<float>({0.0}));
|
||||||
|
localDataPoolMap.emplace(gyrodefs::ANGULAR_VELOCITY_Y,
|
||||||
|
new PoolEntry<float>({0.0}));
|
||||||
|
localDataPoolMap.emplace(gyrodefs::ANGULAR_VELOCITY_Z,
|
||||||
|
new PoolEntry<float>({0.0}));
|
||||||
|
localDataPoolMap.emplace(gyrodefs::GENERAL_CONFIG_REG42,
|
||||||
|
new PoolEntry<uint8_t>({0}));
|
||||||
|
localDataPoolMap.emplace(gyrodefs::RANGE_CONFIG_REG43,
|
||||||
|
new PoolEntry<uint8_t>({0}));
|
||||||
|
|
||||||
|
poolManager.subscribeForPeriodicPacket(gyroData.getSid(), false, 4.0, false);
|
||||||
|
return HasReturnvaluesIF::RETURN_OK;
|
||||||
|
}
|
||||||
|
|
||||||
|
Now, if we receive some sensor data and converted them into the right format,
|
||||||
|
we can write it into the pool like this, using a guard class to ensure the set is commited back
|
||||||
|
in any case:
|
||||||
|
|
||||||
|
.. code-block:: cpp
|
||||||
|
|
||||||
|
PoolReadGuard readHelper(&gyroData);
|
||||||
|
if(readHelper.getReadResult() == HasReturnvaluesIF::RETURN_OK) {
|
||||||
|
if(not gyroData.isValid()) {
|
||||||
|
gyroData.setValidity(true, true);
|
||||||
|
}
|
||||||
|
|
||||||
|
gyroData.angVelocityX = angularVelocityX;
|
||||||
|
gyroData.angVelocityY = angularVelocityY;
|
||||||
|
gyroData.angVelocityZ = angularVelocityZ;
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
The guard class will commit the changed data on destruction automatically.
|
||||||
|
|
||||||
|
Using the local data pools in a ``ExtendedControllerBase`` subclass
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
|
Coming soon
|
||||||
|
|
||||||
|
|
||||||
35
docs/make.bat
Normal file
35
docs/make.bat
Normal file
@ -0,0 +1,35 @@
|
|||||||
|
@ECHO OFF
|
||||||
|
|
||||||
|
pushd %~dp0
|
||||||
|
|
||||||
|
REM Command file for Sphinx documentation
|
||||||
|
|
||||||
|
if "%SPHINXBUILD%" == "" (
|
||||||
|
set SPHINXBUILD=sphinx-build
|
||||||
|
)
|
||||||
|
set SOURCEDIR=.
|
||||||
|
set BUILDDIR=_build
|
||||||
|
|
||||||
|
if "%1" == "" goto help
|
||||||
|
|
||||||
|
%SPHINXBUILD% >NUL 2>NUL
|
||||||
|
if errorlevel 9009 (
|
||||||
|
echo.
|
||||||
|
echo.The 'sphinx-build' command was not found. Make sure you have Sphinx
|
||||||
|
echo.installed, then set the SPHINXBUILD environment variable to point
|
||||||
|
echo.to the full path of the 'sphinx-build' executable. Alternatively you
|
||||||
|
echo.may add the Sphinx directory to PATH.
|
||||||
|
echo.
|
||||||
|
echo.If you don't have Sphinx installed, grab it from
|
||||||
|
echo.http://sphinx-doc.org/
|
||||||
|
exit /b 1
|
||||||
|
)
|
||||||
|
|
||||||
|
%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
|
||||||
|
goto end
|
||||||
|
|
||||||
|
:help
|
||||||
|
%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
|
||||||
|
|
||||||
|
:end
|
||||||
|
popd
|
||||||
63
docs/osal.rst
Normal file
63
docs/osal.rst
Normal file
@ -0,0 +1,63 @@
|
|||||||
|
.. _osal:
|
||||||
|
|
||||||
|
Operating System Abstraction Layer (OSAL)
|
||||||
|
============================================
|
||||||
|
|
||||||
|
Some specific information on the provided OSALs are provided.
|
||||||
|
|
||||||
|
Linux
|
||||||
|
-------
|
||||||
|
|
||||||
|
This OSAL can be used to compile for Linux host systems like Ubuntu 20.04 or for
|
||||||
|
embedded Linux targets like the Raspberry Pi. This OSAL generally requires threading support
|
||||||
|
and real-time functionalities. For most UNIX systems, this is done by adding ``-lrt`` and
|
||||||
|
``-lpthread`` to the linked libraries in the compilation process. The CMake build support provided
|
||||||
|
will do this automatically for the ``fsfw`` target. It should be noted that most UNIX systems need
|
||||||
|
to be configured specifically to allow the real-time functionalities required by the FSFW.
|
||||||
|
|
||||||
|
Hosted OSAL
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
This is the newest OSAL. Support for Semaphores has not been implemented yet and will propably be
|
||||||
|
implemented as soon as C++20 with Semaphore support has matured. This OSAL can be used to run the
|
||||||
|
FSFW on any host system, but currently has only been tested on Windows 10 and Ubuntu 20.04. Unlike
|
||||||
|
the other OSALs, it uses dynamic memory allocation (e.g. for the message queue implementation).
|
||||||
|
Cross-platform serial port (USB) support might be added soon.
|
||||||
|
|
||||||
|
FreeRTOS OSAL
|
||||||
|
------------------
|
||||||
|
|
||||||
|
FreeRTOS is not included and the developer needs to take care of compiling the FreeRTOS sources and
|
||||||
|
adding the ``FreeRTOSConfig.h`` file location to the include path. This OSAL has only been tested
|
||||||
|
extensively with the pre-emptive scheduler configuration so far but it should in principle also be
|
||||||
|
possible to use a cooperative scheduler. It is recommended to use the `heap_4` allocation scheme.
|
||||||
|
When using newlib (nano), it is also recommended to add ``#define configUSE_NEWLIB_REENTRANT`` to
|
||||||
|
the FreeRTOS configuration file to ensure thread-safety.
|
||||||
|
|
||||||
|
When using this OSAL, developers also need to provide an implementation for the
|
||||||
|
``vRequestContextSwitchFromISR`` function. This has been done because the call to request a context
|
||||||
|
switch from an ISR is generally located in the ``portmacro.h`` header and is different depending on
|
||||||
|
the target architecture or device.
|
||||||
|
|
||||||
|
RTEMS OSAL
|
||||||
|
---------------
|
||||||
|
|
||||||
|
The RTEMS OSAL was the first implemented OSAL which is also used on the active satellite Flying Laptop.
|
||||||
|
|
||||||
|
TCP/IP socket abstraction
|
||||||
|
------------------------------
|
||||||
|
|
||||||
|
The Linux and Host OSAL provide abstraction layers for the socket API. Currently, only UDP sockets
|
||||||
|
have been imlemented. This is very useful to test TMTC handling either on the host computer
|
||||||
|
directly (targeting localhost with a TMTC application) or on embedded Linux devices, sending
|
||||||
|
TMTC packets via Ethernet.
|
||||||
|
|
||||||
|
Example Applications
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
There are example applications available for each OSAL
|
||||||
|
|
||||||
|
- `Hosted OSAL <https://egit.irs.uni-stuttgart.de/fsfw/fsfw-example-hosted>`_
|
||||||
|
- `Linux OSAL for MCUs <https://egit.irs.uni-stuttgart.de/fsfw/fsfw-example-linux-mcu>`_
|
||||||
|
- `FreeRTOS OSAL on the STM32H743ZIT <https://egit.irs.uni-stuttgart.de/fsfw/fsfw-example-stm32h7-freertos>`_
|
||||||
|
- `RTEMS OSAL on the STM32H743ZIT <https://egit.irs.uni-stuttgart.de/fsfw/fsfw-example-stm32h7-rtems>`_
|
||||||
2
docs/pus.rst
Normal file
2
docs/pus.rst
Normal file
@ -0,0 +1,2 @@
|
|||||||
|
PUS Services
|
||||||
|
==============
|
||||||
@ -1,23 +1,49 @@
|
|||||||
target_include_directories(${TARGET_NAME} PRIVATE
|
if(DEFINED TARGET_NAME)
|
||||||
|
target_include_directories(${TARGET_NAME} PRIVATE
|
||||||
${CMAKE_CURRENT_SOURCE_DIR}
|
${CMAKE_CURRENT_SOURCE_DIR}
|
||||||
)
|
|
||||||
|
|
||||||
target_sources(${TARGET_NAME} PRIVATE
|
|
||||||
ipc/missionMessageTypes.cpp
|
|
||||||
pollingsequence/PollingSequenceFactory.cpp
|
|
||||||
objects/FsfwFactory.cpp
|
|
||||||
)
|
|
||||||
|
|
||||||
# If a special translation file for object IDs exists, compile it.
|
|
||||||
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/objects/translateObjects.cpp")
|
|
||||||
target_sources(${TARGET_NAME} PRIVATE
|
|
||||||
objects/translateObjects.cpp
|
|
||||||
)
|
)
|
||||||
endif()
|
|
||||||
|
|
||||||
# If a special translation file for events exists, compile it.
|
|
||||||
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/objects/translateObjects.cpp")
|
|
||||||
target_sources(${TARGET_NAME} PRIVATE
|
target_sources(${TARGET_NAME} PRIVATE
|
||||||
events/translateEvents.cpp
|
ipc/missionMessageTypes.cpp
|
||||||
|
pollingsequence/PollingSequenceFactory.cpp
|
||||||
|
objects/FsfwFactory.cpp
|
||||||
)
|
)
|
||||||
|
|
||||||
|
# If a special translation file for object IDs exists, compile it.
|
||||||
|
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/objects/translateObjects.cpp")
|
||||||
|
target_sources(${TARGET_NAME} PRIVATE
|
||||||
|
objects/translateObjects.cpp
|
||||||
|
)
|
||||||
|
endif()
|
||||||
|
|
||||||
|
# If a special translation file for events exists, compile it.
|
||||||
|
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/objects/translateObjects.cpp")
|
||||||
|
target_sources(${TARGET_NAME} PRIVATE
|
||||||
|
events/translateEvents.cpp
|
||||||
|
)
|
||||||
|
endif()
|
||||||
|
else()
|
||||||
|
target_include_directories(${LIB_FSFW_NAME} PRIVATE
|
||||||
|
${CMAKE_CURRENT_SOURCE_DIR}
|
||||||
|
)
|
||||||
|
|
||||||
|
target_sources(${LIB_FSFW_NAME} PRIVATE
|
||||||
|
ipc/missionMessageTypes.cpp
|
||||||
|
pollingsequence/PollingSequenceFactory.cpp
|
||||||
|
objects/FsfwFactory.cpp
|
||||||
|
)
|
||||||
|
|
||||||
|
# If a special translation file for object IDs exists, compile it.
|
||||||
|
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/objects/translateObjects.cpp")
|
||||||
|
target_sources(${LIB_FSFW_NAME} PRIVATE
|
||||||
|
objects/translateObjects.cpp
|
||||||
|
)
|
||||||
|
endif()
|
||||||
|
|
||||||
|
# If a special translation file for events exists, compile it.
|
||||||
|
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/objects/translateObjects.cpp")
|
||||||
|
target_sources(${LIB_FSFW_NAME} PRIVATE
|
||||||
|
events/translateEvents.cpp
|
||||||
|
)
|
||||||
|
endif()
|
||||||
endif()
|
endif()
|
||||||
|
|||||||
@ -7,7 +7,7 @@
|
|||||||
#include <fsfw/tmtcpacket/pus/tm/TmPacketStored.h>
|
#include <fsfw/tmtcpacket/pus/tm/TmPacketStored.h>
|
||||||
#include <fsfw/tmtcservices/CommandingServiceBase.h>
|
#include <fsfw/tmtcservices/CommandingServiceBase.h>
|
||||||
#include <fsfw/tmtcservices/PusServiceBase.h>
|
#include <fsfw/tmtcservices/PusServiceBase.h>
|
||||||
#include <fsfw/internalError/InternalErrorReporter.h>
|
#include <fsfw/internalerror/InternalErrorReporter.h>
|
||||||
|
|
||||||
#include <cstdint>
|
#include <cstdint>
|
||||||
|
|
||||||
@ -48,6 +48,6 @@ void Factory::setStaticFrameworkObjectIds() {
|
|||||||
|
|
||||||
DeviceHandlerFailureIsolation::powerConfirmationId = objects::NO_OBJECT;
|
DeviceHandlerFailureIsolation::powerConfirmationId = objects::NO_OBJECT;
|
||||||
|
|
||||||
TmPacketStored::timeStamperId = objects::NO_OBJECT;
|
TmPacketBase::timeStamperId = objects::NO_OBJECT;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|||||||
@ -1,83 +0,0 @@
|
|||||||
#!/usr/bin/env python3
|
|
||||||
# -*- coding: utf-8 -*
|
|
||||||
"""Small portable helper script to generate LCOV HTML coverage data"""
|
|
||||||
import os
|
|
||||||
import platform
|
|
||||||
import sys
|
|
||||||
import time
|
|
||||||
import argparse
|
|
||||||
import webbrowser
|
|
||||||
from typing import List
|
|
||||||
|
|
||||||
|
|
||||||
"""Copy this helper script into your project folder. It will try to determine a CMake build folder
|
|
||||||
and then attempt to build your project with coverage information.
|
|
||||||
|
|
||||||
See Unittest documentation at https://egit.irs.uni-stuttgart.de/fsfw/fsfw for more
|
|
||||||
information how to set up the build folder.
|
|
||||||
"""
|
|
||||||
def main():
|
|
||||||
|
|
||||||
parser = argparse.ArgumentParser(description="Processing arguments for LCOV helper script.")
|
|
||||||
parser.add_argument(
|
|
||||||
'-o', '--open', action='store_true', help='Open coverage data in webbrowser'
|
|
||||||
)
|
|
||||||
args = parser.parse_args()
|
|
||||||
|
|
||||||
build_dir_list = []
|
|
||||||
if not os.path.isfile('README.md'):
|
|
||||||
os.chdir('..')
|
|
||||||
for directory in os.listdir("."):
|
|
||||||
if os.path.isdir(directory):
|
|
||||||
os.chdir(directory)
|
|
||||||
check_for_cmake_build_dir(build_dir_list)
|
|
||||||
os.chdir("..")
|
|
||||||
|
|
||||||
if len(build_dir_list) == 0:
|
|
||||||
print("No valid CMake build directory found. Trying to set up hosted build")
|
|
||||||
build_directory = 'build-Debug-Host'
|
|
||||||
os.mkdir(build_directory)
|
|
||||||
os.chdir(build_directory)
|
|
||||||
os.system('cmake -DFSFW_OSAL=host -DFSFW_BUILD_UNITTESTS=ON ..')
|
|
||||||
os.chdir('..')
|
|
||||||
elif len(build_dir_list) == 1:
|
|
||||||
build_directory = build_dir_list[0]
|
|
||||||
else:
|
|
||||||
print("Multiple build directories found!")
|
|
||||||
build_directory = determine_build_dir(build_dir_list)
|
|
||||||
perform_lcov_operation(build_directory)
|
|
||||||
if os.path.isdir('fsfw-tests_coverage') and args.open:
|
|
||||||
webbrowser.open('fsfw-tests_coverage/index.html')
|
|
||||||
|
|
||||||
|
|
||||||
def check_for_cmake_build_dir(build_dir_dict: list):
|
|
||||||
if os.path.isfile("CMakeCache.txt"):
|
|
||||||
build_dir_dict.append(os.getcwd())
|
|
||||||
|
|
||||||
|
|
||||||
def perform_lcov_operation(directory):
|
|
||||||
os.chdir(directory)
|
|
||||||
os.system("cmake --build . -- fsfw-tests_coverage -j")
|
|
||||||
|
|
||||||
|
|
||||||
def determine_build_dir(build_dir_list: List[str]):
|
|
||||||
build_directory = ""
|
|
||||||
for idx, directory in enumerate(build_dir_list):
|
|
||||||
print(f"{idx + 1}: {directory}")
|
|
||||||
while True:
|
|
||||||
idx = input("Pick the directory to perform LCOV HTML generation by index: ")
|
|
||||||
if not idx.isdigit():
|
|
||||||
print("Invalid input!")
|
|
||||||
continue
|
|
||||||
|
|
||||||
idx = int(idx)
|
|
||||||
if idx > len(build_dir_list) or idx < 1:
|
|
||||||
print("Invalid input!")
|
|
||||||
continue
|
|
||||||
build_directory = build_dir_list[idx - 1]
|
|
||||||
break
|
|
||||||
return build_directory
|
|
||||||
|
|
||||||
|
|
||||||
if __name__ == "__main__":
|
|
||||||
main()
|
|
||||||
@ -1,3 +0,0 @@
|
|||||||
#!/bin/sh
|
|
||||||
mkdir build-Unittest && cd build-Unittest
|
|
||||||
cmake -DFSFW_BUILD_UNITTESTS=ON -DFSFW_OSAL=host -DCMAKE_BUILD_TYPE=Debug ..
|
|
||||||
188
scripts/helper.py
Executable file
188
scripts/helper.py
Executable file
@ -0,0 +1,188 @@
|
|||||||
|
#!/usr/bin/env python3
|
||||||
|
# -*- coding: utf-8 -*
|
||||||
|
"""Small portable helper script to generate test or doc configuration for the
|
||||||
|
flight software framework
|
||||||
|
"""
|
||||||
|
import os
|
||||||
|
import argparse
|
||||||
|
import webbrowser
|
||||||
|
import shutil
|
||||||
|
import sys
|
||||||
|
import time
|
||||||
|
from typing import List
|
||||||
|
|
||||||
|
|
||||||
|
UNITTEST_FOLDER_NAME = 'build-tests'
|
||||||
|
DOCS_FOLDER_NAME = 'build-docs'
|
||||||
|
|
||||||
|
|
||||||
|
def main():
|
||||||
|
|
||||||
|
parser = argparse.ArgumentParser(description="FSFW helper script")
|
||||||
|
choices = ('docs', 'tests')
|
||||||
|
parser.add_argument(
|
||||||
|
'type', metavar='type', choices=choices,
|
||||||
|
help=f'Target type. Choices: {choices}'
|
||||||
|
)
|
||||||
|
parser.add_argument(
|
||||||
|
'-a', '--all', action='store_true',
|
||||||
|
help='Create, build and open specified type'
|
||||||
|
)
|
||||||
|
parser.add_argument(
|
||||||
|
'-c', '--create', action='store_true',
|
||||||
|
help='Create docs or test build configuration'
|
||||||
|
)
|
||||||
|
parser.add_argument(
|
||||||
|
'-b', '--build', action='store_true',
|
||||||
|
help='Build the specified type'
|
||||||
|
)
|
||||||
|
parser.add_argument(
|
||||||
|
'-o', '--open', action='store_true',
|
||||||
|
help='Open test or documentation data in webbrowser'
|
||||||
|
)
|
||||||
|
|
||||||
|
args = parser.parse_args()
|
||||||
|
if args.all:
|
||||||
|
args.build = True
|
||||||
|
args.create = True
|
||||||
|
args.open = True
|
||||||
|
elif not args.build and not args.create and not args.open:
|
||||||
|
print(
|
||||||
|
'Please select at least one operation to perform. '
|
||||||
|
'Use helper.py -h for more information'
|
||||||
|
)
|
||||||
|
sys.exit(1)
|
||||||
|
|
||||||
|
# This script can be called from root and from script folder
|
||||||
|
if not os.path.isfile('README.md'):
|
||||||
|
os.chdir('..')
|
||||||
|
build_dir_list = []
|
||||||
|
if not args.create:
|
||||||
|
build_dir_list = build_build_dir_list()
|
||||||
|
|
||||||
|
if args.type == 'tests':
|
||||||
|
handle_tests_type(args, build_dir_list)
|
||||||
|
elif args.type == 'docs':
|
||||||
|
handle_docs_type(args, build_dir_list)
|
||||||
|
else:
|
||||||
|
print('Invalid or unknown type')
|
||||||
|
sys.exit(1)
|
||||||
|
|
||||||
|
|
||||||
|
def handle_docs_type(args, build_dir_list: list):
|
||||||
|
if args.create:
|
||||||
|
if os.path.exists(DOCS_FOLDER_NAME):
|
||||||
|
shutil.rmtree(DOCS_FOLDER_NAME)
|
||||||
|
create_docs_build_cfg()
|
||||||
|
build_directory = DOCS_FOLDER_NAME
|
||||||
|
elif len(build_dir_list) == 0:
|
||||||
|
print('No valid CMake docs build directory found. Trying to set up docs build system')
|
||||||
|
shutil.rmtree(DOCS_FOLDER_NAME)
|
||||||
|
create_docs_build_cfg()
|
||||||
|
build_directory = DOCS_FOLDER_NAME
|
||||||
|
elif len(build_dir_list) == 1:
|
||||||
|
build_directory = build_dir_list[0]
|
||||||
|
else:
|
||||||
|
print("Multiple build directories found!")
|
||||||
|
build_directory = determine_build_dir(build_dir_list)
|
||||||
|
os.chdir(build_directory)
|
||||||
|
if args.build:
|
||||||
|
os.system('cmake --build . -j')
|
||||||
|
if args.open:
|
||||||
|
if not os.path.isfile('docs/sphinx/index.html'):
|
||||||
|
# try again..
|
||||||
|
os.system('cmake --build . -j')
|
||||||
|
if not os.path.isfile('docs/sphinx/index.html'):
|
||||||
|
print(
|
||||||
|
"No Sphinx documentation file detected. "
|
||||||
|
"Try to build it first with the -b argument"
|
||||||
|
)
|
||||||
|
sys.exit(1)
|
||||||
|
webbrowser.open('docs/sphinx/index.html')
|
||||||
|
|
||||||
|
|
||||||
|
def handle_tests_type(args, build_dir_list: list):
|
||||||
|
if args.create:
|
||||||
|
if os.path.exists(UNITTEST_FOLDER_NAME):
|
||||||
|
shutil.rmtree(UNITTEST_FOLDER_NAME)
|
||||||
|
create_tests_build_cfg()
|
||||||
|
build_directory = UNITTEST_FOLDER_NAME
|
||||||
|
elif len(build_dir_list) == 0:
|
||||||
|
print(
|
||||||
|
'No valid CMake tests build directory found. '
|
||||||
|
'Trying to set up test build system'
|
||||||
|
)
|
||||||
|
create_tests_build_cfg()
|
||||||
|
build_directory = UNITTEST_FOLDER_NAME
|
||||||
|
elif len(build_dir_list) == 1:
|
||||||
|
build_directory = build_dir_list[0]
|
||||||
|
else:
|
||||||
|
print("Multiple build directories found!")
|
||||||
|
build_directory = determine_build_dir(build_dir_list)
|
||||||
|
os.chdir(build_directory)
|
||||||
|
if args.build:
|
||||||
|
perform_lcov_operation(build_directory, False)
|
||||||
|
if args.open:
|
||||||
|
if not os.path.isdir('fsfw-tests_coverage'):
|
||||||
|
print("No Unittest folder detected. Try to build them first with the -b argument")
|
||||||
|
sys.exit(1)
|
||||||
|
webbrowser.open('fsfw-tests_coverage/index.html')
|
||||||
|
|
||||||
|
|
||||||
|
def create_tests_build_cfg():
|
||||||
|
os.mkdir(UNITTEST_FOLDER_NAME)
|
||||||
|
os.chdir(UNITTEST_FOLDER_NAME)
|
||||||
|
os.system('cmake -DFSFW_OSAL=host -DFSFW_BUILD_UNITTESTS=ON ..')
|
||||||
|
os.chdir('..')
|
||||||
|
|
||||||
|
|
||||||
|
def create_docs_build_cfg():
|
||||||
|
os.mkdir(DOCS_FOLDER_NAME)
|
||||||
|
os.chdir(DOCS_FOLDER_NAME)
|
||||||
|
os.system('cmake -DFSFW_OSAL=host -DFSFW_BUILD_DOCS=ON ..')
|
||||||
|
os.chdir('..')
|
||||||
|
|
||||||
|
|
||||||
|
def build_build_dir_list() -> list:
|
||||||
|
build_dir_list = []
|
||||||
|
for directory in os.listdir("."):
|
||||||
|
if os.path.isdir(directory):
|
||||||
|
os.chdir(directory)
|
||||||
|
build_dir_list = check_for_cmake_build_dir(build_dir_list)
|
||||||
|
os.chdir("..")
|
||||||
|
return build_dir_list
|
||||||
|
|
||||||
|
|
||||||
|
def check_for_cmake_build_dir(build_dir_list: list) -> list:
|
||||||
|
if os.path.isfile("CMakeCache.txt"):
|
||||||
|
build_dir_list.append(os.getcwd())
|
||||||
|
return build_dir_list
|
||||||
|
|
||||||
|
|
||||||
|
def perform_lcov_operation(directory: str, chdir: bool):
|
||||||
|
if chdir:
|
||||||
|
os.chdir(directory)
|
||||||
|
os.system("cmake --build . -- fsfw-tests_coverage -j")
|
||||||
|
|
||||||
|
|
||||||
|
def determine_build_dir(build_dir_list: List[str]):
|
||||||
|
build_directory = ""
|
||||||
|
for idx, directory in enumerate(build_dir_list):
|
||||||
|
print(f"{idx + 1}: {directory}")
|
||||||
|
while True:
|
||||||
|
idx = input("Pick the directory: ")
|
||||||
|
if not idx.isdigit():
|
||||||
|
print("Invalid input!")
|
||||||
|
continue
|
||||||
|
|
||||||
|
idx = int(idx)
|
||||||
|
if idx > len(build_dir_list) or idx < 1:
|
||||||
|
print("Invalid input!")
|
||||||
|
continue
|
||||||
|
build_directory = build_dir_list[idx - 1]
|
||||||
|
break
|
||||||
|
return build_directory
|
||||||
|
|
||||||
|
|
||||||
|
if __name__ == "__main__":
|
||||||
|
main()
|
||||||
@ -1,3 +1,3 @@
|
|||||||
target_sources(${TARGET_NAME} PRIVATE
|
target_sources(${LIB_FSFW_NAME} PRIVATE
|
||||||
TestTask.cpp
|
TestTask.cpp
|
||||||
)
|
)
|
||||||
Loading…
Reference in New Issue
Block a user