You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Usb.getDevices() returns a list of all USB devices connected to the system.
for (vardevice : Usb.getDevices()) {
System.out.println(device);
}
List all video cameras connected via USB
Video cameras can be recognized because they have a USB interface implementing the Video class and Video Control subclass.
Since each interface can have multiple alternate settings, the class code and subclass code are found on the UsbAlternateSetting instance. It's sufficient to check the current one.
Get the device with a specific vendor and product ID
The vendor ID and product ID (0xcafe and 0xceaf in this example) uniquely identify a particular type of USB device, i.e. all devices of the same type have the same features and use the same communication protocol (on top of USB).
vartestDevice = Usb.findDevice(0xcafe, 0xceaf);
if (testDevice.isPresent()) {
System.out.println(testDevice.get());
} else {
System.out.println("Device not found");
}
Get notifications about connected and disconnected devices
A separate callback con be registered to be notified when a device is connected or disconnected.
The callback is consumer taking a UsbDevice as its argument. The consumer is called from a background thread.
If multiple devices of the same type are used, the triple of vendor ID, product ID and serial number can be used to uniquely identify a device. This can be useful to save settings related to a particular device.
To send a control request, the device is opened first. controlTrasnferOut takes a UsbControlTransfer as its first argument, consisting of request type, request, value, index and data. The purpose of these values depends on the USB device and is usually provided by the device manufacturer. For devices implementing an official USB class, it is documented in the USB class specification.
For the test device, the possible values and their functionality are documented in GitHub at USB loopback test device. Note that the UsbControlTransfer instance uses separate fields for request type and recipient while they are combined in bmRequestType field in the USB specification.
Interrupt transfers are small packets sent to a USB endpoint with transfer type interrupt. The test device can receive interrupt transfers on endpoint 3. In order to use, the device must be opened and interface 0 must be claimed.
Note: The test device will echo interrupt packet on another interrupt endpoint. If the echoed data is not read, the device will not accept new data. So the test device should be reset or unplugged after this test.
Receive an interrupt transfer
Interrupt transfers are usually used by a USB device for notification about events happening a unpredictable time. So receiving an interrupt transfer consists mainly of waiting, and the host will likely wait for it in a separate thread.
The test device will echo each packet sent to OUT endpoint 3 on IN endpoint 3 twice. In order to use the endpoints, the device must be opened and interface 0 must be claimed.
Data can be sent to endpoints of transfer type bulk in the same way as to endpoints of transfer type interrupt. However, it is more convenient to use an OutputStream.
The test device accepts bulk transfers on endpoint 1. In order to use, the device must be opened and interface 0 must be claimed.
Note: The test device will echo the data on another endpoint. If the echoed data is not read, a small buffer will fill up and the device will not accept new data. So the test device should be reset or unplugged after this test.
Receive a bulk transfer
Data can be received from endpoints of transfer type bulk in the same way as from endpoints of transfer type interrupt. However, it is more convenient to use an InputStream.
The test device loops back all data sent to OUT endpoint 1 to IN endpoint 2. For small amounts of data, it is possible to send it and then receive it in the same thread. For bigger amounts, two separate threads are needed.
Bulk endpoints are a stream based protocol as opposed to a message based protocol. There is no concept of a message boundary. Both the host and the device will merge and split the stream of data into packets as they see fit. If message boundaries are important, the protocol on top of USB must define them. The below code uses the new line character as a message boundary.
In order to use endpoints 1 and 2, the device must be opened and interface 0 must be claimed.
vartestDevice = Usb.findDevice(0xcafe, 0xceaf).orElseThrow();
testDevice.open();
testDevice.claimInterface(0);
// send text to the devicetry (varwriter = newOutputStreamWriter(testDevice.openOutputStream(1))) {
writer.write("Welcome to Java Does USB\n");
writer.write("Have a nice day.\n");
}
// receive echoed texttry (varreader = newBufferedReader(newInputStreamReader(testDevice.openInputStream(2)))) {
System.out.println(reader.readLine());
System.out.println(reader.readLine());
}
testDevice.close();