|
2. Device Model:
According to the USB specification every USB device is a class
that implements the UsbDevice interface and it is exposed as a
UsbDevice object. Even USB hubs are treated as UsbDevice
objects. The USB hubs is represented as a class that implements
the UsbHub interface which in turn is extended from the
UsbDevice interface. Every USB device may have multiple
configurations associated with it and these configurations are
represented by their respective UsbConfig interfaces. Each
combination of USB device and UsbConfig interface exposes
different functionality which is driven by the configuration
parameters in the UsbConfig. Each individual combination has
different end points associated with them, which can act as a
source or synch of data for that USB device.
Typically clients use a combination of UsbDevice objects and
UsbConfig objects to get access to a device. They then use the
UsbConfig interface to get the corresponding UsbInterface for
the device. The UsbInterface provides access to end points which
are used for sending or receiving data.
3 Event Model:
The Event model of the USB specification is based on the
JavaBeans event model. Since devices can be removed or attached
dynamically, the model needs to have a mechanism to send and
receive events. Each USB device has a set of UsbDeviceListeners
that register themselves to receive notifications about any
events. The device uses the UsbHostManager and UsbServices
objects to add listeners to the host system. The USB events are
delivered asynchronously to the device.
4 USB Pipes Model:
Pipes are the only means of communications between the host and
USB devices. USB devices communicate through device end points,
which in turn communicate through pipes. These pipes are not
physical pipes for data transfer but are modeled as logical
pipes. These logical pipes are objects that belong to a specific
end point and exist as long as the device model exists.
For a pipe to be accessible the pipe must be active, pipes
belonging to end points on an active interface are active while
those on inactive interface settings are inactive. Apart from
being active the Pipes need to be opened before they are used.
To prepare a UsbPipe for communication, the UsbInterface that
owns the UsbPipe needs to be claimed using the claim() method.
If the UsbInterface is already in use by another client, an
exception is thrown. The UsbPipe object can now be obtained
using the getUsbPipe() method. Now the UsbPipe object can be
used to open a pipe by calling the open() method. The pipe is
now ready for any data transmission. A UspPipeException is
thrown if the call fails.
The simplest way to transmit data through the pipes is using a
byte array. The data that needs to be transmitted should be
filled into the byte array if the direction of communication is
out (From the host to the device) and vice versa if the
communication is in. There are two types of communications
possible, synchronous and asynchronous, which are defined in the
UsbInterface. For synchronous communication the syncSubmit(byte
[]) method is used, while the asyncSubmit(byte []) method is
used for asynchronous communication. The synchSubmit() method
will block the control till the transmission is complete and
return the number of bytes transferred or an exception in case
of any problem. After the submission is complete all the
UspPipe’s listeners will receive a data or error event depending
upon the completion status of the operation. The asynchronous
operation returns a SubmitResult object immediately after the
subsystem accepts the submission. It does not wait till the
transmission is completed but allows the client to use the
SubmitResult object to track the submission. The asynchronous
process has a method called waitUntilCompleted() which can be
used to block control till the submission is completed.
The UspPipe’s endpoint’s direction determines if the pipe is
being used for input or output. Output is when data is
transferred from the host to the device and input is the reverse
process. For input the data buffer is filled with data received
from the device while for output the data is passed to the
device. The specification does not have any maximum or minimum
limitations on the size of the data. But the data size is
limited to the UspPipe’s maximum packet size. However if the
data exceeds the packet size it will be sent in segments.
5 Request and Standard Operations:
The Request and USB operations provide a mechanism of performing
standard operations and vendor specific operations on the USB
devices. The USB specification defines a few standard operations
that all devices need to do, which is defined in the
StandardOperations interface. The request results are available
from the Request objects through get methods(). To cater to
different request and the different data encoding mechanisms a
RequestFactory Class is provided to create Requests.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
