Base class for all the OpenViBE acquisition server drivers. More...
Public Member Functions | |
| IDriver (IDriverContext &rDriverContext) | |
| Constructor. More... | |
| virtual | ~IDriver (void) |
| Destructor. | |
General purpose functions | |
| virtual const char * | getName (void)=0 |
| Gets the driver name (usually the hardware name) More... | |
| virtual OpenViBE::boolean | isFlagSet (const OpenViBEAcquisitionServer::EDriverFlag eFlag) const |
| Tests if a flag is set for this driver. More... | |
Driver configuration | |
| virtual OpenViBE::boolean | isConfigurable (void)=0 |
| This function should tell whether the dirver is configurable or not. More... | |
| virtual OpenViBE::boolean | configure (void)=0 |
| Requests the driver to configure itself. More... | |
Initialization / uninitialization | |
| virtual OpenViBE::boolean | initialize (const OpenViBE::uint32 ui32SampleCountPerSentBlock, OpenViBEAcquisitionServer::IDriverCallback &rCallback)=0 |
| Initializes the driver. More... | |
| virtual OpenViBE::boolean | uninitialize (void)=0 |
| Uninitializes the driver. More... | |
| virtual const OpenViBEAcquisitionServer::IHeader * | getHeader (void)=0 |
| Gets the header information for the session. More... | |
Starting / Stopping acquisition | |
| virtual OpenViBE::boolean | start (void)=0 |
| Starts acquisition for this driver. More... | |
| virtual OpenViBE::boolean | stop (void)=0 |
| Stops acquisition for this driver. More... | |
| virtual OpenViBE::boolean | loop (void)=0 |
| Requests data acquisition to be done. More... | |
Protected Attributes | |
| OpenViBEAcquisitionServer::IDriverContext & | m_rDriverContext |
| The driver context. | |
Detailed Description
Base class for all the OpenViBE acquisition server drivers.
- Date
- 2007-04-01 This class should be used by hardware driver developers in order to add new peripherals to the OpenViBE acquisition server. This driver is then used by the server to get cerebral activity measurments and to send this measured activity to the platform so it can be processed.
The behavior of the driver is splitted into 3 phases :
- configuration
- initialization / uninitialization
- acquisition start / stop
The implemented driver could either have direct access to the hardware or read the measurements from a proprietarry server, depending on the hardware manufacturer choice. Thus, the configuration phase of this driver should be able to provide the information OpenViBE needs that are not present from the hardware manufacturer'.
Important job for the driver is to give the acquisition server fixed size measured buffers... This implies that if the hardware sends random size buffers, sample per sample buffers, fixed length buffer but not the size the acquisition server requested, it would be the driver's job to rebuild correct buffers.
- See also
- CAcquisitionServer
Constructor & Destructor Documentation
|
inline |
Constructor.
- Parameters
-
rDriverContext [in] : the driver context
Member Function Documentation
|
pure virtual |
Gets the driver name (usually the hardware name)
- Returns
- the driver name.
|
inlinevirtual |
Tests if a flag is set for this driver.
- Parameters
-
eFlag [in] : the flag to test
- Returns
- true if the tested flag is set
- false if the tested flag is not set
- Note
- Default implementation always returns false, meaning that no flag is set
|
pure virtual |
This function should tell whether the dirver is configurable or not.
- Returns
- true if this driver is configurable.
- false if this driver is not configurable.
- See also
- configure
|
pure virtual |
Requests the driver to configure itself.
- Returns
- true if the configuration ended successfully
- false if the configuration ended with an error
This function requests the driver to configure itself. The acquisition server never calls this function if isConfigurable returned false. However, calling this reflects a lack of information from the hardware itself or from the server that is provided by the hardware manufacturer. The configure function should then ask the user for missing information to be filled.
Filling these information can be done any way you want... But if the driver developer wants to use a GUI for this, it is recommended to use Glade/GTK since the acquisition server already uses this API. If you use Glade/GTK, you won't have to perform API initialization ; this is done by the acquisition server already. It is the responsability of the driver developer to release any allocated GUI object after the configuration is done.
- See also
- isConfigurable
|
pure virtual |
Initializes the driver.
- Parameters
-
ui32SampleCountPerSentBlock [in] : the number of samples to send per channel per driver send operation. rCallback [in] : the callback object to call when the buffer are filled correctly.
- Returns
- true in case of success.
- false in case of error.
When called, this function should prepare the driver to receive data from the hardware. This means doing everything from checking the hardware is present, checking its configuration, getting header information from it and so on. This function should return only when it has a valid header to return to the acquisition server... For some hardware, this could nead data sending request (so it gets basic information), and then request data sending to stop...
- See also
- uninitialize
- getHeader
- IHeader
|
pure virtual |
Uninitializes the driver.
- Returns
- true in case of success.
- false in case of error.
This function disconnects any link to the hardware and frees any allocated structures/objects related to the hardware. When this is called, the driver may be re-configured and re-initialized to start a new acquisition session.
|
pure virtual |
Gets the header information for the session.
- Returns
- the header information for the session
The returned header is used by the acquisition server to send encapsulated data to the platform at the beginning of the sending process. This header should be filled by the information collected from the hardware or the driver itself when configure is called.
- See also
- IHeader
|
pure virtual |
Starts acquisition for this driver.
- Returns
- true in case of success.
- false in case of error.
This function is called by the acquistion server to notify the driver that signal acquisiton should start... The driver should forward this instruction to the hardware... The loop function is then called repeatedly to receive data from the hardware and send it back to the server.
|
pure virtual |
Stops acquisition for this driver.
- Returns
- true in case of success.
- false in case of error.
This function is called by the acquistion server to notify the driver that signal acquisiton should stop... The driver should forward this instruction to the hardware... The loop function is then no more called and the driver may be uninitialized to be re-configured.
|
pure virtual |
Requests data acquisition to be done.
- Returns
- true in case of success.
- false in case of error.
This function is called repeatedly by the acquisition server when the driver is correctly initialized and started. The driver's job here is to receive measures from the hardware, build the buffers according to the requested sampling count per channel (see initialize) and send this built buffer to the provided callback object. The server will then send these informations to the platform.
During this loop function, the object passed as IDriverCallback at the initialize phase should be ready to be notified of samples or stimulations.
- Warning
- When implementing the driver, one should take care of configuring stimulation dates so that they are relative to the last buffer start time.
Generated on Tue Jun 26 2012 15:25:54 for Documentation by
1.7.4