Skip to content

Releases: nasa/fprime

v4.0.0a1 (Alpha 1)

15 May 21:21
952e7cf
Compare
Choose a tag to compare
v4.0.0a1 (Alpha 1) Pre-release
Pre-release

F Prime v4 Alpha Release 1 🎉

This is the first alpha release of F Prime v4. This release comes with the following amazing features:

  1. Conditional Sequencing (Svc/FpySequencer)
  2. Fixed-Width Numerical Types
  3. Better GDS plugin support (GdsStandardApp, DataHandlerPlugin)
  4. Improved CMake structure
  5. Formalized configuration modules
  6. External Parameter Handling Support
  7. FPP moduling for Packets
  8. FPP v3
  9. Design pattern documentation
  10. Uplink/Downlink upgrades

Breaking Changes

Typing Changes

F Prime is removing the NATIVE_INT_TYPE, PlatformIntType, etc. Additionally, F Prime has begun ensuring that configurable types (e.g. FwIndexType) are configured to fixed-width values. The requirements (signed, minimum sizes) can be found in the numerical types document.

Users needing non-default values for configurable types should set them as type aliases in FPP using the new configuration system.

FwIndexType Required as Port Indices

Users of older F Prime code may still have NATIVE_INT_TYPE used as port indices. This is now required to be FwIndexType. Other uses of NATIVE_INT_TYPE must also be replaced.

Before:

const NATIVE_INT_TYPE portNum

After:

const FwIndexType portNum

Rate Group Contexts

Rate group context has been changed to the fixed-width type U32.

Before

NATIVE_INT_TYPE rateGroup1Context[Svc::ActiveRateGroup::CONNECTION_COUNT_MAX] = {};
NATIVE_INT_TYPE rateGroup2Context[Svc::ActiveRateGroup::CONNECTION_COUNT_MAX] = {};
NATIVE_INT_TYPE rateGroup3Context[Svc::ActiveRateGroup::CONNECTION_COUNT_MAX] = {};

After:

U32 rateGroup1Context[Svc::ActiveRateGroup::CONNECTION_COUNT_MAX] = {};
U32 rateGroup2Context[Svc::ActiveRateGroup::CONNECTION_COUNT_MAX] = {};
U32 rateGroup3Context[Svc::ActiveRateGroup::CONNECTION_COUNT_MAX] = {};

Unit Test Constant Changes

In the same capacity as above, unit test constants of NATIVE_INT_TYPE are not supported

Before:

    static const NATIVE_INT_TYPE MAX_HISTORY_SIZE = 10;

    // Instance ID supplied to the component instance under test
    static const NATIVE_INT_TYPE TEST_INSTANCE_ID = 0;

    // Queue depth supplied to the component instance under test
    static const NATIVE_INT_TYPE TEST_INSTANCE_QUEUE_DEPTH = 10;

After:

    // Maximum size of histories storing events, telemetry, and port outputs
    static const U32 MAX_HISTORY_SIZE = 10;

    // Instance ID supplied to the component instance under test
    static const FwEnumStoreType TEST_INSTANCE_ID = 0;

    // Queue depth supplied to the component instance under test
    static const FwSizeType TEST_INSTANCE_QUEUE_DEPTH = 10;

New CMake Module Structure

The old module registration structure in F Prime had one primary limitation: SOURCE_FILES and MOD_DEPS were variables and thus could bleed into other module registrations if not unset. This pollution of CMake's variable namespace, high chance for user error, and poor choice of the name "MOD_DEPS" led to a need to refactor how modules are done. To fit in with modern CMake practices, all module inputs are arguments to the registration calls with individual variables specified by directive arguments (e.g. SOURCES, DEPENDS).

Tip

register_fprime_module, register_fprime_deployment and register_fprime_ut still support MOD_DEPS, SOURCE_FILES, UT_MOD_DEPS, UT_SOURCE_FILES. Updating to the new structure is only required for register_fprime_configuration calls. However, new features will only be supported with the new structure and as such, users are encouraged to update when needed.

The new register_fprime_* calls are provided arguments lists separated by argument directives to specify sources (SOURCES), dependencies (DEPENDS) etc.

The first argument is an optional explicit module name followed by directives and their argument lists.

Before:

set(SOURCE_FILES
    "${CMAKE_CURRENT_LIST_DIR}/source1.cpp"
    "${CMAKE_CURRENT_LIST_DIR}/source2.cpp"
    "${CMAKE_CURRENT_LIST_DIR}/source1.fpp"
    "${CMAKE_CURRENT_LIST_DIR}/source2.fpp"
)
set(HEADER_FILES
    "${CMAKE_CURRENT_LIST_DIR}/header1.hpp"
    "${CMAKE_CURRENT_LIST_DIR}/header2.hpp"
)
set(MOD_DEPS Fw_Types)
register_fprime_module(MyModule)

After:

register_fprime_module(
    SOURCES
        "${CMAKE_CURRENT_LIST_DIR}/source1.cpp"
        "${CMAKE_CURRENT_LIST_DIR}/source2.cpp"
    HEADERS
        "${CMAKE_CURRENT_LIST_DIR}/header1.hpp"
        "${CMAKE_CURRENT_LIST_DIR}/header2.hpp"
    AUTOCODER_INPUTS
        "${CMAKE_CURRENT_LIST_DIR}/source1.fpp"
        "${CMAKE_CURRENT_LIST_DIR}/source2.fpp"
    DEPENDS
        Fw_Types
)

Tip

Notice that autocoder inputs are now specifically called out separately from compiled source files.

Warning

Do not specify an explicit module name when autocoding FPP.

Old variable usage can be translated to new directives using the following table:

Old Structure's Variable Directive Purpose
SOURCE_FILES SOURCES Source files supplied to cc, c++, or other compiler
SOURCE_FILES AUTOCODER_INPUTS Autocoder input files used to generate file
MOD_DEPS DEPENDS Module build target dependencies
HEADER_FILES HEADERS Header files supplied by the module
UT_SOURCE_FILES (built) SOURCES Unit test source files to supplied to compiler
UT_SOURCE_FILES (autocode inputs) AUTOCODER_INPUTS Unit test autocoder input files
UT_MOD_DEPS DEPENDS Unit test module dependencies
UT_HEADER_FILES HEADERS Unit test headers

Deployment Ordering

Since deployments in F Prime do recursive detection of items like unit tests, etc, deployments now check for the existence of F Prime modules that support them. This means F Prime deployments must be defined last in the CMake structure.

Before:

add_fprime_subdirectory("${CMAKE_CURRENT_LIST_DIR}/Components/")

add_fprime_subdirectory("${CMAKE_CURRENT_LIST_DIR}/MathDeployment/")

add_fprime_subdirectory("${CMAKE_CURRENT_LIST_DIR}/Types/")
add_fprime_subdirectory("${CMAKE_CURRENT_LIST_DIR}/Ports/")

After:

add_fprime_subdirectory("${CMAKE_CURRENT_LIST_DIR}/Components/")
add_fprime_subdirectory("${CMAKE_CURRENT_LIST_DIR}/Types/")
add_fprime_subdirectory("${CMAKE_CURRENT_LIST_DIR}/Ports/")

add_fprime_subdirectory("${CMAKE_CURRENT_LIST_DIR}/MathDeployment/")

Project Configuration Changes

One of the flaws of historical F Prime is that configuration was an all-or-nothing copy. It meant that projects, libraries, etc could not just override what was changed. This presented projects with a maintenance issue: owning unchanged code provided by F Prime while tracking their own minor changes.

With v4.0.0 projects choose to override specific files and the rest are inherited from underlying configuration modules.

Additionally, each configuration is specified as a module. Use the CONFIGURATION_OVERRIDES directive to override existing config. User SOURCES, HEADERS, and AUTOCODER_INPUTS as usual to specify new configuration (i.e. new configuration for your library). Modules specifying only CONFIGURATION_OVERRIDES must also use the INTERFACE specifier.

To specify a new configuration module, ensure that some directory added to the project with add_fprime_subdirectory contains a CMakeLists.txt including a register_fprime_config call.

See changes in cmake module structure to understand the format of the register_fprime_config call.

CMakeLists.txt

    register_fprime_config(
      CONFIGURATION_OVERRIDES
        "${CMAKE_CURRENT_LIST_DIRECTORY}/FpConfig.fpp"
        "${CMAKE_CURRENT_LIST_DIRECTORY}/IpCfg.hpp"
    )

This example shows how to override just FpConifg.fpp and IpCfg.hpp from fprime.

Tip

Configurations are overridden by filename, so remember to keep your filenames consistent with the file you wish to override.

Tip

Default F Prime configuration lives at fprime/default/config projects will use these settings unless the filename is included in a projects configuration module via CONFIGURATION_OVERRIDES.

Warning

F Prime only has the notion of a single configuration per project (i.e. build). You still may not specify different configurations for different modules built by the same project.

Component Configuration Usage Changes

All configuration headers used from the F Prime configuration directory default/config, a library configuration directory, or a project configuration directory must specify the path including the parent folder.

Before:

#include "IpCfg.hpp"

After:

#include "config/IpCfg.hpp"

Additionally, components wanting to depend on and use core F Prime configured types must depend on Fw_Types and include Fw/FPrimeBasicTypes.h or Fw/FPrimeBasicTypes.hpp.

Before: C++

#include "FpConfig.hpp"

After: C++

#include "Fw/FPrimeBasicTypes.hpp

Before: CMakeLists.txt

set(MOD_DEPS
    SomeDependency
)

After: CMakeLists.txt

set(MOD_DEPS
    Fw...
Read more

v3.6.3

11 May 19:10
5a3b873
Compare
Choose a tag to compare

Release Notes

This release brings in a fix for autocoding of FPP arrays that could cause a very lengthy (if not infinite) build time when compiling with -g should the user have defined a very large array type (~10,000's of elements).

Warning

The v3.6.X series will be the last F Prime releases to support XML autocoding using the Ai.xml and Packets.xml structures.

What's Changed

Full Changelog: v3.6.2...v3.6.3

v3.6.2 - Hotfix 2

27 Feb 00:44
Compare
Choose a tag to compare

This is a follow-up hot-fix release to support fprime-vxworks (v0.2.0). It includes the following bug fixes:

  1. Removes priority from ActiveLogger to prevent health failure when alive and processing many events
  2. Added NOT_SUPPORTED to OSAL statuses.

Full Changelog: v3.6.1...v3.6.2

Release v3.6.1

26 Feb 02:12
Compare
Choose a tag to compare

This is a fix release for v3.6.0, which fixes the following issues:

  1. fprime-gds failing to handle false tokens in JSON
  2. fpp-to-layout not included in requirements.txt
  3. Python dependency security updates
  4. Website content rearranging

Full Changelog: v3.6.0...v3.6.1

Release v3.6.0

13 Feb 00:13
a2a0f39
Compare
Choose a tag to compare

Major Features

Breaking Changes

Os::ConditionVariable usage

  • Os::ConditionVariable::wait() will no longer lock on behalf of the user. Callers of the wait() API must have previously locked the Mutex. Failing to do so will result in an assertion error as it is illegal to wait without holding a lock.

Changes to the Os::ConditionVariable implementations

  • Implementors of the Os::ConditionVariable interface must now implement pend() instead of wait(), returning a ConditionVariable::Status instead of asserting.

IPv4 Driver Changes

Users of the Drv::TcpClient, Drv::TcpServer and Drv::Udp should not supply the reconnect flag to the start() call of these components anymore. It is also recommended to move the configure call to the configuration section of the topology start up sequence.

+    if (state.hostname != nullptr && state.port != 0) {
+        comm.configure(state.hostname, state.port);
+    }
    if (state.hostname != nullptr && state.port != 0) {
        Os::TaskString name("ReceiveTask");
        // Uplink is configured for receive so a socket task is started
-       comm.configure(state.hostname, state.port);
-       comm.start(name, true, COMM_PRIORITY, Default::STACK_SIZE);
+       comm.start(name, COMM_PRIORITY, Default::STACK_SIZE);
    }
}

Users of Drv::Udp must now call configureSend() / configureRecv() explicitly. It is now illegal to call configure() and will result in an assertion failure.

What's Changed

New Contributors

Full Changelog: v3.5.1...v3.6.0

Release v3.5.1

11 Dec 23:37
9f6b4a3
Compare
Choose a tag to compare

This release includes minor fixes to support the fprime-vxworks package. This fixes refine the Posix OSAL layer for use with VxWork's posix support.

Breaking Changes

Svc::DpCatalog configuration must be updated to include #define DP_EXT ".fdp". This file located in user configuration and is named DpCfg.hpp

What's Changed

New Contributors

Full Changelog: v3.5.0...v3.5.1

Release v3.5.0

16 Oct 18:13
c548b53
Compare
Choose a tag to compare

The release v3.5.0 contains a number of improvements. Primarily, the Operating System Abstraction Layer (OSAL) has been refactored to make integration with new operating systems easier. It also ensures that the OSAL selection for each subsystem is independent, and selected per-executable rather than the entire project.
State machine autocoding has been integrated into F Prime, and a plug-in system has been introduced to the GDS to allow for customized integrations and use-cases.

Breaking Changes

There are a number of breaking changes in this release. Users will need to fix these issues when upgrading from v3.4.3.

Configuration Changes

Configuration has been substantially changed. Users should migrate to the new FpConfig.h available in fprime/config and adjust settings accordingly.

General OSAL Changes

Users are encouraged to call Os::init() in the main function of their deployment. While not strictly necessary, this initializes OS singletons at a deterministic time.

Fw::Logger::log calls that precede this call will not be output.

#include <Os/Os.hpp>
...
int main(...) {
    Os::init();
    ...
}

Failing to do so will result in singletons self-initializing on first usage resulting in a very small delay on first usage. Fw::Logger::log messages will not use the Os::Console output until Os::init() is called.

OSAL functions names have been updated to match better naming standards. Please consult the OSAL layer APIs for the new names.

Fw::Logger and Os::Log

Os::Log has been renamed Os::Console to differentiate it from "Fw Log (Log Events)". Most users should be using the Fw::Logger interface anyway.

Fw::Logger::logMsg has been renamed to Fw::Logger::log and now supports printf style substitutions!

Fw::Obj.m_objName is Now an Fw::ObjectName String Type

Direct uses of m_objName should note that the type has changed to a string class. The accessor method still returns a char* type.

FPP Changes

FPP has introduced new keywords to support integrated state machines! This means users who chose those names will need to escape them. Commonly, state is used and should be escaped as $state

- event SetBlinkingState(state: Fw.On) ...
+ event SetBlinkingState($state: Fw.On) ...

PRM_SET/SAVE commands are PARAM_SET/SAVE. This will be revised in a future release as was an unintentional rename.

Task Changes

Most components have standardized on start, stop, and join calls to manage internal tasks. To start these tasks users should switch to the new start, stop, and join methods.

-    comm.startSocketTask(name, true, COMM_PRIORITY, Default::STACK_SIZE);
+    comm.start(name, true, COMM_PRIORITY, Default::STACK_SIZE);
...

-    comm.stopSocketTask();
-    (void)comm.joinSocketTask(nullptr);
+   comm.stop();
+    comm.join();

Fully Qualified Instance Names

Instances in F Prime dictionaries and typologies are now fully-qualified. This means that the instances are prepended with the module names. To restore the global-instance functionality of older deployments, please remove modules definitions from around instances.

- module Ref {
...

  instance blockDrv: Drv.BlockDriver base id 0x0100 \
    queue size Default.QUEUE_SIZE \
    stack size Default.STACK_SIZE \
    priority 140
...
- }

StringUtils Changes

Users of StringUtils functions should now supply a FwSizeType and may no longer use U32 as arguments.

StringBase Constructor are now Explicit

Conversion from const char* to some Fw::StringBase types requires explicit use of the single argument constructor.

Linux GPIO driver

Users of the LinuxGpioDriver now should exepct a return value of Drv::GpioStatus from read and write calls. Additionally, the open call now expects a chip argument.

- bool gpio_success = gpioDriver.open(13, Drv::LinuxGpioDriver::GpioDirection::GPIO_OUT);
+ Os::File::Status gpio_success = gpioDriver.open("/dev/gpiochip0", 13, Drv::LinuxGpioDriver::GpioConfiguration::GPIO_OUTPUT);

Time and Interval Changes

Users should now supply a Fw::TimeInterval(seconds, microseconds) to calls to Os::Task::delay. Svc.TimeVal has been replaced by Os::RawTime.

GDS Changes

The GDS now defaults to ZeroMQ as a transport layer instead of our home-grown solution.

The GDS now expects dictionaries in the new JSON format.

Full List of Changes

Read more

Release v3.4.3

20 Feb 19:24
ba30515
Compare
Choose a tag to compare

Hotfix release correcting a bug in the deployment templates (fprime-util new --deployment).

What's Changed

Full Changelog: v3.4.2...v3.4.3

Release v3.4.2

16 Feb 20:55
7b21b18
Compare
Choose a tag to compare

Quarterly release including bug fixes, improvements and a few minor breaking changes.

Breaking Changes

  • In Fw/FilePacket, the length and value member variables are now private and should instead be accessed with the getLength and getValue methods.
  • In Svc/FileDownlink, the sourceName, destName, osFile and size member variables are now private and should be accessed with their get* methods.
  • send is now a reserved keyword in FPP. FPP objects that are named send, such as ports, need to be either renamed or escaped with a $ character (see reference on escape characters in FPP)
  • The following only applies to projects that pull the config/ folder out of fprime/ to configure and own it in their project.
    Modifications are required in the following files (links show content to add):

Improvements

  • The Ninja build tool is now officially supported by F´ Tools. Generate a Ninja-based build cache with fprime-util generate --ninja.
  • fprime-util new --project is being deprecated in favor of a new package: fprime-bootstrap. This is to fix installation issues as well as improve user experience with a new recommended approach to using virtual environments within an F´ project. See the Install Guide for more information.
  • Improvements to the F´ GDS and F´ Tools packages.

All PRs

New Contributors

Full Changelog: v3.4.1...v3.4.2

Release v3.4.1

18 Dec 22:40
8a1612c
Compare
Choose a tag to compare

This release addresses a number of issues with the v3.4.0 release. Most notably, we've corrected a number of issues with the various tool packages that support F´.

What's Changed

Full Changelog: v3.4.0...v3.4.1