Implement support for Prolific virtual COM port over WebUSB

[liu-minjie]

device info:

the device works well with navigator.serial in crhome 89.
but it will not work with the polyfill code in lower version chrome. it will throw the errror: "Unable to find interface with class 2"

[A-J-Bauer]

Had the same problem with a CH340 on an arduino connecting from Android.

You could try:

const deviceFilter = { usbVendorId: 6790, usbProductId: 29987 }; // 1659, 8963 for prolific
const interfaces = { usbControlInterfaceClass: 255, usbTransferInterfaceClass: 255 };

if ("usb" in navigator) {
    try {                   
        device = await serial.requestPort({ filters: [deviceFilter] }, interfaces);
    } catch (e) {
        if (device.opened) {
            await device.close();                
         }
    }
}

[liu-minjie]

Had the same problem with a CH340 on an arduino connecting from Android.

You could try:

const deviceFilter = { usbVendorId: 6790, usbProductId: 29987 }; // 1659, 8963 for prolific
const interfaces = { usbControlInterfaceClass: 255, usbTransferInterfaceClass: 255 };

if ("usb" in navigator) {
    try {                   
        device = await serial.requestPort({ filters: [deviceFilter] }, interfaces);
    } catch (e) {
        if (device.opened) {
            await device.close();                
         }
    }
}

now another issuse:
A is with pollyfill code
B is with chrome native serial

when A send data to B. it's ok, B will receive data correctly
but B send data to A, A will not receive any data.
after close port of A, the code reader.read().then((data) => {}) will receive {done: true, value: undefined }

[reillyeon]

This library only currently understands how to control a USB serial device that uses the standard USB CDC-ACM protocol, which is why it is looking for an interface with class 2. From my research many USB serial devices that use other non-standard protocols are still similar enough to this protocol that the library should work with only minor modifications.

We will use this issue to track implementing support for such chips from Prolific Technologies.

[A-J-Bauer]

For my purposes I simply changed the SerialPort constructor code to look for interface types instead of interface class numbers:

this.controlInterface_ = this.device_.configuration.interfaces.find(x => x.alternates.find(y => y.endpoints.find(z => z.type === 'interrupt'))); // findInterface(this.device_, this.polyfillOptions_.usbControlInterfaceClass);
this.transferInterface_ = this.device_.configuration.interfaces.find(x => x.alternates.find(y => y.endpoints.find(z => z.type === 'bulk'))); // findInterface(this.device_, this.polyfillOptions_.usbTransferInterfaceClass);

Now it works the same as navigator.serial on desktop (serial.js and demo here: https://github.com/A-J-Bauer/asa)

[reillyeon]

That's interesting. It looks like Prolific chips use protocol that is similar enough to the standard USB CDC-ACM protocol that it works for the subset of functionality currently used by this library.

In particular it uses control transfers that appear identical to the standard SET_LINE_CODING and SET_CONTROL_LINE_STATE commands.

[A-J-Bauer]

I think it does, the device Info posted by liu-minjie looks similar (endpoints not unfolded) to that returned for the WCH CH340 chip (http://www.wch-ic.com/products/CH340.html) that is used for Arduino Nano clones and those are working with the modification mentioned above.