0

I've been very new to driver development and recently read about communicating with USB peripherals using LibUsbDotNet.

Currently I'm developing a small library for interacting with the OBD interface built into vehicles. The serial connection works great but since I've seen many USB connectors I wanted to let people use their USB connectors with this library.

The introduction page of LibUsbDotNet says:

Before LibUsbDotNet can access a usb device on a Windows operating system the device must be installed with either WinUSB or libusb-win32 usb drivers. Optionally, libusb-win32 has the unique ability to operate as a filter service. When the filter service mode is enabled, libusb-win32 will allow access to every usb device on the system without the need for driver setup/installation packages.

Does that mean that I'll need to create own driver packages for every single USB to OBD connector and deploy it with the library? Is there really the need for a driver? I only want to read from the USB port and transfer data to it. So that the interface on the other end may receive my messages and respond to me - just as the COM port.

Euro Micelli
  • 33,285
  • 8
  • 51
  • 70
0x8BADF00D
  • 962
  • 1
  • 8
  • 18
  • 1
    Well, libusb isn't used for USB-serial converters. Those have virtual COMM port drivers, either vendor-provided or Microsoft's `usbcdc.sys` which loads for devices that conform to the USB standard Communication Device Class. – Ben Voigt Aug 31 '14 at 23:10
  • How'd I access this vendor provided driver? Is there a generic solution or does that depend on the vendor? – 0x8BADF00D Sep 01 '14 at 12:15
  • For USB-serial converters, you open the COM port by name or number. (The Microsoft-provided `System.IO.Ports.SerialPort` class only supports numbers, and has a number of other more serious problems, so I suggest you use the Win32 API for serial ports, either through p/invoke or a better wrapper library) – Ben Voigt Sep 01 '14 at 12:57
  • Now, it's not just a matter of talking to the device, but understanding the protocol it speaks. I don't know whether OBD bridges have a standardized format the way, for example, GPS devices have NMEA. – Ben Voigt Sep 01 '14 at 12:58
  • Oh, that's not a problem at all. Communicating with a serial to usb adapter works fine (it is listed as actual COM port) but when communicating with a end to end usb cable (with no serial converter at all, just the obd connector at one side and the usb connector at the other side) I can't use the serial port class since in this case, nothing is mapped as COM port. – 0x8BADF00D Sep 01 '14 at 15:14
  • Not all USB-serial converters have a DB9 serial connector, some are integrated into the device (many many GPS units work this way). But if you don't see a COM port after connection, even with the right drivers installed, then you're probably working with something other than USB-serial. Once you go beyond the usual device classes (Communication Device class, Mass Storage class, etc) then it becomes increasingly likely to need special support for each individual device model. – Ben Voigt Sep 01 '14 at 15:47
  • The point of libusb is to provide a single driver for all USB devices, at the common level of abstraction (basically, USB descriptors and end-points). You still need an install package with each individual VID&PID combination listed, however, in order to be able to use libusb. And you need model-specific detail about the exact message format the device expects on its endpoints. – Ben Voigt Sep 01 '14 at 15:49

0 Answers0