Ref Namespace Reference

Classes
class	BlockDriver
class	DpDemo
class	PingReceiverComponentImpl
class	RecvBuffImpl
class	SendBuffImpl
	This component sends a data buffer to a driver each time it is invoked by a scheduler. More...
class	SignalGen
struct	TopologyState
	required type definition to carry state More...
class	TypeDemo

Typedefs
typedef PingReceiverComponentImpl	PingReceiver
typedef RecvBuffImpl	RecvBuff
typedef SendBuffImpl	SendBuff

Functions
void	setupTopology (const TopologyState &state)
	initialize and run the F´ topology More...
void	startRateGroups (const Fw::TimeInterval &interval)
	cycle the rate group driver based in a system timer More...
void	stopRateGroups ()
	stop the rate groups More...
void	teardownTopology (const TopologyState &state)
	teardown the F´ topology More...

Typedef Documentation

PingReceiver

typedef PingReceiverComponentImpl Ref::PingReceiver

Definition at line 13 of file PingReceiver.hpp.

RecvBuff

typedef RecvBuffImpl Ref::RecvBuff

Definition at line 13 of file RecvBuff.hpp.

SendBuff

typedef SendBuffImpl Ref::SendBuff

Definition at line 13 of file SendBuff.hpp.

Function Documentation

setupTopology()

void Ref::setupTopology

(

const TopologyState &

state

)

initialize and run the F´ topology

Initializes, configures, and runs the F´ topology. This is performed through a series of steps, some provided via autocoded functions, and others provided via the functions implementation. These steps are:

1. Call the autocoded initComponents() function initializing each component via the component.init method
2. Call the autocoded setBaseIds() function to set the base IDs (offset) for each component instance
3. Call the autocoded connectComponents() function to wire-together the topology of components
4. Configure components requiring custom configuration
5. Call the autocoded loadParameters() function to cause each component to load initial parameter values
6. Call the autocoded startTasks() function to start the active component tasks
7. Start tasks not owned by active components

Step 4 and step 7 are custom and supplied by the project. The ordering of steps 1, 2, 3, 5, and 6 are critical for F´ topologies to function. Configuration (step 4) typically assumes a connect but not started topology and is thus inserted between step 3 and 5. Step 7 may come before or after the active component initializations. Since these custom tasks often start radio communication it is convenient to start them last.

The state argument carries command line inputs used to setup the topology. For an explanation of the required type Ref::TopologyState see: RefTopologyDefs.hpp.

Parameters

state

object shuttling CLI arguments (hostname, port) needed to construct the topology

Definition at line 60 of file RefTopology.cpp.

startRateGroups()

void Ref::startRateGroups

(

const Fw::TimeInterval &

interval

)

cycle the rate group driver based in a system timer

In order to be a portable demonstration, the reference topology does not have a direct hardware timer that is typically used in embedded applications. Instead, a linux system timer is used to drive the rate groups at 1Hz. The slower rate groups are derived from this fundamental rate using the RateGroupDriver component to divide the rate down to slower rates.

For embedded Linux, this could be used to drive the system rate groups. For other embedded systems, projects should write components that implement whatever timers are available for that platform in place of Svc/LinuxTimer.

This loop is stopped via a stopRateGroups call.

Definition at line 87 of file RefTopology.cpp.

stopRateGroups()

void Ref::stopRateGroups

(

)

stop the rate groups

This stops the cycle started by startRateGroups.

Definition at line 95 of file RefTopology.cpp.

teardownTopology()

void Ref::teardownTopology

(

const TopologyState &

state

)

teardown the F´ topology

Tears down the F´ topology in preparation for shutdown. This is done via a series of steps, some provided by autocoded functions, and others provided via the function implementation. These steps are:

1. Call the autocoded stopTasks() function to stop the tasks started by startTasks() (active components)
2. Call the autocoded freeThreads() function to join to the tasks started by startTasks()
3. Stop the tasks not owned by active components
4. Join to the tasks not owned by active components
5. Deallocate other resources
6. Call the autocoded tearDownComponents() function to tear down component-owned resources
7. Call the autocoded deinitComponents() function to finish component shutdown

Step 1, 2, 3, and 4 must occur in-order as the tasks must be stopped before being joined. These tasks must be stopped and joined before any active resources may be deallocated.

For an explanation of the required type Ref::TopologyState see: RefTopologyDefs.hpp.

Parameters

state

state object provided to setupTopology

Definition at line 99 of file RefTopology.cpp.