Consider using non-generic USB VID/PID
Closed this issue · 3 comments
As a lurker, I haven't had the chance to look into this, but sigrokproject/libsigrok#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.
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.