sterlingpeet / cookiecutter-fprime-deployment Goto Github PK

Used the cookiecutter to build a Linux Deployment, the cookiecutter still shows the following options:

startup_delay_msec
startup_arduino_led_flash
arduino_log_stream

Even though they should be Arduino only options

Some baked in assumptions prevent the user from reasonably describing a deployment that exists in the root of the F Prime repository folder. It would be better if a . path was usable, or a different variable is used to designate this condition.

When generating a deployment in the "gt2-software/Common/support" directory using the options listed below in the .cookiecutterrc file, the following line was omitted from the Topology.cpp file:

hardwareRateDriver.start();

This prevents the LED blinker component that gets generated from working default out of the box and should be added after the eventLogger start function.

Contents of .cookiecutterrc:

default_context:

    _template:                 'gh:SterlingPeet/cookiecutter-fprime-deployment'
    arduino_log_stream:        'Serial'
    component_dir_name:        'LedBlinker'
    component_explicit_common: ''
    component_explicit_component_suffix: 'Component'
    component_impl_suffix:     ''
    component_instance_name:   'ledBlinker'
    component_kind:            'passive'
    component_multiplatform_support: 'no'
    component_name:            'Led Blinker'
    component_namespace:       'LEDBlinkDeployment'
    component_path_to_fprime_root: '../../../..'
    component_short_description: 'Example component to support LED Blink Deployment deployment.'
    component_slug:            'LedBlinker'
    dep_short_description:     'A deployment that blinks an LED'
    deployment_baremetal_scheduler: 'yes'
    deployment_command_sequence_support: 'no'
    deployment_display_name:   'LED Blink Deployment'
    deployment_event_text_log_support: 'no'
    deployment_file_xfer_support: 'no'
    deployment_health_support: 'no'
    deployment_parameter_support: 'yes'
    deployment_path:           'Common/support'
    deployment_path_to_fprime_framework: '../../../fprime'
    deployment_path_to_project_root: '../../..'
    deployment_ref_doc_boilerplate: 'no'
    deployment_rg_sched_contexts_hpp: 'no'
    deployment_slug:           'LEDBlinkDeployment'
    deployment_target_platform_support: 'Arduino'
    email:                     '[email protected]'
    full_name:                 'Anthony Limiero'
    license:                   'None'
    startup_arduino_led_flash: 'yes'
    startup_delay_msec:        '2000'

The rateGroup1HzComp is referenced in commented out lines in the TopologyAi.xml as well as Topology.cpp files, but not in Components.hpp. As it is now, the user must uncomment lines in TopologyAi.xml, Topology.cpp, and SchedContexts.hpp, then add a line to Components.hpp to set up the 1Hz rate group.

Components.hpp should be set up like the other files so the user can easily set up a 1Hz rate group by just uncommenting the right lines in the 4 related boilerplate files.

// extern Svc::ActiveRateGroupImpl rateGroup1HzComp; should be added here:

Very small issue here, but I recently discovered that there is a double instantiation of the Os::Log class.

The first instantiation is found in the Main.cpp file for Arduino deployments on line 52, right after the #ifdef statement setting up the Serial logger.

Os::Log logger;

The second instantiation is found in the Topology.cpp file on line 38 after the enum of context ID's. This one

Os::Log osLogger;

This one probably goes all the way back to the Ref deployment.

While this double instantiation doesn't affect anything negatively, you can safely remove either of these instantiations without any effect on the functionality of the particular instance of the Fw::Logger that's currently registered. Happy to discuss this more, but I've run out of time for now and just wanted to get this written down initially.

Using all of the default options, all of the files and folders generated by the template should result in output that is equivalent to the Ref deployment. Allowable differences include whitespace, line endings, and comments.

In the deployment level CMakeLists.txt, the following line is used to specify whether the Baremetal Scheduler should be used for a specific deployment:

set(BAREMETAL_SCHEDULER CACHE BOOL ON "Uses the baremetal scheduler")

However, with Fprime 2.0, the flag that specifies the use of the baremetal scheduler is actually FPRIME_USE_BAREMETAL_SCHEDULER, necessitating that the new line in the deployment Cmakelists.txt be something like:

set(FPRIME_USE_BAREMETAL_SCHEDULER ON).

Within the repository, the cookiecutter should check to see if the user has specified a baremetal deployment and then set the variable as necessary here, along these lines:

{% if cookiecutter.deployment_baremetal_scheduler == "yes" -%}
set(FPRIME_USE_BAREMETAL_SCHEDULER ON)
{%- endif %}

So when I run cookiecutter --overwrite-if-exists --config-file={{cookiecutter.deployment_dir_name}}/.cookiecutterrc gh:sterlingpeet/cookiecutter-fprime-deployment the cookiecutter automatically deletes some of the work I already had within the topology such as importing components etc.

Is there a way for us to run this command and have it only change the directly affected lines vs having it also delete the lines that I added in for my deployment?

When creating an Arduino deployment with the options shown in the .cookiecutterrc file shown below, there are several components in the Topology.cpp file that are missing a regCommands() call.

The default output is this:

/* Register commands */
    cmdDisp.regCommands();
    eventLogger.regCommands();

The output should ALSO include regCommand() calls for the following two components:

1. The LedBlinker component
2. The eePrmDb component

My suspicion is that there needs to be a tweak to the logic when you select "yes" for deployment_parameter_support to make sure these two components have their commands registered. The LedBlinker has no other commands but the set and save parameter commands, and the eePrmDb component would only be included if you selected yes for parameter support.

Here is a copy of the .cookiecutterrc file that I used:

default_context:

    _template:                 'gh:SterlingPeet/cookiecutter-fprime-deployment'
    arduino_log_stream:        'Serial'
    component_dir_name:        'LedBlinker'
    component_explicit_common: ''
    component_explicit_component_suffix: 'Component'
    component_impl_suffix:     ''
    component_instance_name:   'ledBlinker'
    component_kind:            'passive'
    component_multiplatform_support: 'no'
    component_name:            'Led Blinker'
    component_namespace:       'Test'
    component_path_to_fprime_root: '../../..'
    component_short_description: 'Example component to support Test deployment.'
    component_slug:            'LedBlinker'
    dep_short_description:     'test'
    deployment_baremetal_scheduler: 'yes'
    deployment_command_sequence_support: 'no'
    deployment_display_name:   'Test'
    deployment_event_text_log_support: 'no'
    deployment_file_xfer_support: 'no'
    deployment_health_support: 'no'
    deployment_parameter_support: 'yes'
    deployment_path:           'Common'
    deployment_path_to_fprime_framework: '../../fprime'
    deployment_path_to_project_root: '../..'
    deployment_ref_doc_boilerplate: 'no'
    deployment_rg_sched_contexts_hpp: 'no'
    deployment_slug:           'Test'
    deployment_target_platform_support: 'Arduino'
    email:                     '[email protected]'
    full_name:                 'Anthony Limiero'
    license:                   'None'
    startup_arduino_led_flash: 'yes'
    startup_delay_msec:        '2000'

I ran the cookiecutter deployment command from the following location within an fprime project repository: "gt2-software/Common/support" where "gt2-software" is the project root that contains fprime and fprime-arduino as submodules.

When generating a deployment using the options listed in the .cookiecutterrc file listed below, the #include path in the Components.hpp file comes out like this:

#include <LEDBlinkDeployment/LedBlinker/LedBlinkerComponent.hpp>

but it should come out like this:

#include <Common/support/LEDBlinkDeployment/LedBlinker/LedBlinkerComponent.hpp>

The path is missing the "Common/support," which I believe is correlated to the deployment_path option in the .cookiecutterrc file.

Contents of .cookiecutterrc:

default_context:

    _template:                 'gh:SterlingPeet/cookiecutter-fprime-deployment'
    arduino_log_stream:        'Serial'
    component_dir_name:        'LedBlinker'
    component_explicit_common: ''
    component_explicit_component_suffix: 'Component'
    component_impl_suffix:     ''
    component_instance_name:   'ledBlinker'
    component_kind:            'passive'
    component_multiplatform_support: 'no'
    component_name:            'Led Blinker'
    component_namespace:       'LEDBlinkDeployment'
    component_path_to_fprime_root: '../../../..'
    component_short_description: 'Example component to support LED Blink Deployment deployment.'
    component_slug:            'LedBlinker'
    dep_short_description:     'A deployment that blinks an LED'
    deployment_baremetal_scheduler: 'yes'
    deployment_command_sequence_support: 'no'
    deployment_display_name:   'LED Blink Deployment'
    deployment_event_text_log_support: 'no'
    deployment_file_xfer_support: 'no'
    deployment_health_support: 'no'
    deployment_parameter_support: 'yes'
    deployment_path:           'Common/support'
    deployment_path_to_fprime_framework: '../../../fprime'
    deployment_path_to_project_root: '../../..'
    deployment_ref_doc_boilerplate: 'no'
    deployment_rg_sched_contexts_hpp: 'no'
    deployment_slug:           'LEDBlinkDeployment'
    deployment_target_platform_support: 'Arduino'
    email:                     '[email protected]'
    full_name:                 'Anthony Limiero'
    license:                   'None'
    startup_arduino_led_flash: 'yes'
    startup_delay_msec:        '2000'

When creating a cookiecutter deployment for ATmega, the ATmegaSerialDriver component is started with a baud rate of 115K in the Topology.cpp file. It would be beneficial to have an option added for starting the UART driver with a different baud rate by default, that way it is one less step to remember when trying to get a deployment functioning out of the box with GT-2 or ATmegas with clock speeds of 8MHz.

Requesting this feature after discovering that the GDS does not work with a 115K baud rate for the GT-2 ATmega modules, so anyone developing for GT-2 has to manually change the baud rate in their Topology.cpp file. It would be nice as we continue to make deployments in the future to avoid this to streamline our development process and avoid any unecessary headaches because people forget this one small detail.

When FW_OBJECT_NAMES is not set to 1, the component class constructor gets broken.

See below, the constructor header is only defined inside the #if FW_OBJECT_NAMES == 1 block.

Compare to the constructor header declaration in the .hpp file. This should fix it:

#else
{{cookiecutter.component_name}}Component{{cookiecutter.component_explicit_common}}{{cookiecutter.component_suffix}}(void) :
{{cookiecutter.component_name}}Component{{cookiecutter.component_explicit_common}}Base(),
#endif

The following line links to sdd.html when it should be sdd.md.

Small fix needed here:

If the namespace is chosen to be nested, e.g.: Drv::support, then the component's namespace declaration (as output by the template) is of the form:

namespace Drv::support {
  // Component Code Here
}

This format requires C++17 or newer, and generates compiler warnings. The correct output should be:

namespace Drv {
namespace support {
  // Component Code Here
}
}