I'm in a project that must perform "tests" on USB Pen Drives.
For that, I'm using a USB Hub (49 port Asic Miner - I'm using it due the number of ports).
I intend to plug 49 USB Pen drives on the HUB and test them using a Linux Java App. The test consists on "check if it is recognized", "storing and deleting data" and "check the size".
My problem is on the first step. If there is any Pen Drive that is not working properly, the system will recognize 48 pen drives, but I'll never know the specific device that is not working.
My question is: Is there any way to know the address (or something like that) of a specific usb port on a usb hub? For example: If I connect just one USB Pen Drive on port "34", my software will know that the device is connected on that specific port.
Thank you very much for your time and for your help!
Use Runtime to execute the Linux command mount. It will list all devices currently mounted, manually or automatically, like:
/dev/sdb5 on /media/xdrive type ext4 (rw,nosuid,nodev,uhelper=udisks)
/dev/sdj1 on /media/Website type vfat (rw,nosuid,nodev,uhelper=udisks,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,flush)
Here, second line describes the USB stick I have just plugged in (running Ubuntu). It can be easily recognized from the filesystem (vfat, and the hard drive above uses ext4) and it is mounted on /media/Website (because 'Website' is the stick label that has been used when formatting the stick in vfat). It should be trivial to parse the output and locate the mounted sticks (when formatting, I suggest to give the known labels matching the stick numbers).
If needed, you can put more information into the small file directly on the stick.
You can capture the output through the Process.getOutputStream().
When done, you can safely unmount the sticks before pulling them out:
umount /media/Website
You should check these libraries jUSB and usb2java (they are a little out of date though).
However JNI will allow you to create an interface that interacts with different Operating Systems. This would allow you for cross-platform functionality. I'd look into libUSB (because you are looking for Linux) for a good start!
Hope that helps! :)
Related
i am working on a method to import files which are stored on an usb device to my database.
I already done it for Mac and Windows, but I don't know how to get the path to the usb device when the application is used under Linux/Ubuntu with java.
Is there a way to find the path?
I don't think there is any way that is guaranteed to work on all Linux systems. There are a few approaches I have used, with varying degrees of success.
A method that requires no external utilities is to enumerate and parse the pseudo-files in /dev/disk, /proc/mounts, and /sys/bus/usb, and build a representation of the USB devices that hold storage. There might be more than one, so you might still have to make some guesses, or offer users a choice. This is a pretty tedious method, but I think it is the most general. You can just look at /media, /run/media, as somebody else suggested, but this only works on some Linux installations, and only if that form of auto-mounting is enabled.
A less tedious approach is to invoke the utility udisksctl from your program. I think this utility exists for almost all Linux variants, but it isn't always installed by default. The output of the utility has to be parsed, but it's less hassle that working directly with the kernel psedofiles.
To get a list of disk devices, execute udisksctl status. This will tell you the model name, which will often include the text "USB", and the block device (e.g., /dev/sdb). Then you can execute udisksctl info -b /dev/sdb and look for the line that begins "MountPoints". If the device is not mount you could, if you wished, force it by executing udisksctl mount.... There's a heap of other useful stuff that udisksctl can do -- see its man page.
In Java you can use Runtime.exec() to run udisksctl, but it's probably friendlier to users to check that it is installed first, by check for the existence of /usr/bin/udisksctl.
The easiest way I found is using the Volumes directory.
/Volumes/NAME_OF_USB_DRIVE/file.whatever
I am looking to record movement based on GPS, and plan to record it on the laptop that is in the vehicle. It looks like GlobalSat BU-353 is a good pick, but I am not clear on how to write a program for the actual receive/record. The existing answer seems to be fore Serial, and does not appear to be helpful for USB systems. I could use a USB-to-serial converter with a Serial based GPS device, but I don't like this complexity.
Can you point me a working example? I don't mind using a foreign language (Python perhaps), as long as I can run it on Windows without too much installation/programming headache. Please point me to evidence that this can be done, and how. Preferably a working example that was tested with x USB receiver.
Also I would like information on what the risk of compatibility problems there would be. I would expect that there are many programs out there along with many GPS devices so that a standard has been established (like USB cameras), but is this really the case?
Look up Prolific Technology USB-to-serial converter software. You install it, then your USB device data can be read off of one of Windows COM ports. I'm using the RXTX library to read the com port that is getting my USB data (RXTXcomm.jar).
It's a bit of a pain, because you don't know for sure which COM port is going to be used, it can depend on the order things are plugged into the USB ports on the machine, etc. On some machines, the same physical USB port tends to gravitate towards the same COM port, however, so maybe that will make things predictable enough. Anyway, that's what I'm using to read USB data. At least it's the installed converter, which does not involve code, and everything is java from there.
Yes, there is a defacto standard for the GPS output, the NMEA data strings. All the USB GPS devices I've come across use this. Essentially, as soon as they're turned on (which means as soon as they're plugged in), they start emitting strings of data in the NMEA format. The first letters designate what kind of record is being reported, and the rest of the string is the data. I'm sure some of them also have query capability, etc., but given the nature of GPS programs in general it also works in a lot of cases just to have the device spit out the characters until someone unplugs it. Each string is less than some reasonable maximum number of characters (80? 132? don't remember), and is terminated with some kind of EOL. My code reads them all and only processes the ones it's interested in.
Hope that gets you started.
I want to implement (for educational purposes) a program that checks the connectivity status of my laptop with certain wireless "entities". For example it will check my connection to a certain cell (mobile telephony) or a specific WLAN AP (e.g. the WLAN of my house).
Can I do that using only Java or should I use C/C++? The platform will be Vista / XP and in the future maybe Linux.
Is there anyone that can guide me to the correct APIs (if any)?
I would definitely recommend C/C++, however, if you are trying to write one code and run it in both linux and windows check out jNetPCap which is an implementation of PCap library for Java. tell me exactly how you want to check the connectivity? pinging? or you just want to know to what wireless network you are connected ? do you want to measure network delay?
I'm currently doing a project where I have to interact with a circuit I made through the parallel port of a computer. However, my computer doesn't have a parallel port so I borrowed a Parallel to USB adapter cable. The cable didn't come with any drivers, but it's recognized by the device manager as a "USB Printing Support" controller, under the USB section.
It seems that old parallel printers can be plugged in and work properly without any problems. So my question is, if I write a program in Java that tries to interact with a parallel port directly, will it work? And if not, can anyone give me some pointers as to what I need to do to interact with it?
Thanks.
I think you should head toward javax.comm library here.. there is also a different version that is supposed to work better, called librxtx.. take a look here (it's a pluggable replacement for javax.comm)..
I used both of them for an embedded device and they worked great, they manage serial and parallel port.. maybe also usb in your case.
I can't speak for parallel or Java but I've done something similar with serial-via-USB and C#. In that case it was exactly the same as a native controller. YMMV.
As for testing things: get an old dot-matrix printer (and put it in hex dump mode if you really want the nitty-gritty).
If you really want drivers for the thing, find a utility (I think the windows device manager can do it) that gives you the vendor ID and product ID numbers and from those you can look up all kinds of fun stuff (many Linux distributions have a plain text file that maps the numbers to the name of the manufacturer and what not) that plus Google should give you a driver installer.
You need java parallel port drivers which I haven't found for free. You'll have to pay for the driver for Windows.
I think there might be some free drivers if you use Linux.
USB "parallel port" adapters and cables generally aren't. They contain chips that emulate USB printers and send the print data out the parallel port like it might be sent to a similar printer using a parallel (printer) port.
Unless the device you have is actually a printer, there are probably very few (if any) adapters that will work.
There are ways of attaching GPIO "parallel"/bus pins into USB including certain FTDI chips, UARTs and various microcontrollers. If you can write software to use one of these, it could let you drive arbitrary circuits the way olde PC parallel ports were (not through the same MMIO, though).
I'm writing a program that has to mantain a large catalog of files. Those may be on different devices and I'd like to know what is the best way to do this in Java. I mean that I need to:
Identify the device the file (or just a directory) is on and get a name or identifier for this device that will be consistent...
Be able to use this device identifier to check if the device is plugged (like a USB pen, a HDD mounted or not, a network drive...)
Having this compatible with Windows, Unix and whatever...
The ideal solution would be some kind of device abstraction... In the docs I can see that File is related to partitions but it doesn't seem to be a proper abstraction or object of the filesystem. Or maybe if there is not a proper java abstraction, the best way to handle this diversity on each system.
Java 7 has the Path class which is an improvement over File. Check it out at http://download.java.net/jdk7/binaries/, or the tutorial at http://java.sun.com/docs/books/tutorial/essential/io/fileio.html.
If it is acceptable to (a) run only on Windows and (b) require admin rights to run your program, then this can be done with WMI via JACOB.
In particular take a look at the Win32_LogicalDisk class. This is sufficient to get the drive type (IDE, network, USB etc), the volume label and volume serial number (which may be enough to uniquely identify a removable volume for the purposes of your application.)
For more advanced functions (e.g. getting drive serial numbers) there are other classes, e.g. Win32_DiskDrive, Win32_DiskPartition, Win32_PhysicalMedia. However these will only work fully if running as admin.
A quick google turned up http://today.java.net/article/2006/07/05/java-and-usb which may be of help. At least it describes the state of USB support from a few years ago.
I would attempt to largely avoid the problem, by simplifying aspects of it. Namely I would would keep your catalog at the file/folder abstraction and then use the above article to generate code that listens for any USB activity.
Of course such an approach would require you to check a specific file/folder exists prior to the loading that portion of your catalog. Also you would require a thread to constantly listen for USB events and then perform the neccessary checks if any USB device has been connected/disconnected and perform the neccessary checks on the filesystem again.