I’ve been playing with the Processing language (http:\/\/processing.org) a little bit and liking it so far. For anyone not familiar, it’s a Java-based rapid-prototyping language that includes very friendly libraries for graphics, sound, video and select hardware (e.g. serial port). One thing I couldn’t find much info on was talking to arbitrary USB devices (not USB-to-serial based gadgets, but sending and receiving raw packet-level data). <\/p>\n
Anyway, I found a solution that works in Processing with only minimal tweaking. You need:<\/p>\n
Processing (of course) – http:\/\/www.processing.org
\nlibusb or libusb-win32 – http:\/\/libusb-win32.sourceforge.net (Windows) or http:\/\/libusb.wiki.sourceforge.net\/ (Linux)
\nLibusb Java wrapper – http:\/\/libusbjava.sourceforge.net\/wp\/<\/p>\n
I only tried this on Windows so far, so the following assumes a Windows installation.<\/p>\n
(I know, wrappers upon wrappers. So in the end you end up with device -> OS -> libusb -> libusbjava native DLL -> libusbjava JNI wrapper -> Processing. Probably not the most efficient approach in the world, but in the era of multi-GHz machines I’m not sweating too hard about it :-)<\/p>\n
Follow the author’s recommendations on setting up libusb-win32 for your device, if it’s not already been done. Then, (for Windows users) extract the LibusbJava.dll file and drop it somewhere Processing\/Windows can find it. The author recommends \\Windows\\System or equivalent; if this seems a bit forward, dropping it in the same directory as processing.exe works fine too.<\/p>\n
Finally, making the library appear for Processing: create a new folder(-nest) for it in Processing’s libraries folder (blahblah\\processing-0135\\libraries\\libusbjava\\library), and drop the .jar file in it. Rename it to something more sane; Processing doesn’t seem to like all those extra dots and numerals. After renaming the .jar file sanely and restarting Processing, it will appear in the Sketch->Import Library menu. Clicking on the menu item automagically fishes out the correct class names and adds the appropriate (import…) lines to your sketch. From here on out, programming for the libusbjava wrapper appears to follow the actual libusb API pretty closely.<\/p>\n
Here’s the program I tested it with. All it does is connect to a Rez\/Drmn trance vibrator, send a USB packet to turn the motor on at about 2\/3 intensity, then exit.<\/p>\n
\nimport ch.ntb.usb.testApp.*; \/\/ these four lines were automatically added by clicking it
\nimport ch.ntb.usb.*; \/\/ on Processing's Sketch -> Import Library menu item
\nimport ch.ntb.usb.usbView.*; \/\/ ...
\nimport ch.ntb.usb.logger.*; \/\/ Some of these can probably be removed safely.<\/p>\n
void setup()
\n{
\n noLoop();
\n}<\/p>\n
void draw()
\n{
\n LibusbJava.usb_init(); \/\/ required inits for libusb-win32
\n LibusbJava.usb_find_busses(); \/\/
\n LibusbJava.usb_find_devices(); \/\/<\/p>\n
\/\/ retrieve a object tree representing the bus with its devices and
\n \/\/ descriptors
\n Usb_Bus bus = LibusbJava.usb_get_busses();<\/p>\n
\/\/ Find a specific USB device on the bus (by its VID\/PID) and return a handle to the device in 'dev'
\n \/\/ This diverges a bit from native libusb-win32 code in that you don't have to loop through all the devices\/busses searching for it.
\n Device dev = USB.getDevice((short) 0x0b49, (short) 0x064f); \/\/ VID\/PID combination of Drmn' Trance Vibe device<\/p>\n
\/\/ Note: Since this is just a quick n dirty \"hey, is this possible?\" test, I've added no error checking whatsoever.
\n \/\/ For anything more than a tightly-controlled quick hack \/ demo, you will want to do so!! (for starters, check if the device was found at all...)<\/p>\n
try {
\n \/\/ data to write to the device. I don't want to write any data, so leaving this array empty.
\n byte[] data = new byte[] {};
\n \/\/ data read from the device
\n byte[] readData = new byte[data.length];<\/p>\n
\/\/ open the device with configuration 1, interface 0 and without
\n \/\/ altinterface
\n \/\/ this will initialise Libusb for you
\n dev.open(1, 0, -1);<\/p>\n
\/\/ ^^ Note, this may also diverge from native libusb-win32; I've never seen the choice of \"-1\" for alt. interface before (I assume it's interpreted as \"any\/all\/none\/don't-care\"), but it seems to work.<\/p>\n
\/\/ This device uses Control messages on endpoint 0. The following packet turns ON the motor at about 2\/3 intensity (0xAA).<\/p>\n
\/\/ Fields are: Request type (0x41-Out+Write), bRequest, WValue, wIndex, byte[] data, size, timeout, bool reopenOnTimeout
\n dev.controlMsg(0x41, 0x00, 0xAAAA, 0x0000, data, 0, 1000, false);<\/p>\n
\/\/ The \"reopenOnTimeout\" field is a new one. It sounds either flaky-hardware-friendly or extremely dangerous.<\/p>\n
\/\/ ok, motor turned on! I'm satisfied that you can control arbitrary USB devices from Processing at the raw (bulk\/interrupt) packet level, so this is as far as I go for now.<\/p>\n
\/\/ close the device
\n dev.close();
\n } catch (USBException e) {
\n \/\/ if an exception occures during connect or read\/write an exception
\n \/\/ is thrown
\n e.printStackTrace();
\n }
\n}
\n<\/tt><\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve been playing with the Processing language (http:\/\/processing.org) a little bit and liking it so far. For anyone not familiar, it’s a Java-based rapid-prototyping language that includes very friendly libraries for graphics, sound, video and select hardware (e.g. serial port). One thing I couldn’t find much info on was talking to arbitrary USB devices (not […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_FSMCFIC_featured_image_caption":"","_FSMCFIC_featured_image_nocaption":"","_FSMCFIC_featured_image_hide":"","iawp_total_views":31,"footnotes":""},"categories":[4],"tags":[],"class_list":["post-470","post","type-post","status-publish","format-standard","hentry","category-geek"],"_links":{"self":[{"href":"https:\/\/tim.cexx.org\/index.php?rest_route=\/wp\/v2\/posts\/470","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tim.cexx.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tim.cexx.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tim.cexx.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tim.cexx.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=470"}],"version-history":[{"count":0,"href":"https:\/\/tim.cexx.org\/index.php?rest_route=\/wp\/v2\/posts\/470\/revisions"}],"wp:attachment":[{"href":"https:\/\/tim.cexx.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=470"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tim.cexx.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=470"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tim.cexx.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=470"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}