F' - A flight software and embedded systems framework

Overview

F´: A Flight-Proven, Multi-Platform, Open-Source Flight Software Framework

Language grade: C++ Language grade: Python Language grade: JavaScript

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.

F´ comprises several elements:

  • 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.

Quick Installation Guide

The following utilities are prerequisites to installing F´:

  • cmake
  • git
  • Python 3.5+ with pip

Once these utilities are installed, you can install F´ Python dependencies. Installing dependencies in a Python virtual environment prevents issues at the system level, but installing in a virtual environment is not required.

To install F´ quickly, enter:

git clone https://github.com/nasa/fprime.git
cd fprime
pip install --upgrade wheel setuptools pip
pip install Fw/Python Gds/

For full installation instructions, including virtual environment creation and installation verification, see INSTALL.md.

Example Deployments

F´ comes with two example deployments. The deployments represent working F´ applications to help you understand F´. You can use these examples for reference, or clone them to start a new project.

The next section links to more step-by-step tutorials, but it's a good idea to build and run at least the first example deployment to ensure that F´ is installed correctly.

Example one: Ref

The standard reference application demonstrates how most of the system components should be wired together. The reference application can build on Linux or Mac OSX, allowing you to get started immediately without the need for embedded hardware.

Example two: RPI

This Raspberry PI application shows how to run F´ in an embedded context by running on the Raspberry PI (a $35 embedded Linux computer). This application shows you how to get started on embedded projects with cross-compiling, drivers, and more. The Raspberry Pi was chosen because it is commercially available for a low price and runs Linux.

Tutorials

F´ provides several tutorials in order to help understand and develop within the framework. These tutorials cover basic component creation, system and topology design, tooling, and more. These tutorials are available at docs/Tutorials/README.md.

Getting Help with F´

As F´ becomes a community centered product line, there are more items available from the community at large.

You can join the mailing list at https://groups.google.com/d/forum/fprime-community.

The F´ community GitHub Organization contains third party contributions, more documentation of flight software development, and more! https://github.com/fprime-community.

You can open issues with this repository at: https://github.com/nasa/fprime/issues

F´ Features

F´ has the following key features that enable robust embedded system design.

Reusability

F´'s component-based architecture enables a high degree of modularity and software reuse.

Rapid Deployment

F´ provides a complete development ecosystem, including modeling tools, testing tools, and a ground data system. Developers use the modeling tools to write high-level specifications, automatically generate implementations in C++, and fill in the implementations with domain-specific code. The framework and the code generators provide all the boilerplate code required in an F´ deployment, including code for thread management, code for communication between components, and code for handling commands, telemetry, and parameters. The testing tools and the ground data system simplify software testing, both on workstations and on flight hardware in the lab.

Portability

F´ runs on a wide range of processors, from microcontrollers to multicore computers, and on several operating systems. Porting F´ to new operating systems is straightforward.

High Performance

F´ utilizes a point-to-point architecture. The architecture minimizes the use of computational resources and is well suited for smaller processors.

Adaptability

F´ is tailored to the level of complexity required for small missions. This makes F´ accessible and easy to use while still supporting a wide variety of missions.

Analyzability

The typed port connections provide strong compile-time guarantees of correctness.

F´ Release Notes

Release 1.0:

  • This is the initial release of the software to open source. See the license file for terms of use.

Release 1.01

  • Updated contributor list. No code changes.

Release 1.1

  • Created a Raspberry Pi demo. Read about it here
  • Added a tutorial here
  • Updated Svc/BufferManager with bug fix
  • Fixed a bunch of shell permissions

Release 1.2

  • Better MagicDraw Plugin
  • Prototype CMake build system. See: CMake Documentation
  • Mars Helicopter Project fixes migrated in
  • Python 3 support added
  • Gse refactored and renamed to Gds
  • Wx frontend to Gds
  • UdpSender and UdpReceiver components added
  • Purged inaccurate ITAR and Copyright notices
  • Misc. bug fixes

Release 1.3

  • New prototype HTML GUI
  • Python packages Fw/Python and Gds
  • Refined CMake and fprime-util helper script
  • Better ground interface component
  • Integration test API
  • Baremetal components

Release 1.4

  • Ref app no longer hangs on Linux exit
  • GDS improvements:
    • File Uplink and Downlink implemented
    • GDS supports multiple active windows
    • Usability improvements for EVRs and commands
  • CMake improvements:
    • Baremetal compilation supported
    • Random rebuilding fixed
    • Missing Cheetah templates properly rebuild
    • Separate projects supported without additional tweaks
  • Updated MemAllocator to have:
    • "recoverable" flag to indicate if memory was recoverable across boots
    • size variable is now modifiable by allocator to indicate actual size
    • This will break existing code that uses MemAllocator
  • Updated CmdSequencer
    • Uses new MemAllocator interface

Release 1.5

  • Documentation improvements
  • F´ Project restructuring
  • Refactored fprim-util
    • Replaced redundant targets with flags e.g. build-ut is now build --ut
    • Added info command
    • Bug and usability fixes
  • GDS Improvements
    • Prototype GDS CLI tool
    • Project custom dashboard support
  • Array, Enum type support and examples
  • Code linting and bug fixes
Comments
  • Porting to Platforms with Constrained Memory

    Porting to Platforms with Constrained Memory

    I am trying to port F Prime to one of the largest available parts in the ATmega family of embedded processors from Microchip (previously Atmel). With some modifications, @zeroping and I have managed to get it to compile all the expected frameworks parts, port objects, and components for the ArduinoBlink deployment in @LeStarch's fork.

    The problem is that when we get to the linking step, it fails to link because it cannot find references to new and delete. These keywords are explicitly left out of the avr-g++ compiler support, because using them on many of the smaller supported processors is actually a mistake. e.g.: an ATtiny85 with 512 bytes of ram, or worse, an ATtiny10 with only 32 bytes of RAM! Not that we care about running F Prime on those targets, but the authors of the compiler do care, and made appropriate decisions about the built-in support.

    Similarly, there is an avr-libc that is provided but STL, libc++, and libstdc++ are not. These issues are approachable by providing stubs or extern "C" statements for the Fw/Types/AVR directory. In fact, that is how I have gotten it to compile, needing cstring, cstdio, and cstdarg shims in the Types folder.

    The following is a snippet of my [cmake build system] compilation output where the linker fails:

    [100%] Linking CXX executable ../../../bin/avr-gcc/ArduinoBlink
    cd /home/vagrant/src/ATmega-fprime/build-atmega/examples/ArduinoBlink/Top && /usr/bin/cmake -E cmake_link_script CMakeFiles/ArduinoBlink.dir/link.txt --verbose=1
    /usr/bin/avr-g++  -g   CMakeFiles/ArduinoBlink.dir/Main.cpp.obj CMakeFiles/ArduinoBlink.dir/Topology.cpp.obj CMakeFiles/ArduinoBlink.dir/write.c.obj CMakeFiles/ArduinoBlink.dir/ArduinoTopologyAppAc.cpp.obj  -o ../../../bin/avr-gcc/ArduinoBlink ../../../lib/avr-gcc/libFw_Types.a ../../../lib/avr-gcc/libFw_Cfg.a ../../../lib/avr-gcc/libSvc_ActiveRateGroup.a ../../../lib/avr-gcc/libSvc_Health.a ../../../lib/avr-gcc/libSvc_Time.a ../../../lib/avr-gcc/libSvc_FatalHandler.a ../../../lib/avr-gcc/libSvc_GroundInterface.a ../../../lib/avr-gcc/libSvc_TlmChan.a ../../../lib/avr-gcc/libSvc_BufferManager.a ../../../lib/avr-gcc/libSvc_FileDownlink.a ../../../lib/avr-gcc/libSvc_ActiveLogger.a ../../../lib/avr-gcc/libSvc_AssertFatalAdapter.a ../../../lib/avr-gcc/libexamples_ArduinoGpsTracker_SerialDriver.a ../../../lib/avr-gcc/libSvc_CmdDispatcher.a ../../../lib/avr-gcc/libexamples_ArduinoGpsTracker_LedBlinker.a ../../../lib/avr-gcc/libSvc_FileUplink.a ../../../lib/avr-gcc/libexamples_ArduinoGpsTracker_HardwareRateDriver.a ../../../lib/avr-gcc/libSvc_PrmDb.a ../../../lib/avr-gcc/libSvc_RateGroupDriver.a ../../../lib/avr-gcc/libSvc_CmdSequencer.a ../../../lib/avr-gcc/libFw_Logger.a ../../../lib/avr-gcc/libSvc_GroundInterface.a ../../../lib/avr-gcc/libSvc_LinuxTime.a ../../../lib/avr-gcc/libOs.a ../../../lib/avr-gcc/libOs_Baremetal_TaskRunner.a ../../../lib/avr-gcc/libSvc_WatchDog.a ../../../lib/avr-gcc/libUtils_Types.a ../../../lib/avr-gcc/libSvc_Fatal.a ../../../lib/avr-gcc/libFw_FilePacket.a ../../../lib/avr-gcc/libFw_Buffer.a ../../../lib/avr-gcc/libCFDP_Checksum.a ../../../lib/avr-gcc/libFw_Prm.a ../../../lib/avr-gcc/libSvc_Cycle.a ../../../lib/avr-gcc/libFw_Tlm.a ../../../lib/avr-gcc/libFw_Log.a ../../../lib/avr-gcc/libSvc_Sched.a ../../../lib/avr-gcc/libSvc_Ping.a ../../../lib/avr-gcc/libFw_Cmd.a ../../../lib/avr-gcc/libFw_Com.a ../../../lib/avr-gcc/libSvc_Seq.a ../../../lib/avr-gcc/libSvc_Time.a ../../../lib/avr-gcc/libFw_Comp.a ../../../lib/avr-gcc/libOs.a ../../../lib/avr-gcc/libFw_Time.a ../../../lib/avr-gcc/libFw_Port.a ../../../lib/avr-gcc/libFw_Obj.a ../../../lib/avr-gcc/libFw_Logger.a ../../../lib/avr-gcc/libUtils_Hash.a ../../../lib/avr-gcc/libFw_Types.a ../../../lib/avr-gcc/libFw_Cfg.a 
    /usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: ../../../bin/avr-gcc/ArduinoBlink section `.text' will not fit in region `text'
    /usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: region `text' overflowed by 271484 bytes
    ../../../lib/avr-gcc/libFw_Types.a(Assert.cpp.obj): In function `Fw::defaultPrintAssert(signed char const*)':
    /home/vagrant/src/ATmega-fprime/Fw/Types/Assert.cpp:23: undefined reference to `operator delete'
    /home/vagrant/src/ATmega-fprime/Fw/Types/Assert.cpp:23: undefined reference to `operator delete'
    ../../../lib/avr-gcc/libSvc_ActiveLogger.a(ActiveLoggerImpl.cpp.obj): In function `Svc::ActiveLoggerImpl::~ActiveLoggerImpl()':
    /home/vagrant/src/ATmega-fprime/Svc/ActiveLogger/ActiveLoggerImpl.cpp:59: undefined reference to `operator delete'
    ../../../lib/avr-gcc/libSvc_ActiveLogger.a(ActiveLoggerImpl.cpp.obj): In function `Svc::ActiveLoggerImpl::~ActiveLoggerImpl()':
    /home/vagrant/src/ATmega-fprime/Svc/ActiveLogger/ActiveLoggerImpl.cpp:59: undefined reference to `operator delete'
    ../../../lib/avr-gcc/libSvc_CmdDispatcher.a(CommandDispatcherComponentAc.cpp.obj): In function `Svc::CommandDispatcherComponentBase::~CommandDispatcherComponentBase()':
    /home/vagrant/src/ATmega-fprime/build-atmega/F-Prime/Svc/CmdDispatcher/CommandDispatcherComponentAc.cpp:730: undefined reference to `operator delete'
    

    The Arduino solution for cross-platform code between AVR and ARM architectures is to implement new and delete in the Arduino library. It basically just thinly wraps the avr-libc implementations of malloc() and free():

    void *operator new( size_t size ){
      return malloc( size );
    }
    
    void *operator new[]( size_t size ){
      return malloc( size );
    }
    
    void operator delete( void *ptr ){
      if( ptr )
        free( ptr );
    }
    
    void operator delete[]( void *ptr ){
      if( ptr )
        free( ptr );
    }
    

    So, clearly it is possible to find a place to plug this into the framework. However, @timcanham has also suggested that perhaps there are patterns we can leverage that avoid using malloc.

    What is a good approach here? Hopefully we can use the results of this issue to enhance Issue #76.

    Documentation High Priority 
    opened by SterlingPeet 46
  • Errors Issue

    Errors Issue

    I am working on the testing section of my CLEMOps component, and I get this error when I try to run make ut. I haven't started working on the tests themselves, but I think I have everything setup, including the blank testing functions. https://github.com/brhs17/fprime/tree/MOpAgg makeUTCLEMOps

    opened by brhs17 37
  • make impl Command Not Recognized

    make impl Command Not Recognized

    My name is Benjamin and I am a new member on Cornell Cislunar Explorers. I have been working thorough the math component tutorial, and at step 2.4.1 I cannot get the make impl command to create any stubs.

    I run the command in the Ref/MathSender directory, and get the result:

    make: *** No rule to make target 'impl'. Stop.

    I built the component without any problems, and have failed to find anything like misnamed files.

    opened by brhs17 33
  • RPI Demo ./runBoth.sh

    RPI Demo ./runBoth.sh

    I am having an issue running the runBoth.sh file after compiling the RPI demo.

    I have made the RPI demo successfully, and am now trying to run the script runBoth.sh in the RPI directory. However, this is giving me the following error:

    ./scripts/run_pi.sh: 31: ./scripts/run_pi.sh: Syntax error: end of file unexpected (expected "fi")

    And then the program just hangs and does not terminate. I looked at the run_pi.sh file and could not find the problem. Any ideas what I should do to fix the script or if I may have installed something incorrectly setting up?

    opened by aaronbuchwald 32
  • lestarch: installing dependencies where necessary, checking for other…

    lestarch: installing dependencies where necessary, checking for other…

    … dependencies

    | | | |:---|:---| |Originating Project/Creator| | |Affected Component| | |Affected Architectures(s)| | |Related Issue(s)| | |Has Unit Tests (y/n)| | |Builds Without Errors (y/n)| | |Unit Tests Pass (y/n)| | |Documentation Included (y/n)| |


    Change Description

    Installs:

    1. SBT, when needing to build fpp

    Checks for (existing installation:

    1. fprime-util (for autocoder dependencies)
    2. python3
    3. java
    opened by LeStarch 27
  • lestarch: integrate FPP and CMake

    lestarch: integrate FPP and CMake

    | | | |:---|:---| |Originating Project/Creator| | |Affected Component| | |Affected Architectures(s)| | |Related Issue(s)| | |Has Unit Tests (y/n)| | |Builds Without Errors (y/n)| | |Unit Tests Pass (y/n)| | |Documentation Included (y/n)| |


    Change Description

    Initial CMake + FPP refactor. CMake cleanup. Autocoder subsystem drafted.

    Rationale

    FPP for the win.

    Testing/Review Recommendations

    Only the build works, other functions will come soon!

    Future Work

    impl testimpl dict ... ...

    opened by LeStarch 19
  • lestarch: reworked linux serial driver into linux uart driver following byte stream driver model

    lestarch: reworked linux serial driver into linux uart driver following byte stream driver model

    | | | |:---|:---| |Originating Project/Creator| | |Affected Component| | |Affected Architectures(s)| | |Related Issue(s)| | |Has Unit Tests (y/n)| | |Builds Without Errors (y/n)| | |Unit Tests Pass (y/n)| | |Documentation Included (y/n)| |


    Change Description

    This takes Drv::LinuxSerialDriver and reworks it into LinuxUartDriver. This includes the following:

    1. Renaming for clarity as this specifically deals with UART ports
    2. Switched to using buffer manager allocate and deallocate calls for acquiring memory
    3. Switched to using Drv::ByteStreamDriverModel for send and recv

    Rationale

    First and foremost the driver was essentially implementing the Drv::ByteStreamModel anyway. Refactoring it to match makes it a drop-in replacement in uplink/downlink without changing much other than order of arguments and names.

    Second, managing its own buffer pool was an old pattern that we've moved away from in favor of the buffer manager. This now uses that pattern.

    Third, UART is a clearer more descriptive name than Serial

    Future Work

    Unit tests. They are disabled in CMake, but perhaps should be brought back.

    opened by LeStarch 18
  • Import/tlm packetizer

    Import/tlm packetizer

    | | | |:---|:---| |Originating Project/Creator| @timcanham | |Affected Component| Svc/TlmPacketizer | |Affected Architectures(s)| All | |Related Issue(s)| | |Has Unit Tests (y/n)| y | |Builds Without Errors (y/n)| y | |Unit Tests Pass (y/n)| y | |Documentation Included (y/n)| y |


    Change Description

    This PR contains the Svc/TlmPacketizer component and updates to the autocoder scripts to support generating packet C++ code. It is not the final delivery; there are some dependency issues to sort out, and the packetizer script isn't fully complete. This is meant to deliver the component and scripts to avoid diverging too much.

    Rationale

    This is a useful alternative to Svc/TlmChan if fixed packets make more sense.

    Testing/Review Recommendations

    The Ref application is tested to show it runs normally. You can exercise the SET_LEVEL command with a 0 argument and see the LevelSet evr and SendLevel channel.

    Future Work

    The dependency issues discovered during development need to be fixed, and the full end-to-end testing would need to be completed.

    opened by timcanham 17
  • fixed handling of redefined messages field types in Gds and GroundInterface

    fixed handling of redefined messages field types in Gds and GroundInterface

    | | | |:---|:---| |Originating Project/Creator|GT1/Georgia Tech | |Affected Component| Svc/GroundInterface | |Affected Architectures(s)| None | |Related Issue(s)| None | |Has Unit Tests (y/n)| N | |Builds Without Errors (y/n)| Y | |Unit Tests Pass (y/n)| Y | |Documentation Included (y/n)| Y |


    Change Description

    Edited the GroundInterface component to use the compilation flags defining the Packet Descriptor. Edited the Gds to use the configuration manager's types when encoding and decoding commands, events, telemetry, parameters, and packet headers.

    Rationale

    Fixes bug where configuring message fields in deployments causes the Gds to be unable to communicate with the deployment. The compilation flags for configuring message fields are necessary on certain platforms with limited memory to reduce memory usage.

    Testing/Review Recommendations

    A deployment should be made that edits the (compilation flag, config manager field) pairs described in the included Gds/docs/README.md file are changed. This deployment should be able to have successful exchanges of commands, events, parameters, and telemetry. There should also be builds containing individual changes to each flag to ensure that all fields are set correctly.

    Future Work

    The FwEnumStoreType flag is confirmed to break the communications with the Gds when it is changed from an I32. I do not know how to change the way this type is serialized since it is defined in the fprime/common/models/serialize/enum_type.py file which I don't believe has access to the configuration manager from the Gds.

    There may be additional fields that can be configured with compilation flags, but will still cause issues with encoding and decoding that will need to be handled correctly to avoid broken communications.

    opened by AaronMcDaniel 16
  • MagicDraw18 SP6 on Windows velocity runtime failure

    MagicDraw18 SP6 on Windows velocity runtime failure

    Hello,

    We are running the fprime magicDraw plugin on MagicDraw18 SP6 Windows. We installed the JPL plugin and got the Component Autocoder to appear on toolbar. However when pressing Auto Generate Component/Port/Topology XML we get the following error:

    screen shot 2019-02-02 at 1 12 37 pm

    All of the XML files in AutoXML are generated but empty. Have you seen this issue before? What do you suggest we do next?

    Any help is greatly appreciated. Thank you!

    opened by Shurtado2019 16
  • lestarch: refactored IPv4 drivers

    lestarch: refactored IPv4 drivers

    | | | |:---|:---| |Originating Project/Creator| Infrastructure | |Affected Component| Drv | |Affected Architectures(s)| N/A | |Related Issue(s)| | |Has Unit Tests (y/n)| y | |Builds Without Errors (y/n)| y | |Unit Tests Pass (y/n)| y | |Documentation Included (y/n)|y |


    Change Description

    Refactors SocketIpDriver into 3 specific drivers TcpClient, TcpServer, and Udp.

    Rationale

    More reusability.

    Testing/Review Recommendations

    Future Work

    Need to fix re-connection code.

    opened by LeStarch 15
  • Make `Ref/Main.cpp` agnostic of F´

    Make `Ref/Main.cpp` agnostic of F´

    | | | |:---|:---| |Originating Project/Creator| | |Affected Component| Ref/Main.cpp | |Affected Architectures(s)| None | |Related Issue(s)| None | |Has Unit Tests (y/n)| n | |Builds Without Errors (y/n)| y | |Unit Tests Pass (y/n)| n | |Documentation Included (y/n)| n |


    Change Description

    This PR aims to make the Ref/Main.cpp of the F' framework as agnostic and standalone as possible.

    Rationale

    In the event that a unit supplier delivers a product developed with F´ to an integrator, it must be able to deliver it as a third-party library.

    The older version of Ref/Main.cpp is tightly coupled to the framework and may put off the user for fear of introducing unnecessary dependencies to the end integrator.

    With this PR, the Ref/Main.cpp deployment shows the user how to wrap the F´ deployment using a minimalist API. This API has three functions:

    • Initialize() : which is responsible for gathering all the initialization functions of the library.
    • Deinitialize() : performs the reverse operation of Initialize.
    • run_one_cycle() : allowing the user to cycle the whole library.

    Testing/Review Recommendations

    I took the liberty of cleaning up the Ref/Top folder by deleting files that seemed unnecessary for the deployment and that added noise to the user.

    Future Work

    The next step would be to gather all the static libraries from the deployment into a single archive for easy integration into a client's code base. (see https://github.com/nasa/fprime/discussions/1657)

    opened by ThibFrgsGmz 0
  • Remove locs.fpp, subdirs.txt, update-locs, and update-subdirs

    Remove locs.fpp, subdirs.txt, update-locs, and update-subdirs

    | | | |:---|:---| |Originating Project/Creator| | |Affected Component| | |Affected Architectures(s)| | |Related Issue(s)| #1576 | |Has Unit Tests (y/n)| | |Builds Without Errors (y/n)| | |Unit Tests Pass (y/n)| | |Documentation Included (y/n)| |


    Change Description

    Removing obsolete locs.fpp, update-locs, subdirs.txt, and update-subdirs.

    opened by codeflight1 1
  • Add standard FPP types

    Add standard FPP types

    | | | |:---|:---| |Originating Project/Creator| | |Affected Component| Fw::Types, Drv::LinuxGpioDriver | |Affected Architectures(s)| | |Related Issue(s)| #1486 | |Has Unit Tests (y/n)| | |Builds Without Errors (y/n)| y | |Unit Tests Pass (y/n)| y | |Documentation Included (y/n)| |


    Change Description

    Adding standard FPP types as per #1486.

    opened by codeflight1 0
  • Fix type specifications in framework

    Fix type specifications in framework

    • Correct inconsistencies in uses of types
    • ~~Remove NATIVE_INT_TYPE and NATIVE_UINT_TYPE from the FPP model. These are not serializable types, because they have a platform-variable size. They should not appear in FPP models.~~
    • ~~Change the use of NATIVE_UINT_TYPE in Svc/Sched to U16. This seems reasonable for now. We can use FwIndexType here, but this will require an update to the FPP code generator. (We should update the FPP code generator to support the new types anyway.)~~

    Supersedes #1694.

    opened by bocchino 1
  • Multi-Com Component

    Multi-Com Component

    | | | |:---|:---| |F´ Version| | |Affected Component| |

    Feature Description

    We are soon to get a com stub and com queue component. However, when testing it can be nice to have a multi-com component. This would allow a com stub + ipv4 for testing, radio + radio driver for com testing without needing to edit or change the topology.

    This component should:

    1. Allow for multiple "Com Adapter Interface" outputs to multiple Com Adapters
    2. Support commands to enable/disable each interface
    3. Detect which interfaces are ready
    4. Only send to a "ready" interface that is also enabled
    5. Serial send buffer to each interface, using the deallocation to signal the next
    6. Responsibly deallocate buffer after final send.
    enhancement 
    opened by LeStarch 0
Releases(v3.1.1)
  • v3.1.1(Aug 19, 2022)

    Updated fprime-tools to allow external configuration and update fprime-gds to run without arguments and match the new fprime-tools version!

    What's Changed

    • Update requirements.txt by @LeStarch in https://github.com/nasa/fprime/pull/1616
    • lestarch: bump fprime-tools for configuration fix. by @LeStarch in https://github.com/nasa/fprime/pull/1622
    • Fixing fprime and fprime-gds version mismatch by @kevin-f-ortega in https://github.com/nasa/fprime/pull/1627

    Full Changelog: https://github.com/nasa/fprime/compare/v3.1.0...v3.1.1

    Source code(tar.gz)
    Source code(zip)
  • v3.1.0(Jun 30, 2022)

    F´ Release v3.1.0: Release Notes

    This release of F´ publishes and baselines native versions of the FPP tools as well as a streamlined CMake system that should enable F´ builds based on FPP to run faster. It includes a number of other improvements including a refined dependency versioning setup, gcovr for coverage analysis, and more!

    Major Changes

    • Improved FPP and CMake efficiency.
    • Switched to requirements.txt for dependency version tracking. Users should use this to install.
    • ActiveRateGroup, RateGroupDriver now have zero-argument standardized constructors. Users should update topologies. See Ref App.
    • CMake autocoders and targets have been refactored for efficiency. Implements should follow: Autocoder Integration

    New Contributors

    • @capsulecorplab made their first contribution in https://github.com/nasa/fprime/pull/1198
    • @myint made their first contribution in https://github.com/nasa/fprime/pull/1272
    • @iw4p made their first contribution in https://github.com/nasa/fprime/pull/1240
    • @danjwait made their first contribution in https://github.com/nasa/fprime/pull/1346
    • @Drosaca made their first contribution in https://github.com/nasa/fprime/pull/1352
    • @inPhraZ made their first contribution in https://github.com/nasa/fprime/pull/1322
    • @Kronos3 made their first contribution in https://github.com/nasa/fprime/pull/1383
    • @lnxpy made their first contribution in https://github.com/nasa/fprime/pull/1353
    • @cadomani made their first contribution in https://github.com/nasa/fprime/pull/1423
    • @connorfuhrman made their first contribution in https://github.com/nasa/fprime/pull/1441
    • @aditsachde made their first contribution in https://github.com/nasa/fprime/pull/1508

    Full Changelog: https://github.com/nasa/fprime/compare/v3.0.0...v3.1.0

    Source code(tar.gz)
    Source code(zip)
  • v3.0.0(Dec 22, 2021)

    Release 3.0.0: Release and Migration Notes

    Version 3.0.0 of F´ comes with several major enhancements to the framework. This release contains an update to use the FPP modeling language and the C++ standard has been updated to C++11. These are fairly substantial changes and users should consult the version 3 migration guide when adopting F´ version 3.

    Whats included:

    1. FPP modeling integration and build system support
    2. CMake build system refactor
    3. Extended C++11 support

    Note: python3, java and C++11 compliant compiler tools are now required.

    New Contributors

    • @bocchino made their first contribution in https://github.com/nasa/fprime/pull/727
    • @ThibFrgsGmz made their first contribution in https://github.com/nasa/fprime/pull/744
    • @Piphi5 made their first contribution in https://github.com/nasa/fprime/pull/760
    • @AliMuhammadOfficial made their first contribution in https://github.com/nasa/fprime/pull/779
    • @r9-pena made their first contribution in https://github.com/nasa/fprime/pull/809
    • @nabcouwer made their first contribution in https://github.com/nasa/fprime/pull/821
    • @tarampampam made their first contribution in https://github.com/nasa/fprime/pull/765
    • @Emil808 made their first contribution in https://github.com/nasa/fprime/pull/827
    • @IvanReznikov made their first contribution in https://github.com/nasa/fprime/pull/831
    • @astroesteban made their first contribution in https://github.com/nasa/fprime/pull/869
    • @chaolinyi made their first contribution in https://github.com/nasa/fprime/pull/875
    • @zachar1a made their first contribution in https://github.com/nasa/fprime/pull/883
    • @slowy07 made their first contribution in https://github.com/nasa/fprime/pull/927
    • @gkieszkowski made their first contribution in https://github.com/nasa/fprime/pull/935
    • @smir45 made their first contribution in https://github.com/nasa/fprime/pull/958
    • @adityadees made their first contribution in https://github.com/nasa/fprime/pull/959
    • @ugo94490 made their first contribution in https://github.com/nasa/fprime/pull/986
    • @thnkslprpt made their first contribution in https://github.com/nasa/fprime/pull/1033
    • @shubham-shahh made their first contribution in https://github.com/nasa/fprime/pull/1079
    • @gjwatney made their first contribution in https://github.com/nasa/fprime/pull/1111
    • @Blabla51 made their first contribution in https://github.com/nasa/fprime/pull/1089
    • @vietjtnguyen made their first contribution in https://github.com/nasa/fprime/pull/1150
    • @FabrizioSandri made their first contribution in https://github.com/nasa/fprime/pull/1151

    Full Changelog: https://github.com/nasa/fprime/compare/v2.0.0...v3.0.0

    Source code(tar.gz)
    Source code(zip)
  • v2.1.0(Dec 13, 2021)

    This is the final release of the F´ 2.x series before FPP and v3 are released.

    What's Changed

    • Remove unused const qualifiers by @Joshua-Anderson in https://github.com/nasa/fprime/pull/701
    • Remove TIMSP standard types by @Joshua-Anderson in https://github.com/nasa/fprime/pull/712
    • Make assertion file name const by @Joshua-Anderson in https://github.com/nasa/fprime/pull/711
    • Move string copyBuff from implmentation to string base class by @Joshua-Anderson in https://github.com/nasa/fprime/pull/695
    • Wrap raw task routine with an platform specific wrapper by @Joshua-Anderson in https://github.com/nasa/fprime/pull/700
    • Removed Unnecessary .gcov files by @AdvaitDhingra in https://github.com/nasa/fprime/pull/708
    • Recover/disabled uts by @LeStarch in https://github.com/nasa/fprime/pull/726
    • lestarch: add in ability to override telemetry time by @LeStarch in https://github.com/nasa/fprime/pull/713
    • lestarch: fixing health for UTs by @LeStarch in https://github.com/nasa/fprime/pull/746
    • Fix #743 Redirect to Discussions tab by @ThibFrgsGmz in https://github.com/nasa/fprime/pull/744
    • Make serializable type getters as const functions by @Joshua-Anderson in https://github.com/nasa/fprime/pull/729
    • Mark tlmWrite argument const for user types by @Joshua-Anderson in https://github.com/nasa/fprime/pull/730
    • Compile root cmake project with -Wextra by @Joshua-Anderson in https://github.com/nasa/fprime/pull/745
    • Correct errors in PolyType toString method by @Joshua-Anderson in https://github.com/nasa/fprime/pull/747
    • lestarch: making CI log archive always run by @LeStarch in https://github.com/nasa/fprime/pull/759
    • Add Black Formatting by @Piphi5 in https://github.com/nasa/fprime/pull/760
    • lestarch: fixing defaults for linux drivers (default build) by @LeStarch in https://github.com/nasa/fprime/pull/771
    • Update build-test.yml by @LeStarch in https://github.com/nasa/fprime/pull/776
    • Remove usages of variable length arrays by @Joshua-Anderson in https://github.com/nasa/fprime/pull/758
    • spelling: received by @eltociear in https://github.com/nasa/fprime/pull/766
    • Enable AddressSanitizer on CI builds by @Joshua-Anderson in https://github.com/nasa/fprime/pull/770
    • Enable additional LGTM queries by @Joshua-Anderson in https://github.com/nasa/fprime/pull/799
    • Fix incorrect deserialization status check by @Joshua-Anderson in https://github.com/nasa/fprime/pull/800
    • Serializable type for Enums by @rohandkn in https://github.com/nasa/fprime/pull/793
    • Default values for stuct members and scalar initialization of array members by @rohandkn in https://github.com/nasa/fprime/pull/795
    • Correct LGTM query selection by @Joshua-Anderson in https://github.com/nasa/fprime/pull/804
    • for better readability added f-string for formatting by @AliMuhammadOfficial in https://github.com/nasa/fprime/pull/779
    • Workflow to verify compatibility with GpsApp tutorial by @r9-pena in https://github.com/nasa/fprime/pull/809
    • lestarch: fixing Fw::Time to allow comparisons across different time … by @LeStarch in https://github.com/nasa/fprime/pull/803
    • Update check-spelling by @jsoref in https://github.com/nasa/fprime/pull/819
    • Update tutorial-support.yml by @LeStarch in https://github.com/nasa/fprime/pull/823
    • Dev/abcouwer/cmake baremetal fixes by @nabcouwer in https://github.com/nasa/fprime/pull/821
    • In FprimeProtocol.cpp:deframe(), make buffer no larger than requested… by @nabcouwer in https://github.com/nasa/fprime/pull/822
    • Add missing newlines at ends of files by @nabcouwer in https://github.com/nasa/fprime/pull/826
    • Update .dockerignore by @tarampampam in https://github.com/nasa/fprime/pull/765
    • Update Tutorial.md by @Emil808 in https://github.com/nasa/fprime/pull/827
    • lestarch: adding a ready port to bytestreamdriver and the tcp implementors by @LeStarch in https://github.com/nasa/fprime/pull/853
    • bugfix-830 by @IvanReznikov in https://github.com/nasa/fprime/pull/831
    • bugfix-832 by @IvanReznikov in https://github.com/nasa/fprime/pull/833
    • VxWorks/C++ fixes by @timcanham in https://github.com/nasa/fprime/pull/797
    • docs: Update Incorrect Ref Executable Path by @astroesteban in https://github.com/nasa/fprime/pull/869
    • Split CI workflow jobs by @r9-pena in https://github.com/nasa/fprime/pull/872
    • fix: Autocoders: finishPortH.tmpl, clerical error by @chaolinyi in https://github.com/nasa/fprime/pull/875
    • fix spellcheck: Add bootlin to dictionary by @Joshua-Anderson in https://github.com/nasa/fprime/pull/876
    • Cleanup string classes by @Joshua-Anderson in https://github.com/nasa/fprime/pull/768
    • Bugfix: docs/Architecture related guide materials by @chaolinyi in https://github.com/nasa/fprime/pull/880
    • lestarch: fixes an overzealous string copy assert by @LeStarch in https://github.com/nasa/fprime/pull/890
    • Fix #873, allow nullptr as an input with buffer constructor with an a… by @zachar1a in https://github.com/nasa/fprime/pull/883
    • Bypass master.bash file in CI by @r9-pena in https://github.com/nasa/fprime/pull/889
    • lestarch: reworking docker by @LeStarch in https://github.com/nasa/fprime/pull/894
    • Switched to direct use of Dockerhub fprime image by @r9-pena in https://github.com/nasa/fprime/pull/895
    • Update/cmd sequencer heli by @timcanham in https://github.com/nasa/fprime/pull/882
    • Fix autodocs github action by @Joshua-Anderson in https://github.com/nasa/fprime/pull/914
    • Run cmake tests in CI by @Joshua-Anderson in https://github.com/nasa/fprime/pull/915
    • Import/tlm packetizer by @timcanham in https://github.com/nasa/fprime/pull/878
    • fix: typo spelling grammar by @slowy07 in https://github.com/nasa/fprime/pull/927
    • Switch CI to run in VM instead of docker container by @Joshua-Anderson in https://github.com/nasa/fprime/pull/924
    • Switch autodocs action to use VM instead of container by @Joshua-Anderson in https://github.com/nasa/fprime/pull/938
    • Cookiecutter docs by @aidan-wagner in https://github.com/nasa/fprime/pull/936
    • autodocs: check out entire history to avoid errors merging by @Joshua-Anderson in https://github.com/nasa/fprime/pull/944
    • highlight section order and fix few typos by @gkieszkowski in https://github.com/nasa/fprime/pull/935
    • Backport 80char replacement by @Joshua-Anderson in https://github.com/nasa/fprime/pull/923
    • Removed repeated imports by @smir45 in https://github.com/nasa/fprime/pull/958
    • lestarch: compile options added correctly by @LeStarch in https://github.com/nasa/fprime/pull/956
    • minor link fixes by @gkieszkowski in https://github.com/nasa/fprime/pull/949
    • lestarch: removing -lgcov flag to fix macOs unit tests by @LeStarch in https://github.com/nasa/fprime/pull/965
    • remove unused extraspace and line by @adityadees in https://github.com/nasa/fprime/pull/959
    • fix: wrong comments by @ugo94490 in https://github.com/nasa/fprime/pull/986
    • simplifying index.md file by @gkieszkowski in https://github.com/nasa/fprime/pull/943
    • LinuxSerialDriver: Check for errors when setting interface speed by @Joshua-Anderson in https://github.com/nasa/fprime/pull/996
    • Hotfix to devel by @LeStarch in https://github.com/nasa/fprime/pull/997
    • lestarch: allowing GTest to be disabled in UTs by @LeStarch in https://github.com/nasa/fprime/pull/1004
    • lestarch: adding macOS to CI by @LeStarch in https://github.com/nasa/fprime/pull/1007
    • lestarch: deframer fix by @LeStarch in https://github.com/nasa/fprime/pull/1017
    • Fix minor typos in error message strings and descriptive comments by @thnkslprpt in https://github.com/nasa/fprime/pull/1033
    • docs: Update MathComponent to Reference TestMain by @astroesteban in https://github.com/nasa/fprime/pull/1030
    • lestarch: reworking posix tasks by @LeStarch in https://github.com/nasa/fprime/pull/992
    • Fix fprime typos by @thnkslprpt in https://github.com/nasa/fprime/pull/1043
    • Fix MathComponent Tutorial.md typos by @thnkslprpt in https://github.com/nasa/fprime/pull/1053
    • Allow removal of text loggers from build with CMake variable. by @nabcouwer in https://github.com/nasa/fprime/pull/1071
    • small corrections by @shubham-shahh in https://github.com/nasa/fprime/pull/1079
    • Fixed the override of timebase and context in Time::set() by @metzdigital in https://github.com/nasa/fprime/pull/1104
    • Added sequence join wait command by @saba-ja in https://github.com/nasa/fprime/pull/1084
    • lestarch: command response errors to use COMMAND severity, #1095 by @LeStarch in https://github.com/nasa/fprime/pull/1117
    • System resources by @sfregoso in https://github.com/nasa/fprime/pull/1116
    • Docs: Updates of the Tutorial documentation by @Blabla51 in https://github.com/nasa/fprime/pull/1089
    • lestarch: descriptions for commands, events, parameters, and args fix… by @LeStarch in https://github.com/nasa/fprime/pull/1132
    • Fixed BasicTypes preproc checks for pointer type by @vietjtnguyen in https://github.com/nasa/fprime/pull/1150
    • Remove redundant null terminate by @FabrizioSandri in https://github.com/nasa/fprime/pull/1151
    • Fix snprintf by @FabrizioSandri in https://github.com/nasa/fprime/pull/1156
    • lestarch: update to doxygen file by @LeStarch in https://github.com/nasa/fprime/pull/1158

    New Contributors

    • @ThibFrgsGmz made their first contribution in https://github.com/nasa/fprime/pull/744
    • @Piphi5 made their first contribution in https://github.com/nasa/fprime/pull/760
    • @AliMuhammadOfficial made their first contribution in https://github.com/nasa/fprime/pull/779
    • @r9-pena made their first contribution in https://github.com/nasa/fprime/pull/809
    • @nabcouwer made their first contribution in https://github.com/nasa/fprime/pull/821
    • @tarampampam made their first contribution in https://github.com/nasa/fprime/pull/765
    • @Emil808 made their first contribution in https://github.com/nasa/fprime/pull/827
    • @IvanReznikov made their first contribution in https://github.com/nasa/fprime/pull/831
    • @astroesteban made their first contribution in https://github.com/nasa/fprime/pull/869
    • @chaolinyi made their first contribution in https://github.com/nasa/fprime/pull/875
    • @zachar1a made their first contribution in https://github.com/nasa/fprime/pull/883
    • @slowy07 made their first contribution in https://github.com/nasa/fprime/pull/927
    • @gkieszkowski made their first contribution in https://github.com/nasa/fprime/pull/935
    • @smir45 made their first contribution in https://github.com/nasa/fprime/pull/958
    • @adityadees made their first contribution in https://github.com/nasa/fprime/pull/959
    • @ugo94490 made their first contribution in https://github.com/nasa/fprime/pull/986
    • @thnkslprpt made their first contribution in https://github.com/nasa/fprime/pull/1033
    • @shubham-shahh made their first contribution in https://github.com/nasa/fprime/pull/1079
    • @Blabla51 made their first contribution in https://github.com/nasa/fprime/pull/1089
    • @vietjtnguyen made their first contribution in https://github.com/nasa/fprime/pull/1150
    • @FabrizioSandri made their first contribution in https://github.com/nasa/fprime/pull/1151

    Full Changelog: https://github.com/nasa/fprime/compare/v2.0.1...v2.1.0

    Source code(tar.gz)
    Source code(zip)
  • v3.0.0-RC2(Nov 17, 2021)

    WARNING: this is a pre-release of F´ v3.0.0 for the purposes of F´ team testing. Some stability issues are still being ironed out and issues may be encountered. It is recommended that users outside the F´ team wait for a final release v3.0.0.

    This includes several fixes:

    1. Math tutorial is now updated in this branch
    2. Extra warning flags added to Ref to improve code quality. Revealed bugs fixed.

    See v3.0.0-RC1 for more information on v3.0.0 requirements.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.0-RC1(Nov 5, 2021)

    WARNING: this is a pre-release of F´ v3.0.0 for the purposes of F´ team testing. Some stability issues are still being ironed out and issues may be encountered. It is recommended that users outside the F´ team wait for a final release v3.0.0.

    Whats included:

    1. FPP modeling integration and build system support
    2. CMake build system refactor
    3. Extended C++11 support

    Note: python3, java and C++11 compliant compiler tools are now required.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.1(Sep 2, 2021)

    Hot-Fix Release of F´v2.0.1:

    • Correct issue with compilation failing w/ conflicts due to built-in VxWorks definitions

    Note: v2.0.x releases will be the last to support VxWorks 6.7 compilers and the GCC 4 toolchain they use.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Jun 10, 2021)

    Release 2.0: Release and Migration Notes

    Version 2.0.0 of F´ represents major improvements across the F´ framework. As such, some work may be required to migrate from other versions of F´ to the new functionality. This section will offer recommendations to migrate to version 2.0.0 of F´.

    Features and Functionality:

    • New ground interface change improves stability and flexibility
      • Svc::Framer and Svc::Deframer components may be used in place of Svc::GroundInterface
      • Svc::Framer and Svc::Deframer delegate to a user instantiated framing class allowing use of non-fprime framing protocols
    • Drv::ByteStreamDriverModel allows implementing drivers reading/writing streams of bytes using a single model
    • New IPv4 drivers implement Drv::ByteStreamDriverModel allowing choice or combination of uplink and downlink communications
      • Drv::TcpClient is a tcp client that connects to a remote server
      • Drv::TcpServer is a tcp server that allows connections from remote clients
      • Drv::Udp allows UDP communications
      • Drv::SocketIpDriver may be replaced using a choice of an above component.
    • Svc::FileDownlink now supports a queue of files to downlink and a port to trigger file downlinks
    • Svc::FileDownlink may now be configured to turn off certain errors
    • Svc/GenericHub is a basic instantiation of the hub pattern
    • Bug fixes and stability improvements

    Migration considerations:

    • F´ tooling (fprime-util and fprime-gds) should be installed using pip install fprime-tools fprime-gds
    • Os::File::open with the mode CREATE will now properly respect O_EXCL and error if the file exists. Pass in false as the final argument to override.
    • Revise uses of Fw::Buffer to correct usage of member functions using camel case. E.g. Fw::Buffer::getsize is now Fw::Buffer::getSize
    • The ground interface chain has been refactored. Projects may switch to using Svc::Framer, Svc::Deframer, and any implementor of Drv::ByteStreamDriverModel to supply the data. To continue using the old interface with the GDS run fprime-gds --comm-checksum-type fixed.
    • Svc::BufferManager has been reworked to remove errors. When instantiating it please supply a memory allocator as shown in Ref.
    • Dictionaries, binaries, and other build outputs now are written to a deployments build_artifacts folder.

    Deprecated Functionality: The following features are or will be deprecated soon and may be removed in future releases.

    • Svc::GroundInterface and Drv::SocketIpDriver should be replaced by the new ground system components.
    • Inline enumerations (enumerations defined inside the definition of a command/event/channel) should be replaced by EnumAi.xml implementations
    • fprime-util generate --ut -DFPRIME_ENABLE_FRAMEWORK_UTS=OFF will be removed in favor of future fprime-util check variants
    • Autocoders/MagicDrawCompPlugin will be removed in a near-term release
    Source code(tar.gz)
    Source code(zip)
  • NASA-v1.5.3(Nov 5, 2020)

    This is a release of F´ that corrects a minor issues in the fprme-util to properly pass in environment variables for customers using fprime-util to setup their build environment variables. See releases 1.5.x for full release notes.

    Note:

    • See release 1.5.x for release updates
    • fprime python package version updated to 1.5.3, please reinstall with --upgrade flag
    Source code(tar.gz)
    Source code(zip)
  • NASA-v1.5.2(Oct 27, 2020)

    This is a release of F´ that corrects a minor issues in the CMake system affecting template implementation with custom AcConstants.ini files for unit tests and fixes the -D flags passed to fprime-util generate. See release 1.5.0, 1.5.1 for full release notes.

    Note:

    • See release 1.5.0 for full feature set
    • fprime python package version updated to 1.5.2
    Source code(tar.gz)
    Source code(zip)
  • NASA-v1.5.1(Oct 22, 2020)

    This is a release of F´ that corrects a minor issue in the CMake system affecting template implementation with custom AcConstants.ini files. See release 1.5.0 for full release notes.

    Note:

    • Python package versions not updated as the python code was not changed
    • See release 1.5.0 for full feature set
    Source code(tar.gz)
    Source code(zip)
  • NASA-v1.5.0(Oct 22, 2020)

    This represents the release v1.5.0 of the F´ software framework. This release includes bug fixes, user tool improvement, minor feature development, and lots of code quality improvements. A refactor of the user's guide is also included and is available here: https://nasa.github.io/fprime/UsersGuide/guide.html.

    Notable changes:

    • F´utility (fprime-util) reduced the number of subcommands in favor of flags. i.e. fprime-util build-all is not fprime-util build --all
    • F´ projects can be restructured to include links to the fprime framework and packages of fprime components developed by a third party. An example can be found here: https://github.com/fprime-community/fprime-arduino/tree/master/ArduinoBlink
    Source code(tar.gz)
    Source code(zip)
  • NASA-v1.4(May 26, 2020)

    This is the 1.4 release of the F´ framework. It has the following features:

    1. File Uplink and Downlink has been added to the F´  GDS.
    2. Build Helper and CMake fixes
    3. Baremetal fixes
    Source code(tar.gz)
    Source code(zip)
  • NASA-v1.3.1(Jan 24, 2020)

    This is release 1.3.1 of NASA's F´ framework. It contains a additions to the test GUI based on HTML, minor fixes to the fprime-util helper for helping use CMake during normal development. It also contains revisited documentation that presents a consistent view of how to run and development in F´. Our tutorials section was revisited to ensure the latest information.

    This is a point release that fixes minor bugs and documentation found in NASA-v1.3.

    Source code(tar.gz)
    Source code(zip)
  • NASA-v1.3(Nov 22, 2019)

    This is release 1.3 of NASA's F´ framework. It contains a refactored test GUI based on HTML, a new integration and test framework for automating system level tests, and the fprime-util helper for helping use CMake during normal development. Also included are many bug fixes and improvements.

    Source code(tar.gz)
    Source code(zip)
Owner
NASA
Read about NASA's Open Data initiative here: https://www.nasa.gov/open/ & Members Find Instructions here: http://nasa.github.io/
NASA
Embedded, self-hosted swagger-ui for go servers

swaggerui Embedded, self-hosted Swagger Ui for go servers This module provides swaggerui.Handler, which you can use to serve an embedded copy of Swagg

Andy Walker 50 Aug 8, 2022
Embedded javascript server-side renderer for Golang

v8ssr Embedded javascript server-side renderer for Golang. Useful for static server-side rendering. This does not attempt to polyfill node or browser

null 2 Aug 27, 2022
godesim Simulate complex systems with a simple API.

godesim Simulate complex systems with a simple API. Wrangle non-linear differential equations while writing maintainable, simple code. Why Godesim?

Patricio Whittingslow 20 Sep 27, 2022
Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

The Moby Project Moby is an open-source project created by Docker to enable and accelerate software containerization. It provides a "Lego set" of tool

Moby 64.1k Sep 28, 2022
IBus Engine for GoVarnam. An easy way to type Indian languages on GNU/Linux systems.

IBus Engine For GoVarnam An easy way to type Indian languages on GNU/Linux systems. goibus - golang implementation of libibus Thanks to sarim and haun

Varnamproject 10 Feb 10, 2022
Distributed Systems 2021 -- Miniproject 3

Mini_Project3 == A Distributed Auction System == You must implement a distributed auction system using replication: a distributed component which hand

null 0 Dec 1, 2021
A simple tool to send binary data over a serial port. Designed for use with my retro computer systems.

Colin's Transfer Tool This is a really basic tool to transfer firmware files to my retro computer systems over a serial port. This removes the need fo

Colin Maykish 0 Dec 21, 2021
Ghdl - A much more convenient way to download GitHub release binaries on the command line, works on Win & Unix-like systems

ghdl Memorize ghdl as github download ghdl is a fast and simple program (and als

beet 48 Aug 26, 2022
MIT 6.824: Distributed Systems (Spring 2020)

MIT6.824 MIT 6.824: Distributed Systems (Spring 2020) Lab 1 Lab 2 Lab 2A Lab 2B Lab 2C Lab 2D Lab 3 Lab 3A Lab 3B Lab 4 Lab 4A Lab 4B Lab 4 Challenge

Ray Eldath 66 Sep 28, 2022
Software of development with Golang

Go-Simple-Rest-Api Description This repository is a Software of Development with Go,Mux,etc Installation Using Go 1.16.3 Server preferably. DataBase U

Daniel Arturo Alejo Alvarez 9 Dec 13, 2021
Core Brightgate Software Stack

Brightgate Product Software Directories Directory Description base/ Resource and Protocol Buffer message definitions build/ Scripts to do with buildin

Brightgate Inc. 2 Sep 25, 2021
software keyboard for TinyGo

tinykb tinykb is a software keyboard for TinyGo. To use tinykb, it is necessary to implement the driver.Displayer interface. It is still an alpha vers

sago35 2 Jan 14, 2022
The Bhojpur BSS is a software-as-a-service product used as an Business Support System based on Bhojpur.NET Platform for application delivery.

Bhojpur BSS - Business Support System The Bhojpur BSS is a software-as-a-service product used as an Business Support System based on Bhojpur.NET Platf

Bhojpur Consulting 0 Sep 9, 2022
Antch, a fast, powerful and extensible web crawling & scraping framework for Go

Antch Antch, inspired by Scrapy. If you're familiar with scrapy, you can quickly get started. Antch is a fast, powerful and extensible web crawling &

null 238 Sep 27, 2022
Entitas-Go is a fast Entity Component System Framework (ECS) Go 1.17 port of Entitas v1.13.0 for C# and Unity.

Entitas-Go Entitas-GO is a fast Entity Component System Framework (ECS) Go 1.17 port of Entitas v1.13.0 for C# and Unity. Code Generator Install the l

Vladislav Fedotov 19 Aug 15, 2022
Tanzu Framework provides a set of building blocks to build atop of the Tanzu platform and leverages Carvel packaging

Tanzu Framework provides a set of building blocks to build atop of the Tanzu platform and leverages Carvel packaging and plugins to provide users with a much stronger, more integrated experience than the loose coupling and stand-alone commands of the previous generation of tools.

VMware Tanzu 176 Sep 26, 2022
Highly customizable archive and index framework for EPITA

epitar.gz Highly customizable archive and index framework for EPITA. Get started

Aurèle Oulès 24 Apr 12, 2022
GoC2 - MacOS Post Exploitation C2 Framework

goc2 c2 client/server/paylod GoC2 - MacOS Post Exploitation C2 Framework Custom C2 for bypassing EDR and ease of use.

Brian Stegemoller 33 Jun 23, 2022
The High Code Framework (low-code for devs)

hof - the high code framework The hof tool tries to remove redundent development activities by using high level designs, code generation, and diff3 wh

_Hofstadter 305 Sep 25, 2022