Executing Port in setupTopology()

[maxfirefly]

There is a "startup job" that I want to execute before the rategroups of my deployment start ticking. One way I have thought of doing this entails calling a public function in my component at the very end of setupTopology(), e.g.:

setupTopology() {
    init, connect, configure components etc...
    someComponent.publicFunction();
}

where publicFunction() calls a number of components' ports that are configured and connected in topology.fpp
is there any risk/inherent problems with this design pattern that includes calling ports outside the context of rategroups?

an alternate implementation includes putting the publicFunction() inside one of the rate groups, and only calling it once during the first execution utilizing a firstCycle = true type flag. this also requires setting the offset of all other rategroups to be nonzero to make sure this port is executed first. it also means the port will only be used once, but executed continuously

if there's any reason to use one implementation over the other, or an entirely different implementation, do let me know. thanks

[timcanham]

There is nothing special about calling ports in a rate group. As long as the ports are all connected when you call your publicFunction(), it should be fine as long as you know what is happening is safe from a system perspective.

[maxfirefly]

okay so if I'm understanding the idea is to put the publicFunction() call after startTasks() is executed in setupTopolgy() but before startSimulatedCycle() is called in Main.cpp, and set up the publicFunction() call to wait for a complete status from the cmd sequencer

[timcanham]

That's the idea. You would have to have some kind of synchronization between the port getting the sequence done call and the main thread starting the cycling. You might make this into a more formal interface where you have a cycler component that waits for a port call from someComponent that will start cycling. Note that if this is for a more than an experiment and could be used in a flight system that has to start reliably you have to take into account things like the sequence not running (corrupted file?), a failed command in the sequence, etc. This is where something like a mode manager with timeouts and fault protection might be better than stalling the cycling. The cycling may be checking for other fault conditions that wouldn't be wise to delay. You can have a mode manager with a basic set of states like "init" or "configure" or "nominal." Other parts of the system waiting for the initial sequence to complete can check a mode rather than being stalled.

[maxfirefly]

I am quite a ways through implementing what you have suggested here (fault handling interface and whatnot), but am realizing a contradiction in my requirements: if any of the commands include an async command to a queued component, the command sequence cannot complete before rate groups start since the dispatch calls live in rate group hooked ports; thus, the seqDone port in the command sequencer will not be called until the rategroups begin cycling. i.e. there's a circular dependency between the boot up command sequence finishing and the rate groups waiting for a "seqDone" port call
This is not an issue with the PRM_SET commands (which is the primary use case for this functionality), since they are synchronously executed. However, I can't think of a workaround to the queued command problem...

[timcanham]

Is there a reason you are using PRM_SET commands instead of just using stored parameters?

[maxfirefly]

The reason is the parameter database files are not human readable, and there is no way to set, save, or create parameter database files without the fsw running and using the command handlers. Most of all because parameter databases are not trivial to create and maintain.

So, this effort is to make the process of setting, staging, saving/creating DB files simple while using the existing F' framework: the user just needs to write a command sequence and execute the app with a command-line arg: ./deployment -s <seq_name>

an example sequence to run the FSW with certain param values (no db needed):
component.PARAM_1_PRM_SET 256
where component.PARAM_1 will be value 256 for that run

the user could also create a db for future use by running the fsw with this sequence:

component.PARAM_1_PRM_SET 256
component.PARAM_1_PRM_SAVE
prmDb.PRM_SAVE_FILE

and I also added a command line arg for setting the prmDb name, so if the user runs the above sequence with ./deployment -s <seq_name> -d <db_name>, the user now has a parameter db with those values saved to a db named <db_name>

and lastly, once the user has a number of parameter databases to choose from, they can simply use the -d flag on its own to run the fsw with specified prmdb: ./deployment -d <db_name>

if there is a more trivial way to create DB files that I am overlooking please let me know, because command sequences/command handlers in general are the only way I've thought of

EDIT: This is all driven by the goal of rerunning the FSW with different parameter values without recompiling--so modifying the default value and having no DB is ruled out.