Closed hadess closed 2 years ago
hadess, thanks for the comment. Not sure where you saw that implication, but actually the user has to specify which COM/serial port the driver should use. That is done either in the command line such as: ./pulseview -d raspberrypi-pico:conn=/dev/ttyACM0:serialcomm=115200/flow=0 -l 2 or in the gui when you "connect to a device" you do have to specify the desired device, then select USB or COM, and then select the COM port to try.
Note that for devices that are a non-CDC device, I think that pulseview will scan through the vids/pids of hardware that it supports looking for a match, but I've never tried it because I've never used one.
Not sure where you saw that implication, but actually the user has to specify which COM/serial port the driver should use.
I looked at the driver code trying to figure out its initial handshake.
Note that for devices that are a non-CDC device, I think that pulseview will scan through the vids/pids of hardware that it supports looking for a match, but I've never tried it because I've never used one.
This was the end goal, truly plug'n'play configuration.
Closing this out. While the notion of a VID/PID sounds cool, it still requires the user to use Zadig (at least on windows) or some other mechanism which seems to be just as much work as mapping a com port. And the CDC implementation is pretty close to max rate. And, ok, I'm just plain lazy and trying to implement a USB stack still scares me even though there are plenty of examples on how to do it.
As a lurker, I haven't had the chance to look into this, but https://github.com/sigrokproject/libsigrok/pull/181 seems to imply that the driver would try and bind to any serial port and poke at it to see if it supports the protocol.
You can use https://pid.codes/ or http://wiki.openmoko.org/wiki/USB_Product_IDs to request a unique VID/PID for your project, which should take some of the guess work out of identifying devices.