#include <CVMUSB.h>
class CVMUSB {
public:
virtual int vmeWrite32(uint32_t address, uint8_t aModifier, uint32_t data);
virtual int vmeWrite16(uint32_t address, uint8_t aModifier, uint16_t data);
virtual int vmeBlockWrite32(uint32_t base, uint32_t aModifier, uint32_t* pData, size_t nTransfers);
virtual void delay(uint32_t amount);
virtual void loopUntil32(uint32_t address, uint8_t amod, uint32_t mask, uint32_t value);
virtual void loopUntil16(uint32_t address, uint8_t amod, uint32_t mask, uint32_t value);
std::vector<std::string> getRecordedOperations();
void clearRecordedOperations();
virtual int executeList(CVMUSBReadoutList& list, void* pReadBuffer, size_t readBufferSize, size_t* bytesRead);
std::vector<uint8_t< executeList(CVMUSBReadoutList& list, int maxBytes);
};
This class implements a subset of the VMUSBReaodut's CVMUSB Since the
class is used in the context of an offline translator from VMUSBReadout configuration files
to fribdaq-readout yaml configuration files, reads are not supported. The
operations requested of a CVMUSB are memorized and, later dumped into the
appropriate segments of the final configuration file.
Remembering that you are not connected to the hardware is an important part of
porting VMUSBReadout drivers to mvlc_generate code generators. Compilation will detect and
flag as errors attempts to read the hardware, however a more subtle issue is that many
VMUSBReadout drivers implement delays as calls to either
sleep(3) or usleep(3). This will not have the desired effect.
Instead of a delay in, e.g. the initialization of the device, mvlc_generate will delay as it is tranlating
the configuration file. Use the delay of this
CVMUSB class instead.
int vmeWrite32(uint32_t address, uint8_t aModifier, uint32_t data);
Stores a 32 bit wide write operation of data
to the address in the address space specified by
aModifier. Remember, the operation is not actually
done when this method is called, it is later put into a list of operations
the readout will perform when it's supposed to. This is your last warning.
On success, 0 is returned. Failure is not possible in the base class, however
it is flagged by a return value of -1 with a meaningful value of errno
int vmeWrite16(uint32_t address, uint8_t aModifier, uint16_t data);
Same as vmeWrite32, however data
and the actual transfer are 16 bits wide.
int vmeBlockWrite32(uint32_t base, uint8_5 aModifier, uint32_t* pData, size_t nTransfers);
Transfers a block of nTransfers
consecutive uint32_t values from
pData to the block of VME
address space specified by base in the
address space specifiec by aModifier
Note that as the MVLC does not have a block write operation,
this just generates several equivalent calls to vmeWrite32
void delay(uint32_t amount);
Implemewnts a delay that will occur at this point in the operation
list that is being generated. amount is the
length of the delay in 200ns units. These units are chosen to be
compatible with the VMUBSReadout. The actual underlying units are
62.5ns and a sufficient number of 62.5ns periods will be generated to delay
for at least the requested time.
void loopUntil32(uint32_t address, uint8_t amod , uint32_t mask, uint32_t value);
In VMUSBReadout, one could wait for a condition in board by polling it. This can't be done directly with the generator's off line operation. The MVLC, however does have sufficient richness in its operation set to do this autonomously.
The value from the read specified by address and
amod is repeated until, when bitwise anded with
mask the resulting value is equal to value.
This provides the ability to wait until a bit field within a devide has
reached a specified value.
void loopUntil16(uint32_t address, uint8_t amod , uint32_t mask, uint32_t value);
Same as loopUntil32 but the read performed is only
16 bits wide.
std::vector<std::string> getRecordedOperations();
Returns the list of memorized operations in a form that allows the operations to be placed into the Yaml configuration file. Note that this is normally called by the mvlc_generate framework and you won't need to call it in your code.
This method is non-destructive. That is the list of operations is not modified.
void clearRecordedOperations();
Clears the list of saved operations.
int executeList(CVMUSBReadoutList& list, void* pReadBuffer, size_t readBufferSize, size_t* bytesRead);
The VMUSB can operate on lists of operations. These are normally
organized in a CVMUSBReadoutList object and,
during initialization and end run, executed in a CVMUSB
object. In our case, executeList just
appends the operations in list to the list of operations
being maintained by the CVMUSB object.
Since no reads can be done, the remainig parameters, which have to do with
providing a buffer for the results of read operations and its size are not
important since pReadBuffer will never be stored to.
bytesRead for consistency, however, will always have a
zero stored in it.
std::vector<uint8_t> executeList(CVMUSBReadoutList& list, int maxBytes);
With the VMUSB this was a simplified version of executeList
In fact what this method does is append the list
to the list of operations memorized by the CVMUBS object.
It returns an empty vector as reads are not done.