From: Daniel R. <dr...@gm...> - 2011-01-06 20:23:41
|
Hi, Im working on adding Link Instruments MSO-19 support to sigrok, and im struggling on how to keep the code safe for multiple device instances. The MSO-19 uses a usb-serial bridge, and except for hardware identification, all the communication is done in the serial layer. The hardware identification (usb layer) is needed to get hardware type and revision, and to apply some "quirks" to the device calibration. The original windows software doesn't support multiple devices at all. And would fail usb<->serial mapping if the user had another usb device with the same kind of usb-serial bridge as the MSO-19. On Linux I can assert proper usb<->serial mapping using libudev, so, I can make it multiple-instance safe easily. I don't know how to keep proper usb<->serial mapping on other platforms. Should I add libudev as a dependency on linux builds? Should I drop libudev in favor of libusb and not support multiple devices at all? Thanks! -- Daniel Ribeiro |
From: Peter S. <pe...@st...> - 2011-01-06 21:03:39
|
Daniel Ribeiro wrote: > Im working on adding Link Instruments MSO-19 support to sigrok, and im > struggling on how to keep the code safe for multiple device instances. Good man. > The MSO-19 uses a usb-serial bridge, and except for hardware > identification, all the communication is done in the serial layer. That is incredibly stupid device design. > The hardware identification (usb layer) is needed to get hardware type > and revision, and to apply some "quirks" to the device calibration. > > The original windows software doesn't support multiple devices at all. > And would fail usb<->serial mapping if the user had another usb device > with the same kind of usb-serial bridge as the MSO-19. The only correct way to identify devices is using the serial number, as stored in a string descriptor referenced in the iSerial field in the device descriptor. > usb<->serial mapping using libudev .. > Should I add libudev as a dependency on linux builds? No. > Should I drop libudev in favor of libusb Yes. > and not support multiple devices at all? No. Use the serial number to distinguish devices. The device uses vendor specific interface so it is easy enough to program directly using libusb. I'm not sure that it really makes sense to use a kernel driver for this device. //Peter |
From: Daniel R. <dr...@gm...> - 2011-01-06 21:40:00
|
Em Qui, 2011-01-06 às 22:03 +0100, Peter Stuge escreveu: > > The MSO-19 uses a usb-serial bridge, and except for hardware > > identification, all the communication is done in the serial layer. > > That is incredibly stupid device design. Indeed, I think they did this to keep firmware compatibility, as they have/had products that use real serial ports. > The only correct way to identify devices is using the serial number, > as stored in a string descriptor referenced in the iSerial field in > the device descriptor. On USB identifying device instances is not an issue, even without iSerial: Bus/Device numbers are unique. > > and not support multiple devices at all? > > No. Use the serial number to distinguish devices. The device uses > vendor specific interface so it is easy enough to program directly > using libusb. I'm not sure that it really makes sense to use a kernel > driver for this device. You mean.. Replicating standard usb-serial, supported by kernel mode drivers on virtually all platforms with an userspace implementation? I don't think it is worth, it would be easier to support multiple instances on linux(with libudev), and just a single instance on other platforms(with libusb). libudev can be a linux-only dependency, and the code would definitely be smaller than a full usb-serial userspace implementation. -- Daniel Ribeiro |
From: Peter S. <pe...@st...> - 2011-01-06 21:55:04
|
Daniel Ribeiro wrote: > > The only correct way to identify devices is using the serial number, > > as stored in a string descriptor referenced in the iSerial field in > > the device descriptor. > > On USB identifying device instances is not an issue, even without > iSerial: Bus/Device numbers are unique. The serial number is the correct way to distinguish two identical USB devices per spec. Everything else is a workaround for broken devices. > Replicating standard usb-serial, supported by kernel mode drivers > on virtually all platforms with an userspace implementation? Right. As you may know there is no real hard spec for USB-serial and drivers are often device-specific, and since just using libusb would be simpler there could be a point to avoiding kernel drivers that expose this device as a serial port. > the code would definitely be smaller than a full usb-serial > userspace implementation. A bulk transfer with libusb is literally one line of code. Messing with the kernel driver model is not pretty, absolutely not cross platform and certainly not as easy as just using libusb. //Peter |
From: Daniel R. <dr...@gm...> - 2011-01-07 00:47:17
|
Em Qui, 2011-01-06 às 22:54 +0100, Peter Stuge escreveu: > > On USB identifying device instances is not an issue, even without > > iSerial: Bus/Device numbers are unique. > > The serial number is the correct way to distinguish two identical USB > devices per spec. Everything else is a workaround for broken devices. Sure, but the point here is to distinguish two _connected_ USB devices, i don't really need to distinguish two _physical_ devices. > > Replicating standard usb-serial, supported by kernel mode drivers > > on virtually all platforms with an userspace implementation? > > Right. As you may know there is no real hard spec for USB-serial and > drivers are often device-specific, and since just using libusb would > be simpler there could be a point to avoiding kernel drivers that > expose this device as a serial port. > A bulk transfer with libusb is literally one line of code. Messing > with the kernel driver model is not pretty, absolutely not cross > platform and certainly not as easy as just using libusb. I can see the portability benefit of using a libusb-only approach, but it would also make it a lot harder to reuse the plugin/driver code for real-serial connected devices using the same serial protocol. Anyway, I will not implement userspace libusb logic for cm210x's usbserial hardware specifics, its not that small and easy... Its already implemented on kernelspace for most platforms and rewriting it for libusb seems a waste of resources. If you know an open source project that has such 'cm210x libusb' implementation that i can easily copynpaste, please tell me! ;) -- Daniel Ribeiro |
From: Peter S. <pe...@st...> - 2011-01-07 01:31:22
|
Daniel Ribeiro wrote: > > > On USB identifying device instances is not an issue, even without > > > iSerial: Bus/Device numbers are unique. > > > > The serial number is the correct way to distinguish two identical USB > > devices per spec. Everything else is a workaround for broken devices. > > Sure, but the point here is to distinguish two _connected_ USB devices, > i don't really need to distinguish two _physical_ devices. The serial number is what tells which is which. I would use it. > I can see the portability benefit of using a libusb-only approach, but > it would also make it a lot harder to reuse the plugin/driver code for > real-serial connected devices using the same serial protocol. Maybe there could be an extra function that takes care of actual IO, so that it doesn't matter if the serial protocol goes over actual serial or bulk transfers. > Anyway, I will not implement userspace libusb logic for cm210x's > usbserial hardware specifics, its not that small and easy... It is quite easy, but that is your choice. > Its already implemented on kernelspace for most platforms and > rewriting it for libusb seems a waste of resources. The point is again that it makes for nice plug and play on all systems but Windows. As we discussed on IRC, the SiLabs serial port driver is used on Windows, and in order to go from there to libusb the kernel driver would need to be replaced. This can be done automatically using http://libusb.org/wiki/libwdi but then the driver would need to be switched back again to use the original application. That doesn't make much sense, another solution would be much better. > If you know an open source project that has such 'cm210x libusb' > implementation that i can easily copynpaste, please tell me! ;) Would use bulk transfers to send data. One function call. May need to look a little at the kernel driver, or the device datasheet, to craft the control transfer that sets correct port mode and speed. //Peter |