Standard FPP boilerplate could perhaps be avoided

[havelund]

Below is an example of the LedBlinker. It consists of user provided information, followed by generated boilerplate ("Standard AC Ports: ..."). It would be nice if the boilerplate did not appear at all in these FPP files. It is annoying to type as a user. Therefore it is generated. But that seems to slightly defeat the purpose of a DSL. A DSL should be a language you can conveniently program/model in.

module LedBlinker {
@ Component to blink an LED driven by a rate group
active component Led {

    @ Command to turn on or off the blinking LED
    async command BLINKING_ON_OFF(
        onOff: Fw.On @< Indicates whether the blinking should be on or off
    )

    @ Reports the state we set to blinking.
    event SetBlinkingState($state: Fw.On) \
        severity activity high \
        format "Set blinking state to {}."

    @ Reports the LED blink interval set
    event BlinkIntervalSet(interval: U32) \
        severity activity high \
        format "LED blink interval set to {}"

    @ Reports LED state changed
    event LedState(onOff: Fw.On) \
        severity activity low \
        format "LED is {}"

    @ Telemetry channel to report blinking state.
    telemetry BlinkingState: Fw.On

    @ Telemetry channel to report LED transitions
    telemetry LedTransitions: U64

    @ Blinking interval in rate group ticks
    param BLINK_INTERVAL: U32 default 1

    @ Port receiving calls from the rate group
    async input port run: Svc.Sched

    @ Port sending calls to the GPIO driver
    output port gpioSet: Drv.GpioWrite

    ###############################################################################
    # Standard AC Ports: Required for Channels, Events, Commands, and Parameters  #
    ###############################################################################
    @ Port for requesting the current time
    time get port timeCaller

    @ Enables command handling
    import Fw.Command

    @ Enables event handling
    import Fw.Event

    @ Enables telemetry channels handling
    import Fw.Channel

    @ Port to return the value of a parameter
    param get port prmGetOut

    @Port to set the value of a parameter
    param set port prmSetOut

}

}

[Kronos3]

Standard framework ports can be added to an FPP interface and imported. This is already done with Fw.Command, Fw.Event, Fw.Channel. In theory we could add a framework interface:

module Fw {
    interface StandardPorts {
        import Fw.Command
        import Fw.Event
        import Fw.Channel
        import Fw.Parameter
     }
}

This does not require any changes to FPP.

[havelund]

A topology.fpp file (see below) contains even more boilerplate, making it effectively impractical to write a model in FPP without parts of it being generated. I think it would be useful if FPP was a language a user
could model in directly. Just like one would use e.g. SQL, or of course: a programming language.
As it is now it comes across as an intermediate language.

module LedBlinker {

----------------------------------------------------------------------

Symbolic constants for port numbers

----------------------------------------------------------------------

enum Ports_RateGroups {
rateGroup1
rateGroup2
rateGroup3
}

topology LedBlinkerDeployment {

----------------------------------------------------------------------

Subtopology imports

----------------------------------------------------------------------

import CdhCore.Subtopology
import ComCcsds.Subtopology
import DataProducts.Subtopology
import FileHandling.Subtopology

----------------------------------------------------------------------

Instances used in the topology

----------------------------------------------------------------------

instance chronoTime
instance rateGroup1
instance rateGroup2
instance rateGroup3
instance rateGroupDriver
instance systemResources
instance timer
instance comDriver
instance cmdSeq
instance led
instance gpioDriver

----------------------------------------------------------------------

Pattern graph specifiers

----------------------------------------------------------------------

command connections instance CdhCore.cmdDisp
event connections instance CdhCore.events
telemetry connections instance CdhCore.tlmSend
text event connections instance CdhCore.textLogger
health connections instance CdhCore.$health
param connections instance FileHandling.prmDb
time connections instance chronoTime

----------------------------------------------------------------------

Telemetry packets (only used when TlmPacketizer is used)

----------------------------------------------------------------------

# include "LedBlinkerDeploymentPackets.fppi"

----------------------------------------------------------------------

Direct graph specifiers

----------------------------------------------------------------------

connections ComCcsds_CdhCore {
  # Core events and telemetry to communication queue
  CdhCore.events.PktSend -> ComCcsds.comQueue.comPacketQueueIn[ComCcsds.Ports_ComPacketQueue.EVENTS]
  CdhCore.tlmSend.PktSend -> ComCcsds.comQueue.comPacketQueueIn[ComCcsds.Ports_ComPacketQueue.TELEMETRY]

  # Router to Command Dispatcher
  ComCcsds.fprimeRouter.commandOut -> CdhCore.cmdDisp.seqCmdBuff
  CdhCore.cmdDisp.seqCmdStatus -> ComCcsds.fprimeRouter.cmdResponseIn
  
}

connections ComCcsds_FileHandling {
  # File Downlink to Communication Queue
  FileHandling.fileDownlink.bufferSendOut -> ComCcsds.comQueue.bufferQueueIn[ComCcsds.Ports_ComBufferQueue.FILE]
  ComCcsds.comQueue.bufferReturnOut[ComCcsds.Ports_ComBufferQueue.FILE] -> FileHandling.fileDownlink.bufferReturn

  # Router to File Uplink
  ComCcsds.fprimeRouter.fileOut -> FileHandling.fileUplink.bufferSendIn
  FileHandling.fileUplink.bufferSendOut -> ComCcsds.fprimeRouter.fileBufferReturnIn
}

connections Communications {
  # ComDriver buffer allocations
  comDriver.allocate      -> ComCcsds.commsBufferManager.bufferGetCallee
  comDriver.deallocate    -> ComCcsds.commsBufferManager.bufferSendIn
  
  # ComDriver <-> ComStub (Uplink)
  comDriver.$recv                     -> ComCcsds.comStub.drvReceiveIn
  ComCcsds.comStub.drvReceiveReturnOut -> comDriver.recvReturnIn
  
  # ComStub <-> ComDriver (Downlink)
  ComCcsds.comStub.drvSendOut      -> comDriver.$send
  comDriver.ready         -> ComCcsds.comStub.drvConnected
}

connections FileHandling_DataProducts {
  # Data Products to File Downlink
  DataProducts.dpCat.fileOut -> FileHandling.fileDownlink.SendFile
  FileHandling.fileDownlink.FileComplete -> DataProducts.dpCat.fileDone
}

connections RateGroups {
  # timer to drive rate group
  timer.CycleOut -> rateGroupDriver.CycleIn

  # Rate group 1
  rateGroupDriver.CycleOut[Ports_RateGroups.rateGroup1] -> rateGroup1.CycleIn
  rateGroup1.RateGroupMemberOut[0] -> CdhCore.tlmSend.Run
  rateGroup1.RateGroupMemberOut[1] -> FileHandling.fileDownlink.Run
  rateGroup1.RateGroupMemberOut[2] -> systemResources.run
  rateGroup1.RateGroupMemberOut[3] -> ComCcsds.comQueue.run
  rateGroup1.RateGroupMemberOut[4] -> ComCcsds.aggregator.timeout
  rateGroup1.RateGroupMemberOut[5] -> led.run

  # Rate group 2
  rateGroupDriver.CycleOut[Ports_RateGroups.rateGroup2] -> rateGroup2.CycleIn
  rateGroup2.RateGroupMemberOut[0] -> cmdSeq.schedIn

  # Rate group 3
  rateGroupDriver.CycleOut[Ports_RateGroups.rateGroup3] -> rateGroup3.CycleIn
  rateGroup3.RateGroupMemberOut[0] -> CdhCore.$health.Run
  rateGroup3.RateGroupMemberOut[1] -> ComCcsds.commsBufferManager.schedIn
  rateGroup3.RateGroupMemberOut[2] -> DataProducts.dpBufferManager.schedIn
  rateGroup3.RateGroupMemberOut[3] -> DataProducts.dpWriter.schedIn
  rateGroup3.RateGroupMemberOut[4] -> DataProducts.dpMgr.schedIn
}

connections CdhCore_cmdSeq {
  # Command Sequencer
  cmdSeq.comCmdOut -> CdhCore.cmdDisp.seqCmdBuff
  CdhCore.cmdDisp.seqCmdStatus -> cmdSeq.cmdResponseIn
}

connections LedBlinkerDeployment {
  # LED to GPIO driver
  led.gpioSet -> gpioDriver.gpioWrite
}

}

}