Command Program Interface

Can Gedae applications be divorced completely from a workstation?

Yes, Gedae applications can be divorced from a workstation. As part of the ability to embed applications, the Gedae development environment supports the generation of a launch package. The launch package represents a stand-alone application that is ready for downloading to embedded hardware. The launch package reflects the partitioning, mapping and communication types selected by the user during the development process. The launch package is disassociated from the development environment and supports the command program interface so that higher level command and control software can communicate with the signal processing software generated by Gedae.

Embedded hardware typically includes a host controller. The execution of Gedae applications in an embedded environment assumes that presence of a host processor in addition to the DSPs. The host is normally the slot-1 controller in a VME chassis. Gedae currently supports various SPARC, Intel Pentium, and Power PC products. The host processor in conjunction with the Command Program Interface completely removes the need for a workstation display.

What are the details of the Command Program Interface (CPI)?

The Command Program Interface is a very important feature for embedded applications. The functionality provided by the CPI is well defined. The CPI is intended to provide the application developer a mechanism to control the signal processing from external software rather than from the Gedae user interface. This is essential for truly embedded applications. A simple conceptual example is a command and control system. This type of system requires the ability to modify the processing which is performed in the signal processor based on the current state of the overall system. This might include switching from sensor A to sensor B; switching processing modes (e.g., from search to track); responding to operator decisions and actions from a console; etc.

The intent is to provide the developers with the ability to perform many of the actions available through the graphical user interface from higher-level software external to the Gedae application. Consequently, the CPI must provide the ability to load applications; start and stop processing of specific graphs; modify execution parameters; read and write parameters and data; and monitor execution by providing access to data queues in the system. There is a well-defined set of function calls provided to the developer. Functions defined for the CPI that currently are not implemented are associated with Gedae capabilities not yet available, namely run-time graph connection and run-time reallocation.

More Information

For more information on the CPI functions see the CPI_Function table:

CPI Function	Description
appRead	Read launch package information
appGetDirname	Returns name of launch package read by appRead
appGetParams	Returns a list of all user settable parameters in the application
appGetAllParams	Returns a list of all parameters in the application, both settable and derived
appGetInputs	Returns a list of all Inputs in the application. Inputs are defined as input queues which interface that the host
appGetOutputs	Returns a list of all Outputs in the application. Outputs are defined as output queues that interface with the host
appGetPartitions	Returns a list of all the partitions in the application (currently not implemented)
appGetProcessors	Returns a list of all the processors used in the system (currently not implemented)
appGetParam	Returns information on the named parameter
appGetInput	Returns information on the named input
appGetOutput	Returns information on the named output
appGetPartition	Returns information on the named partition
appGetMapping	Returns mapping information for named partition (currently not implemented)
appDataWordsize	Returns the sizeof() of the Gedae data type
appSetMapping	Allow the changing of mappings. Currently the mapping is fixed when the launch package is created. (currently not implemented)
appParamName	Returns name of a parameter, given the handle to the parameter returned by appGetParam
appDataName	Returns name of a data queue, given the handle to the data returned by appGetInput and appGetOutput
appParamNumDimensions	Returns number of dimensions of named parameter
appDataNumDimensions	Returns number of dimensions of named data
appParamValueType	Returns type of named parameter – int, float, complex
appDataValueType	Returns type of named data – int, float, complex
appParamIsConst	Returns true if named parameter is a constant on the graph and not settable
appParamIsSettable	Returns true if named parameter is a settable parameter on the graph
appParamIsDerived	Returns true if named parameter is a derived parameter (derived from settable and constant parameters) and not settable
appParamIsEmbeddable	Returns true if named parameter is used to set a value on an embedded processor – an actual box parameter
appDataIsInput	Returns true if named data queue is an input queue
appParamSet	Sets a parameter’s value, but does not send this information to the embedded process. Should be used in conjunction with appCalculateParam and appUpdateParam
appParamGetSet	Returns the last value that the parameter was set to; does NOT retrieve this information from the embedded processor.
appParamSetDefault	Sets a parameter’s default value, which will override the default value initially read using appRead
appParamGetDefault	Returns the last default value that the parameter was set to; does NOT retrieve this information from the embedded processor.
appParamGetCurrent	Returns the current value of parameter; may or may not be equal to the default or set value, as the current value is calculated
appCalculateParam	Calculates he new value for a list of parameters and the parameters that are derived from it, based on the value the parameters were set to using appParamSet
appCalculateAllParams	As in appCalculateParam, except performs this operation on all parameters in the application
appUpdateParams	Updates parameters on the embedded process with any new values, as calculated using appCalculateParam; used to synchronize updating multiple parameters and offloading parameter calculation from embedded process
appLoadParams	Loads default parameters from a file
appSaveParams	Saves a list of parameters to a file for future retrieval
appSaveAllParams	Saves all parameters to a file for future retrieval
appGetError	Retrieves any error messages that a CPI function set
appPrintError	Retrieves and displays any error messages that a CPI function set
appLoad	Loads and starts application on embedded processor. Starts necessary control communications and downloads schedule(s) to each processor. Does NOT start graph
appReset	Sends reset command to graph
appRun	Sends start command to graph
appStop	Sends stop command to graph
appKill	Kills and cleans up graph and embedded communications
appParamRead	Reads named parameter’s value from graph (currently not implemented)
appParamWrite	Changes named parameter’s value; has the same effect as the sequence appParamSet, appCalculateParam, appUpdateParams
appDataRead	Reads data from named output’s queue. Used to monitor queues
appDataWrite	Writes data to named input’s queue. Used to satisfy flow graph data requirements on inputs
appConnect	Connects two data queues. Can be used to dynamically restructure the graph (currently not implemented)
appDisconnect	Disconnects data queues between launch packages (currently not implemented)
appFree	Frees memory that is allocated when appRead is called
appDataFree	Frees memory that is allocated when using appDataRead and appDataWrite
appParamFree	Frees memory that is allocated when using appParamRead and appParamWrite
appConnectFree	Frees memory allocated when using appConnect and appDisconnect (currently not implemented)

More Information