Anne

Today, I feel pretty optimistic about this project, even though I am not any closer to the goal:
“many devices these days [including this sensor] are made as generic HID (Human Interface Devices) that comply with the USB specifications, so you can enumerate and create a handle to the device (treat it like a file) within c/c++.”

Generic is good. I don’t have to write a driver. C is good, I don’t need to learn about the kernel. Ok, so it can be done, but how?

What I learned about my USB device and its driver

In applications, there is a utility called console which records error message and background processes. Clicking on the log icon shows that there are several logs going on. But only the default one shows any activity when I start the game.

USBSimpleExample: Starting

Found device 0x000091ab

dealWithDevice: found 1 configurations

found interface: 0x000092db

dealWithInterface: found 2 pipes

dealWithPipes: grabbing BULK IN pipe index 1, number 1

dealWithPipes: grabbing BULK OUT pipe index 2, number 2

It seems to me that the game called a generic USB driver called USBSimpleExample which sets up the pipe communications for the device throught the hierarchy described below:

The device is associated to pipes which are connections from the host controller to a logical entity on the device named an endpoint. The pipes are synonymous to byte streams
each pipe is uni-directional, either in or out of the device. endpoint 0 is used to control the device on the bus

To access an endpoint, a hierarchical configuration must be obtained.

1. The device connected to the bus has one (and only one) device descriptor

2. the device descriptor has one or more configuration descriptors. These configurations often correspond to states, e.g. active vs. low power mode.

3. Each configuration descriptor in turn has one or more interface descriptors, which describe certain aspects of the device, so that it may be used for different purposes: for example, a camera may have both audio and video interfaces.

4. Each interface descriptors in turn have one default interface setting and possibly more alternate interface settings

5. Each interface setting has an endpoint descriptor, as outlined above. An endpoint may however be reused among several interfaces and alternate interface settings.

Devices that attach to the bus can be full-custom devices requiring a full-custom device driver to be used, or may belong to a device class. the same device driver may be used for any device that claims to be a member of a certain class. HID is one such device class.
http://en.wikipedia.org/wiki/Universal_Serial_Bus

So there is a generic USB driver. Somehow you tell it you want to talk to your particular device, it finds the device, talks to the device, finds out from the device how many pipes to set up, in this case one for in, one for out.

So I can learn how to access a generic USB device, or how to access a HID compliant device. A third possibility is to see if I can access my sensor through matlab and the psychtoolbox. Quite a few ways to go.
http://psychtoolbox.org/usb.html

I have decided to try to talk to my wild divine hardware. This means diving into the computer world, and getting way over my head. By the look of it, I will never make it. But if I do make it, I better leave a trail behind, for any lost soul out there, who finds the earth is not complex enough as it is, and wants to explore human’s ephemeral technical world.

So the problem is simple enough. I have a biosensor which measures heart beat and electrical conductance, or some such. this sensor talks through a USB port to a software game, the wild divine. How can I write a program that accesses the sensor and plots the data in real time.

The net says an application cannot access a hardware device directly. It needs to talk to a “Device Manager” or “I/O Kit” or else talk to a manager which will talk to this device manager, and the device manager talks to a “device driver” which talks to the “hardware device”.

I have the game installed on my computer. So although I have not idea where, or if this file is readable, there should already be a device driver for the sensor.

Also, I am not starting from scratch. Someone created an open software for PC which is supposed to do what I want to do. http://sourceforge.net/projects/lsm/ It has about a 100 files, which is not really encouraging, but there is a file with USB and lightstone in the name that seems to read information from the sensor, so that file may be the meat of the matter (the driver) for the PC.

Through a couple fas computer help desks, I have located two sources of help. There is a group of employees at Harvard called abcd, which gathers people into email lists concerning various hardware/software interests. There is also a computing society linked through the computer department.

Through ABCD I got a response from BU about a tutorial in linux on how to write a device driver
http://www.linuxjournal.com/article/7353
This gives no information on what language/compiler etc is used to create, build and load the driver, or to bind it to hardware, so it is not a lets start from scratch tutorial, but at least, it suggests that a device driver can be writen.