目录
Thomas Boyer-Chammard

Add documentation for configuration modules (#5974)

  • docs: document configuration modules (register_fprime_config / CONFIGURATION_OVERRIDES)

Add docs/user-manual/build-system/configuration.md explaining how configuration modules are assembled in the build cache, how the framework, platforms, libraries, and subtopologies provide defaults, and how projects override them. Recommend the default-config/config- convention for library configuration. Fix the register_fprime_config API docstring (DEPENDS and EXCLUDE_FROM_ALL are supported), update the platform template, retire the legacy config_directory setting docs, and cross-link related pages.

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

  • docs: address review on configuration docs

Recommend /config-overrides/ for project overrides (a /config/ directory shadows the build-cache config/ include path), mark the library default-config folder as optional, and drop the config_directory mention.

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

  • docs: address multi-agent review on configuration docs
  • platform template: header and STEP 2 wording match the configuration-module contract
  • configuration.md: INTERFACE vs STATIC rule (FPP enum/struct/array autocode .cpp)
  • implement-osal.md: Step 1 uses config-overrides/ like Step 2
  • custom-uplink-downlink-data.md: point at configuration.md instead of config_directory

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

  • docs: placement rule also applies to override-only configuration modules

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

  • docs: address local review iteration 1 findings on configuration modules
  • narrow INTERFACE guidance to type aliases / integer constants (string, float, bool constants and enum/struct/array emit .cpp)
  • hedge STATIC wording: AUTOCODER_INPUTS modules default to STATIC, SOURCES-only modules should declare STATIC (nasa/fprime#5970)
  • explain why <default-config/config-/…> includes bypass overrides
  • fix include-root error remediation and message text
  • state build-cache flattening; RawTimeSource.hpp example
  • add config_directory migration note to settings.md
  • add add_fprime_subdirectory step to subtopology override recipe
  • add INTERFACE to override-only implement-osal example
  • remove stale TOC anchor in configuring-fprime.md
  • sync cmake/API.cmake docstring (checks scope, precedence, config-my-library)

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

  • docs: address local review iteration 2 findings on configuration modules
  • CHOOSES_IMPLEMENTATIONS: document de-duplication caveat (project cannot re-select an implementation the platform already listed)
  • INTERFACE is required (not recommended) for HEADERS/OVERRIDES-only modules; add ‘No SOURCES given to target’ to the errors table
  • FPP override resolution is via fpp-depend, DEPENDS _Types is optional
  • fold duplicated STATIC note in register_fprime_config docstring; align terminology
  • fix platform template STEP 5 comment on GLOBAL_IMPLICIT_DEPENDENCY purpose

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

  • docs: address local review iteration 3 findings
  • GLOBAL_IMPLICIT_DEPENDENCY modules must depend on the global interface target, not Fw_Types (cycle under BUILD_SHARED_LIBS=ON)
  • library override directories need a library-specific name; document the binary-directory collision and the flat configuration file namespace
  • FPP-only consumers get the config dependency from FPP analysis
  • override-before-fprime_setup_included_code() as a cause of the nonexistent-file error; reference nasa/fprime#5970 for the STATIC default
  • platform template: remove empty CHOOSES_IMPLEMENTATIONS
  • subtopologies.md: replace stale ‘different from config’ rule
  • trim duplicated library-default rationale in secondary pages

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

  • docs: address local stale-documentation findings (iteration 3)
  • develop-fprime-libraries.md: link the Default Configuration section from Contents
  • configuration.md: mention component-local /config/Config modules
  • run-baremetal.md: point at configuration modules instead of a copied default/config
  • skills: project configuration module may re-choose implementations; ‘configuration module’ wording

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

  • clarify path

  • revert changes

  • docs: add assembly sequence diagram to configuration page

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

  • docs: prefix build-cache paths in configuration diagram

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>


Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

10小时前6392次提交

A Flight-Proven, Multi-Platform, Open-Source Flight Software Framework



F´ (F Prime) is a component-driven framework that enables rapid development and deployment of spaceflight and other embedded software applications. Originally developed at the Jet Propulsion Laboratory, F´ has been successfully deployed on several space applications. It is tailored but not limited to small-scale spaceflight systems such as CubeSats, SmallSats, and instruments.

Please Visit the F´ Website: https://fprime.jpl.nasa.gov for more information.

What does F´ provide

  • An architecture that decomposes flight software into discrete components with well-defined interfaces
  • A C++ framework that provides core capabilities such as message queues and threads
  • Modeling tools for specifying components and connections and automatically generating code
  • A growing collection of ready-to-use components
  • Testing tools for testing flight software at the unit and integration levels.

Learn more about F´ key features.

System Requirements

The following system requirements apply to your workstation for developing F´ applications. To see the list of supported platforms on which F´ applications can run on, see Supported Platforms.

  1. Linux, Windows with WSL, or macOS operating system

  2. git

  3. Python 3.10+, virtual environments, and PIP

  4. Clang or GNU C and C++ compilers (e.g. gcc and g++)

  5. (Optional) A Rust toolchain (cargo and rustc) — required only to build components that depend on Rust. Components that require cargo are skipped when it is not found, and the rest of the framework builds normally.

Click to Expand: How to Verify System Requirements
  1. git --version

  2. python --version and python -m venv -h. Your system might use an alternate like python3 or python3.13. For pip: pip --version. On your system it might be pip3 or pipx.

  3. g++ --version and then create, build, and run a test program. For example, create a file named hello.cpp with contents:

    #include <iostream>
    int main(void){
        std::cout << "Hello, World!" << std::endl;
    }

    then build and run it, for example like:

    % g++ -o hi hello.cpp
    % ./hi
    Hello, World!
  4. (Optional) cargo --version and rustc --version. Only needed to build components that depend on Rust.

Getting Started

To get started with F´, install the F´ bootstrapping tool with:

pip install fprime-bootstrap

Then, create a new project with:

fprime-bootstrap project

See the HelloWorld Tutorial to guide you through all the steps of developing an F´ project.

New users are encouraged to read through the User Manual and explore the other tutorials.

Getting Help

Discussions

To ask questions, discuss improvements, and ask for help please use the project’s GitHub Discussions.

Bug reports

To report bugs and issues, open an issue here.

Community

The F´ Community GitHub Organization contains third party contributions, more documentation of flight software development, and additional resources.

Resources

Meet the Team

The following roles are members of the CCB and per our governance document have decision making power within the framework.

Role Team Member
Community Manager @LeStarch
Community Manager @thomas-bc
Community Manager @kevin-f-ortega
Security Overseer @bitWarrior
CCB Member @bocchino
CCB Member @kevin-f-ortega
CCB Member @SterlingPeet
CCB Member @timcanham
CCB Member @zimri-leisher

Each product has a set of Maintainers who are charged with the day-to-day implementation of the CCB’s direction as realized in a by product.

Product Core Maintainer(s)
F Prime @LeStarch, @thomas-bc
F Prime (v3.6.x Maintenance) @SterlingPeet
fprime-tools @thomas-bc, @LeStarch
fprime-gds @thomas-bc, @LeStarch
fpp @bocchino, @Kronos3
F Prime Platforms @kevin-f-ortega, @LeStarch
Security @bitWarrior

Release Notes

The version history and artifacts associated with the project can be found at Releases.

关于

NASA JPL 开源的组件化飞行软件框架,面向小型任务,提供组件模型、遥测遥控与代码自动生成,已应用于多类航天任务。镜像收录自 https://github.com/nasa/fprime,License:Apache-2.0

850.1 MB
邀请码
    Gitlink(确实开源)
  • 加入我们
  • 官网邮箱:gitlink@ccf.org.cn
  • QQ群
  • QQ群
  • 公众号
  • 公众号

版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9 京公网安备 11010802047560号