On 11/11/13 23:38, Martin Ling wrote: > For serial devices, we're now integrating libserialport > (http://github.com/martinling/libserialport) which replaces all the > OS-specific serial code in libsigrok, and also provides us the ability > to scan for available serial ports in an OS-independent way. Currently > you just get the port names, but the next version should also offer > details such as USB VID/PID for each detected port. > > For devices that can be uniquely identified from this information that's > great, because those drivers can then find their devices with no user > intervention. > > For those that can't though, it's less clear what we should do. In a GUI > frontend, we want to be able to take advantage of the ability to scan > for serial ports and then offer the user a list of candidates to choose > from for a given driver, rather than having to type one in. But what > call should be made to get that list?
Clearly this will need a new API call, both publicly and in the internal driver API. The driver just asks libserialport, supplying any info it has on what kind of serial port it wants: the driver might know for sure the port is behind a specific VID/PID, for example. The driver also needs to return to the frontend some measure of confidence about each port it returns to the frontend. I see a need for only two indications: the port _might_ be connected to the driver's supported device (e.g. uses a specific VID/PID that is nevertheless not unique -- generic FTDI, say). The second indication is if the driver concludes that this absolutely _is_ a supported device, for example by a unique VID/PID behind it, or other matching USB descriptors. If the driver returns only one serial port to the frontend, and it's marked as being absolutely the right port, the frontend can then call scan() on it. > It would also be nice to avoid the situation where the scan for ports is > done over and over again by each driver. The current approach provides > no straightforward way for them to share this information. > > It seems like it would be good to have some sort of shared "pre-scan" > for usable hardware (serial ports, USB devices, and whatever else). > Each driver could then look through the results to identify the ones > that it might be able to use. This would be more efficient and would > allow us to present better UI to the user. I'm not so sure this is really needed -- a scan for ports is not an expensive operation. In the case of permanently connected ports, libserialport already knows OS-specific ways to quickly enumerate and strip out virtual ttys and such. libserialport might even cache this list to save even this effort -- it's static once eumerated, after all. USB-connected ports don't actually take any effort to scan: the OS already has a list of connected devices in memory, so a scan doesn't cause hardware delays or anything. If you have all the drivers do this in turn, it might even get in some L2 cache hits :-) -- Bert Vermeulen [email protected] ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
