rfoxkendo
commented
1 month ago I'll note that somewhen about 12.0 I tried to do a direct port to libusb2 - I did this in a way that tried to hide the differences between 2 and 0.1 via a layer that did thhe USB stuff (see usb/{usb0.1,usb1} This seemed to work just find but the KSU folks claimed their v1x90's did not initiallize properly. I did some tracing to see if there were different USB Packets being sent to the controlle rbetween 11.3 and 12.0 and did not see anythnig ... played with timing (that's the devicde with a microcontroller that's a pain to program with VMUSB). Finally had to back out all my work so going to libusb2 - is treading where I feared to tread but worth it...maybe another approach taking advantage of asynch completion to improve performance is worth it.
There was one other issue I recall and that's that the CCUSB is not really legal in where it returns its' serial string. but I think that the code to deal witht hat may still be presenet.
The problem is the use of string index 0 for that which is supposed to indicate no such string...libusb2 will produce an error if you attempt to fetch that string but libusb0.1 calmly ignores the illegal use of string#0.and returns the serial string.
Another possible fix is also filed as an issue. At some point, libusb-0.1 became libusb2 which got: A totally different API A wrapper that emulated 0.1 in terms that new API.
It’s not clear to me if the problems are in the wrapper (I think so) or the new API. The new API supports asynchronous completion of USB transfer requests and request cancellation (which the old one does not). There are advantages to using it because the main CAcquisition thread loop could then be written without the clunky swapping between a timed out usb_bulk_read and checking for stuff to do elsewhere. Specifically I think the loop could become an async read with completion routine shipping the received data on to the sender thread while the acquisition thread hung on its command queue. So the other issue contemplates rewriting the CVMUSB/CCUSB classes in terms of the libusb2 API in some funky way that exposes the asynchronous ability. This makes my decision not to expose the libusb interface outside of those classes look like a pretty good one 😊; as the changes would be quite confined and maybe not that extensive.