Re: Nugget: 1 of n : GEtting started with USB communication via VISA

<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><meta name="GENERATOR" content="OpenOffice.org 2.4 (Win32)">



Although
interfacing with a mouse is a relatively easy task, we will look
first at some details of the USB protocol. The best way to visualise
this is by using a USB logger. Under Windows, I personally have found
the (non-free) ?<a href="http://www.hhdsoftware.com/Products/home/usb-monitor.html"; target="_blank">Device
Monitoring Studio</a>? (which seems to have been renamed to ?USB
Monitor? to be of great help. Other, free programs are available
such as ?<a href="http://sourceforge.net/projects/usbsnoop/"; target="_blank">Snoopy
Pro</a>?. These programs sit between the Operating system and the
device driver and records all communication.

Introducing
a USB sniffer at this stage may be deemed overkill, especially for
something relatively simple such a mouse, but it is a valuable tool
which can be used for almost ANY USB device, especially devices for
which you may not have an API description... (i.e.
reverse-engineering).&nbsp; The biggest advantage, however is the
ability to see what data is being sent and received when using ANY
driver, not just VISA as we will be doing later.

By
attaching the device to the host computer and running such program,
we can observe the communication between any program accessing the
device and the device itself. A simple example is a standard mouse.
By attaching a second mouse to the computer (recording one mouse but
controlling the software with another allows cleaner recorded data)
and telling the software to monitor the communication we can observe
what is going on.

The
following was recorded using a standard Microsoft mouse (installed
with a standard Microsoft driver) when clicking and releasing the
left-click button of the mouse:

000053:
Bulk or Interrupt Transfer (DOWN), 25.06.2008 10:58:14.172 +0.0

Pipe
Handle: 0x8a56490c (Endpoint Address: 0x81)

Get
0x4 bytes from the device




000054:
Bulk or Interrupt Transfer (UP), 25.06.2008 10:58:44.968 +30.796.
Status: 0x00000000

Pipe
Handle: 0x8a56490c (Endpoint Address: 0x81)

Get
0x4 bytes from the device

01
00 00 00 &lt;- Data received




000055:
Bulk or Interrupt Transfer (DOWN), 25.06.2008 10:58:44.968 +0.0

Pipe
Handle: 0x8a56490c (Endpoint Address: 0x81)

Get
0x4 bytes from the device




000056:
Bulk or Interrupt Transfer (UP), 25.06.2008 10:58:45.125 +0.156.
Status: 0x00000000

Pipe
Handle: 0x8a56490c (Endpoint Address: 0x81)

Get
0x4 bytes from the device

00
00 00 00 &lt;-- Data received




000057:
Bulk or Interrupt Transfer (DOWN), 25.06.2008 10:58:45.125 +0.0

Pipe
Handle: 0x8a56490c (Endpoint Address: 0x81)

Get
0x4 bytes from the device

The
first thing to note is that the communication taking place is noted
as ?Bulk or Interrupt?. Since we're interfacing
with a HID device, we know it's Interrupt. The data sent via
Interrupt is called a Report. The entire report structure and
it's determination is sufficient for a whole chapter in itself, so I
won't go into more details here.

Interrupt
transfers are designed to allow a device (in this case a mouse) to
send data ?unsolicited?* to the host. While the actual time of
the communication is decided by the device and not the host, the host
must first declare itself ready to listen to the device. Once this is
done, the host is waiting for a response from the device (which may
or may not come depending on whether the device is in use or not).
This preparation for receiving an interrupt from the device is what
we see in the commands 000053, 000055 and 000057 shown above. We can
see from the direction of the communication (DOWN) that it is a
communication from host to device. It is basically declaring itself
ready for the receipt of a Report.

The
other two entries (000054 and 000056) are the Reports sent to the
host from the device upon interaction
.

Relevant Pages

  • Re: Unipod with Nokia 7250i - Anyone drivers ?
    ... if the phone presents its contents as one of the standard USB mass ... Configuration has 1 interfaces ... Endpoint number 1 (device to host) ...
    (comp.sys.acorn.hardware)
  • Re: assessing winusb potential
    ... So it appears in the USB interrupt handler that there is an event ... sent by the host. ... My device writes data to the IN endpoint. ... USB hardware sends the data. ...
    (microsoft.public.development.device.drivers)
  • Re: assessing winusb potential
    ... this is why the host driver must always pend a transfer on the IN endpoint if the device is sending data asynchronously outside of the host asking for it through a protocol. ... as for the exact sequence of events in hw, i am a bit fuzzy, but any book on the usb protocol will tell you. ... Please do not send e-mail directly to this alias. ...
    (microsoft.public.development.device.drivers)
  • Re: USB noise problem
    ... The best site for USB info is: ... If the host hangs, the drivers or other software are improperly written. ... your communication with the USB drivers should have ...
    (comp.arch.embedded)
  • Re: Need help from programming masters (USB hub)
    ... I was thinking of using the USB hub as the device. ... communication is from HOST to HUB. ... Get Jan Axelson's "USB Complete" book which is a good, ... However, as Leo says, it sounds as if you need a complete host stack ...
    (comp.arch.embedded)