locked
USB Ports and Devices!

    Question

  • How do I detect and access the USB ports on my computer and devices attached to them (if connected) with Visual Studio 2008 using Visual Basic code. Please, no C or other languages only VB!

    Michael J. Williams


    Sunday, July 22, 2012 10:45 PM

Answers

  • You don't connect to a USB port unless you are writing a low-level driver. You connect to the device that is attached to the USB port, and how you do that depends on the device.

    If it's a mass storage device then you access it like a disk drive. If it's a virtual serial port then you use the serial port component. If it's a special device then it will be supplied with a driver and possibly an API that you connect to using the speciic protocols of that interface.

    Sunday, July 22, 2012 10:56 PM

All replies

  • You don't connect to a USB port unless you are writing a low-level driver. You connect to the device that is attached to the USB port, and how you do that depends on the device.

    If it's a mass storage device then you access it like a disk drive. If it's a virtual serial port then you use the serial port component. If it's a special device then it will be supplied with a driver and possibly an API that you connect to using the speciic protocols of that interface.

    Sunday, July 22, 2012 10:56 PM
  • You may also be able to use WMI to interrogate or interface with the device.  But as Acamar said, it really depends on the type of device.

    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Monday, July 23, 2012 7:27 PM
    Moderator
  • For "purchased" mass storage devices using USB ports VB gives what you need. I have Hacked out the code that will do this.

    What I want to do now is design my own Instrumentation circuitry, such as an  external Analog to Digital (A/D) Converter, external Digital to Analog (D/A) Converter, my own Oscilloscope, Spectrum Anylyzer, Network Anylyzer, Heart-Beat monitor, whatever, and access it via the USB Host Controller.

    At this stage of my knowledge I figure that I have to gain access to the host controller onboard my laptop first before I can gain access to anything that is subsequently connected to the USB port. Then I can gain access to the Instrumentation that I connect to the USB port.

    Am I too far off the mark here?


    Michael J. Williams

    Monday, July 23, 2012 9:13 PM
  • How true that Quote is!

    After having written nine programs now, over the past two years, for image processing and viewing and storage and retrival from a data disc and without any possibillity of the user doing something that would cause the programs to crash, and all the logic behind the Window User Interface, that makes it easy for the user, that quote is exactly true! The user has no idea of the complexity that is behind a windows form that makes the program look so simple and so easy to use! 


    Michael J. Williams



    Monday, July 23, 2012 9:17 PM
  • That should not be required.   The USB interface device that you choose for your instrumentation equipment will be provided with a driver and API for Windows that gives you access to the device at the required level.  It looks after all the detail of the USB interface, and you only need to add the actual communications protocol, which is the programming of the microcontroller on the device, and the VB code for responding to that proptocol on the PC.

    The simplest way to start is with a generic USB device that can be interfaced to any piece of instrumentation.  See here for an example:
    http://www.velleman.eu/products/view/?country=be&lang=en&id=351346

    Depending on the amount of engineerring you want to do, you can go with that type of kit interfaced to the instruments, or you can build an inegrated unit.  But the integrated unit will use a standard USB interface chip that already has the required driver and API created for it.

    Monday, July 23, 2012 9:38 PM
  • Hi Michael,

    Here is the way I would approach this:

    USB is the universal serial bus which defines a protocol that allows a large number of devices to communicate over a common serial interface.  Accessing this bus and using its resources is something that is done at the driver level in windows.  We know that whenever a new USB device is inserted into the PC, the first thing Windows tries to do is install a driver for the device.

    While the bus itself is capable of high data rates, many devices do not truly require the full capacity of the bus, and in these cases a legacy serial port (COM Port) will work just fine.  All of the devices you listed would almost certainly be designed to communicate using RS232 serial, so a virtual USB-COM port would be the connectivity solution on the PC side.  Even if you were building your own device, you would almost certainly want to take some TTL logic level output and raise it up to RS232 or integrate your own USB-COM controller (there are a number of chips compatible with the default windows virtual com port driver).  This is an inexpensive, proven, reliable solution and hence it is still quite popular.

    If your device really did need the entire service capacity of the USB bus, then you would be faced with writting a device driver in C++ and then your managed VB application could use interop to call the C++ methods of your driver api.

    So I would say that the SerialPort control in .Net connected to a virtual COM port representing your device is probably going to be the best solution.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Monday, July 23, 2012 10:26 PM
    Moderator
  • Why would the code have to be C++ and not Visual Studio 2008 Visual Basic?

    I have already found that VB provides the ability to detect USB-COM ports, and that only one of the USB ports out the four that are on my laptop have the COM capabillity!

    Is this only an USB-RS232 port or will it work with the other standards as well, GBIP-488, RS-485, and the others?

    And are there newer Standards, as it seems that these have been around for quite some time?

    I found the following code in the VB documentation that comes with VS2008Pro but not much more then this.

    Public Class Form1 Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load End Sub Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click GetSerialPortNames() End Sub Sub GetSerialPortNames() For Each sp As String In My.Computer.Ports.SerialPortNames ListBox1.Items.Add(sp) Next End Sub Private Sub ListBox1_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ListBox1.SelectedIndexChanged End Sub End Class



    Michael J. Williams



    Tuesday, July 24, 2012 3:20 AM
  • Do you know if USB-3 Chips available yet? I may want the real time bandwidth!

    Michael J. Williams


    On 2nd thought, if the host controller on my computer is not a USB3 compatible, and I doubt that it is as it is several years old now, then it makes no sense to use an external USB3 device!
    Tuesday, July 24, 2012 3:42 AM
  • I went to the website above and the product they have is the basis of what I want to do myself....

    I find that TI has a USB product line and the Chips they have will be just what I want!

    Design from scratch and go from there!

    Thanks, MJW


    Michael J. Williams

    Tuesday, July 24, 2012 4:17 AM
  • Why would the code have to be C++ and not Visual Studio 2008 Visual Basic?

    Because a device driver needs to connect to the lowest levels of the operating system functionality, and managed code can't do that. 

    It is possible to use some generic USB components with managed code, however, so the real low-level stuff is already done for you.  Whether or not that is an effective way to write your device drivers depends on the application.  But it's still a lot of hard work.

    I have already found that VB provides the ability to detect USB-COM ports, and that only one of the USB ports out the four that are on my laptop have the COM capabillity!

    VB is not detecting USB COM ports - it is detecting COM ports.  It's the magic of the device driver for the USB virtual serial port device that allows VB to detect those ports as if they were standard hardware serial ports.  That sort of magic requires language with the power of C++ to achieve.

    Is this only an USB-RS232 port or will it work with the other standards as well, GBIP-488, RS-485, and the others?

    The serial port component in VB understands only serial ports.   There are USB devices that can provide virtual ports for those other interfaces in the same way that they the USB virtual serial port device works.  An application that understands how to deal with that interface will work with the virtual port.  Or, there are USB devices that connect to those interfaces and provide their own application interface - that allows older instrumentation to look like a USB device as far as the application is concerned.   The kit I referred to above is sometimes used for that.

    And are there newer Standards, as it seems that these have been around for quite some time?

    That would be USB.

    Tuesday, July 24, 2012 4:21 AM
  • Do you know if USB-3 Chips available yet? I may want the real time bandwidth!

    See, for instance:
    http://www.eetimes.com/electronics-news/4200919/TI-offers-USB-3-0-IC-for-5-Gbit-s-transfers

    The industry has likely moved on since then.

    Tuesday, July 24, 2012 4:26 AM
  • Just to expand on the last two questions...

    RS232, RS485, etc are all Line-Level Serial protocols.  These protocols take transistor-transistor-logic (which is typically a simple on/off signal at low voltage) and ramp it up to a signal that can be passed off of the local circuit board and across some length of wire.  Each protocol may define a voltage range, synchronization, and flow/error control scheme - all of which can become important when moving data across a wire at high speed.  On the PC, 12 volt asynchornous serial with flow and error control is implemented through the RS232 interface.  Other Line-Level serial protocols require a hardware converter between the device and the PC.  There are a number of different line-level converters available in hardware depending on the source to convert to RS232.  There are some PCI cards that offer native RS485 ports, but these are out of favor and tend to be much more expensive than an external RS232 converter.

    USB is not really a serial communications standard.  It is a serial bus standard.  The protocol defines the way in which multiple devices will share the bus but it doesnt specify what the data on the bus means.  There will be higher level protocols for the specific device using the USB bus.  For your USB mouse and keyboard, this protocol is typically HID. For your serial port dongle, it is RS232.  The device driver takes care of implementing the high-level protocol which makes meaningful the data transfered between the device and the computer, once it is installed for the device on a given USB port.

    USB is the paved highway which simply says where traffic might go; RS232/HID/Etc. are the painted lines and posted signs which determine the actual flow of traffic on that highway.  USB ports are the on and off ramps to this highway.  When you install a new USB device and Windows installs a driver for it, the purpose of that lane of the highway is then defined.  A "car-pool" lane is just another lane of pavement available for any traffic until someone paints the words "car pool only" on the road or hangs a sign above the lane.  Installing the driver for a USB device is like painting the road and hanging the sign. 

    Does that make sense?


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Tuesday, July 24, 2012 5:28 PM
    Moderator
  • USB 3.0 still is nacent.  You may want to take a look at a book like USB Complete 4th Edition (see www.lvr.com).  Doing real-time data acquistion at the data rates supported by USB 3.0 is a non-trivial proposition.  You certainly cannot do the job using only .NET.  Most of the work has to be done in the associated Windows device driver.  Commercial products of this sort might require >> $100K to develop.

    Dick


    Dick Grier. Author of Visual Basic Programmer's Guide to Serial Communications 4. See www.hardandsoftware.net.

    Thursday, July 26, 2012 5:25 PM
  • The way that makes the most sense to me is to categorize the Bus technologies as

    1)Data Line drivers/recievers(RS-232, and many others, some new some old)

    2)Data Links(UART, SONET, USB, and several others, some new some old)

    3)Data Signal Conditioners and Translators(most often associated with Data-line drivers and recievers or Data Links)


    Michael J. Williams


    • Edited by Miketug2003 Friday, July 27, 2012 5:35 PM Clarity of technologies involved
    Friday, July 27, 2012 5:32 PM
  • I have time on my hands... it will not cost me anywhere near $100K!!!

    Michael J. Williams

    Friday, July 27, 2012 5:38 PM