21 Apr 2015 10:17:53 -0300 Wander Lairson Costa <wander.lairson@g...>:
> I am not very versed into pyserial and ftdi stuff. One question comes > to my mind is: what's the advantage of moving stuff from pyserial to > pyusb? I might have needed to give a broader view first. I did not intend to move anything from /pyserial/ to pyusb. Those two have a sort of equal, independent relationship. The use of pyserial is for any Python code that wants to use a serial comm port. The code should be able to pass some provided string to serial.serial_for_url() and get a Serial instance back, and use it. Whether the actual port is a UART on the motherboard, or some tunneled- over-IP thing, or a USB-to-serial chip with a driver in the kernel, or a USB-to-serial chip with a driver built with pyusb. So pyserial is a common API for serial ports whether they are USB or not. Respectively, pyusb is a common API for USB devices whether they are serial ports or not. :) The only interdependency is that if somebody uses pyusb to write a driver for a USB-to-serial chip, it ought to be written to supply a class that derives from serial.Serial. And somehow, that driver needs to get called when somebody passes a certain form of string to serial.serial_for_url(). Those two pieces of glue right now are in the package pyftdi.serialext. But FTDI is only one brand of (perhaps not fully standard-class-compliant) USB-to-serial chip, and package pyftdi is really a hardware-specific driver for that chip ... all except for the subpackage pyftdi.serialext which is /not/ specific to that chip. It's just the same glue code that any pyusb-based USB-to-serial driver would have to duplicate in some form. It's just that Emmanuel wrote it first, and put it in pyftdi. :) It defines the useful base class UsbSerial that is both an instance of serial.Serial and proxies a pyusb device. It also contains the code to act as a protocol-scheme hook into serial.serial_for_url and recognize strings that should be USB devices. These are the pieces of code that I think could be hoisted up from pyftdi and would reasonably be in pyusb for general use by pyftdi and any other similar drivers for USB-to-serial chips from MCT or Prolific or Cypress or whomever. > I have an idea of providing an usb.classes package, which would ship > modules for each USB standard class. I like that idea. And if that existed, the package for class 02 would reasonably be the right place for this common code. I'm sure you've noticed how usb.org defines standard class protocols and there are some devices that actually work that way, but others rush to market and provide similar functionality but not with the standard- defined protocol. For example (the first one I crashed into), the Audio class defines a USB MIDI protocol, but manufacturers like Midiman make USB-MIDI devices that work with their own strange protocol. Having a driver for the standard class protocol is great because it will work with any device that complies, but as soon as you attach one of the strange devices you need its own strange driver code. The same situation seems to exist for serial. There is a communications class spec that defines a standard protocol, and if there were a pyusb driver for that protocol, it would work with any compliant device (for example, Cypress). I think it would be good if such a driver could be developed, and even distributed as part of pyusb in the usb.classes package. That would not end the need for strange nonstandard protocol drivers like pyftdi, as long as strange chips like FTDI are being sold. I can imagine a possible rule that only drivers for strict USB class specified protocols might be part of pyusb in usb.classes, and drivers for non-class-compliant hardware would remain in separate packages like pyftdi. But it would make sense that usb.classes.communication (or whatever it should be named) contains the common glue such as the proxy class derived from Serial and the hook to intercept serial_for_url. The ideal would be that if somebody had Python code that wanted a serial port, they could pass argv[1] to serial_for_url() and get a usable Serial instance back, whether the argument was /dev/ttyS0 or /dev/ttyUSB3 (in-kernel driver) or something like usb://0x0683,0x1550/?drv=ftdi or usb://0x04b4,0x0003/ (which would be a Cypress chip and Just Work with the class standard driver because Cypress implements the standard).... Does that clarify the structure I had in mind? -Chap ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ pyusb-users mailing list pyusb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pyusb-users
