Within this function, a new thread is started. This thread is used to sample the data from the device. The thread creation step may look something like the following:

vpr::ThreadMemberFunctor<ButtonDevice>* functor =
   new vpr::ThreadMemberFunctor<ButtonDevice>(this,
                                              &ButtonDevice::sampleFunction,
                                              NULL);
mThread = new vpr::Thread(functor);

The above creates a thread that will execute ButtonDevice::sampleFunction(), a non-static member function in the class ButtonDevice. The implementation of that method would be similar to the following in most cases

void ButtonDevice::sampleFunction(void* arg)
{
   // Keep working until mRunning becomes false.
   while ( mRunning )
   {
      this->sample();
   }
}

The thread can be tested for validity using the method vpr::BaseThread::valid().

The job of this function is to kill the thread created in startSampling().

This method reads data from the device and stores it for later use by getDigitalData(). Note that ButtonDevice::sampleFunction(), defined above, invokes this method.

Gadgeteer devices typically use triple-buffered data management. This is done to ensure that data is not being written into a buffer when the Input Manager is trying to read the most recent value. The gadget::Input class defines three variables to help programmers keep track of which buffer is in use at any given time: gadget::Input::current, gadget::Input::valid, and gadget::Input::progress. The sampled data would be read into a three-element array of the correct type (this is driver-specific). When writing the freshly sampled data into the array, use gadget::Input::progress:

mSampledDigitalData[gadget::Input::progress] = sampled_digital_value;

Triple-buffered device drivers use this method to swap the data indices. The member function is usually implemented as follows:

void ButtonDevice::updateData()
{
   vpr::Guard<vpr::Mutex> updateGuard(lock);

   // Copy the valid data to the current data so that both are valid
   mSampledDigitalData[current] = mSampledDigitalData[valid];

   // swap the indices for the tri-buffer pointers
   gadget::Input::swapCurrentIndexes();
}

Note the use of a vpr::Guard<> object to synchronize access to the mSampledDigitalData array. This is needed because the sampling and the reading are occurring in separate threads, but both threads need access to mSampledDigitalData.

In the getElementType() function, the element type of the device must be returned. Its name must be as it appears in the configuration definition file for the driver. For example, the implementation for the simple button driver would appear as:

std::string ButtonDevice::getElementType()
{
   return std:string("ButtonDevice");
}

At this time, it is useful to point out that every Gadgeteer device needs an element type associated with it. An element type is similar to a struct in C or C++. The data structure is defined in an configuration definition file (which usually has the extension .jdef). Once defined, the type for a new driver can be used in JCCL configuration files.

The Input Manager uses this method to read digital data sampled by the driver. This is when the triple-buffered data scheme becomes especially valuable. To provide the Input Manager with the most up-to-date sample, use gadget::Input::current as the index, as shown below:

int JoystickDevice::getDigitalData(int devNum)
{
  return mSampledDigitalData[current];
}

Note that in this example, the parameter devNum is ignored. This is not always the case. Indeed, this button driver would likely have support for more than one button, and in that case, we would use devNum as the index into an array or vector containing data sampled from all the buttons.

There are other methods that must be implemented depending on the classes from which a given driver class derives. In the joystick example given earlier, the method getAnalogData() would have to be implemented in addition to getDigitalData(). The prototype for getAnalogData() is:

virtual float getAnalogData(int devNum = 0)

The joystick driver would use this to return values for the X and Y axes. The data here is more complex because it would be for triple-buffered two-dimensional samples. An implementation might look similar to the following:

float JoystickDevice::getAnalogData(int axis)
{
   vprASSERT(axis >= 0 && axis <= 1 && "only 2 axes (x and y) available");
   return mSampledAnalogData[current][axis];
}

In this driver, the integer argument to the method is used to represent either the X or the Y axis. The assertion ensures that a valid axis index is passed.