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.

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

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.

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?

… 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

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

…

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

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

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

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:

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!

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

Problem Description

I'm following the installation instructions, but when I try the build step (fprime-util build --jobs 10), I get the following error.

[ 53%] Generating AssertFatalAdapterComponentAc.hpp, AssertFatalAdapterComponentAc.cpp
Input object has no document: lxml.etree._XSLTResultTree
Traceback (most recent call last):
  File "/Users/cmauceri/My Drive/Workspace/FPrime/fprime/Autocoders/Python/bin/codegen.py", line 1334, in <module>
    main()
  File "/Users/cmauceri/My Drive/Workspace/FPrime/fprime/Autocoders/Python/bin/codegen.py", line 1259, in main
    the_parsed_component_xml = XmlComponentParser.XmlComponentParser(
  File "/Users/cmauceri/My Drive/Workspace/FPrime/fprime/Autocoders/Python/src/fprime_ac/parsers/XmlComponentParser.py", line 113, in __init__
    self.validate_xml(xml_file, element_tree, "schematron", "active_comp")
  File "/Users/cmauceri/My Drive/Workspace/FPrime/fprime/Autocoders/Python/src/fprime_ac/parsers/XmlComponentParser.py", line 1218, in validate_xml
    validator_compiled = isoschematron.Schematron(validator_parsed)
  File "/Users/cmauceri/My Drive/Workspace/FPrime/fprime-venv/lib/python3.9/site-packages/lxml/isoschematron/__init__.py", line 275, in __init__
    schematron = self._expand(schematron, **expand_params)
  File "src/lxml/xslt.pxi", line 515, in lxml.etree.XSLT.__call__
  File "src/lxml/apihelpers.pxi", line 43, in lxml.etree._documentOrRaise
ValueError: Input object has no document: lxml.etree._XSLTResultTree
make[3]: *** [F-Prime/Svc/AssertFatalAdapter/AssertFatalAdapterComponentAc.hpp] Error 255
make[2]: *** [F-Prime/Svc/AssertFatalAdapter/CMakeFiles/Svc_AssertFatalAdapter.dir/all] Error 2
make[1]: *** [CMakeFiles/Ref.dir/rule] Error 2
make: *** [Ref] Error 2
[ERROR] CMake erred with return code 2

Details

I'm on a Mac with an M1 chip running Monteray.

I used fprime-util build --jobs 10 instead of fprime-util build --jobs "$(nproc || printf '%s\n' 1)" because nproc is not available on mac.

How to Reproduce

1. Follow Installation Instructions
2. Error occurs when I run fprime-util build --jobs "$(nproc || printf '%s\n' 1)"

Expected Behavior

I expect the build to execute successfully.