Table of Contents Previous Chapter
The purpose of the Command Device is to provide access to Back End's Command Interface logic and to the Command FIFO.
The Command Device class, CmdDevice, provides the following features:
The CmdDevice is an interruptible device, and is therefore a subclass of IntrDevice (see Section 6.0 ). This class relies on the BepReg class to provide access to the Command hardware control logic and command FIFO.
FIGURE 29. Command Device Class Relationships
CmdDevice- This class represents the Back End's Command Device logic and FIFO. It provides functions which control the state of the command reception hardware logic (disableReceiver, enableReceiver, resetReceiver), and provides access to the Command FIFO (getFifoAddress, isFifoEmpty, readFifo). In addition to theses functions, it inherits the ability to install and invoke interrupt callback instances from IntrDevice.
IntrDevice - This is an abstract class which defines the common interface to all types of interruptible devices. It is used by the Interrupt Controller (not shown) to dispatch control to interruptible devices, and by client code to install callback functions. Child classes of IntrDevice, including CmdDevice, may use their parent's protected method, invokeCallback() to invoke the installed callback instance (see Section 6.0 ).
BepReg- This class represents the lowest level hardware access to the features provided by the Back End hardware control, status, and pulse registers, and to the Command FIFO. See Section 5.0 for a description of this class.
The Back End's command logic provides the ability to receive entire command packets into the command FIFO and generate an interrupt once the entire packet has been received. This significantly reduces the number of interrupts and the rate of interrupts that the Back End Processor must handle in order to receive a command packet.
Once enabled, the command logic interprets the first received 16-bit command word as the count of the total number of words in the packet, including the received length. It then writes the length into the Command FIFO, and proceeds to receive and store subsequent words from the packet until the last word of the packet has been received. Once the last word is in the FIFO, the hardware generates a command interrupt. The hardware then interprets the next 16-bit words as the length of the subsequent packet.
In the event that the length is out-of-range, or if the command FIFO fills when a packet is being received, the command logic will generate an interrupt, and let the software cope with the condition. The condition is indicated in the Back End's Status register.
Since command transfers and error handling require access to buffer pools and intelligent systems-level decision making, the CmdDevice class doesn't explicitly handle the transfer of commands from the FIFO into memory, or these error conditions, but instead, provides the low-level access routines used by the higher level protocol class (in this case, the CmdManager) to deal with these actions.
Refer to Section 4.3.5 for a format description of words read from the Command FIFO. The upper 32-bits of each read word contain status information about the word being read, and the lower 16-bits contain the actual command word received by the DPA hardware from the spacecraft.
In order to support system initialization, and recovery from errors, the CmdDevice provides functions which allow the client to disable the command reception logic, disableReceiver(), and to reset the command FIFO, resetReceiver(). The client code uses these routines during initialization and error recovery to stop the hardware logic from generating command interrupts due to erroneous packet lengths, and to quickly discard the contents of the Command FIFO, respectively. In general, the client code should call disableReceiver() prior to resetting the contents of the Command FIFO.
In order to allow a client to ensure that the FIFO is empty prior to enabling command reception, or to ensure that the FIFO contains valid data prior to reading and interpreting its contents, the CmdDevice provides a function isFifoEmpty() which returns whether or not the FIFO currently contains any data. In order to allow client code to detect errors, it also provides a function, getErrStatus(), which returns the current error status of the Command Logic.
Once the client is ready to receive commands, it uses the CmdDevice enableReceiver() function to enable the command reception logic, which in turn will start generating command interrupts upon each reception of a command packet.
In order to allow a client to obtain the length of a command packet prior to starting a block transfer from the FIFO, the CmdDevice provides a function readFifo() which returns the next word(s) from the Command FIFO.
In order to allow the client code to perform block transfers from the Command FIFO (possibly by using the Mongoose DMA), the CmdDevice provides a function which returns the virtual address of the FIFO, getFifoAddress().
Whenever a packet has been placed into the Command FIFO, or an error is detected by the Command Logic, a Command interrupt occurs. Once the Interrupt Controller (not shown in Figure 29) determines that the Command interface caused the interrupt, it masks off any lower priority interrupt causes and re-enables interrupts. It then dispatches control to the CmdDevice class's handleInterrupt(). The CmdDevice's handleInterrupt() function then resets the interrupt cause, and invokes the installed interrupt callback instance. The callback then performs any client specific operations.
disableReceiver() enableReceiver() getErrStatus() getFifoAddress() handleInterrupt() isFifoEmpty() readFifo() resetReceiver()
Table of Contents Next Chapter