Expanded support for CP210x family USB serial devices

Question

Expanded support for CP210x family USB serial devices

dwhinham opened this issue 2 years ago · comments

This issue was reported by a user with a CP2104 device (following on from dwhinham/mt32-pi#305).

Removing a part number check in the CP2102 driver (relevant code) apparently gets it working for CP2104, and possibly other members of the CP210x family as they appear to be very similar.

This PDF (page 2) suggests that the differences are very minor (e.g. number of stop bits supported).

Searching for partnum within the Linux driver also reveals where behaviour varies depending on the part number.

It would probably make sense to:

Rename the driver to CP210x.
EITHER: Remove the part number check and deal with any further issues as reported by users of the hardware (easiest solution).
OR: Expand the part number check to other known part numbers and adapt the behaviour of the driver to enforce the correct maximum baud rates, stop bits etc in a similar way to the Linux driver to account for the minor differences in the CP210x family (requires more effort/testing with the hardware).

I would offer to help, but sadly I don't possess any of the devices concerned, hence I'm only able to ensure the issue is tracked.

Many thanks as always!

Rene Stange · Answer 1 · Fri Dec 02 2022 17:19:06 GMT+0800 (China Standard Time)

@dwhinham Thank you for the comprehensive information as always! I will try to implement the second option. I'll need a few days.

Rene Stange · Answer 2 · Sat Dec 03 2022 02:34:15 GMT+0800 (China Standard Time)

There is a modified CP210x driver on the develop branch. This went quicker than expected. I tested it with a CP2102. Please let me know, if more modifications are necessary. I'm not sure, if we should add more vendor/device ID combinations. The Linux driver has a lot of them. I wouldn't include them all, but perhaps the missing SiLabs factory defaults should be added (0xEA61, 0xEA70).

Dale Whinham · Answer 3 · Sat Dec 03 2022 04:58:10 GMT+0800 (China Standard Time)

Perfect solution, thanks Rene. I personally can't think of any further changes necessary, and the way you have implemented this makes it very easy to extend later on if need be.

Cheers!

Rene Stange · Answer 4 · Sat Dec 03 2022 18:31:16 GMT+0800 (China Standard Time)

OK, thanks. Then we should wait, if somebody wants another modification in the coming time. Cheers!

Rene Stange · Answer 5 · Mon May 22 2023 18:56:37 GMT+0800 (China Standard Time)

This feature is in Circle 45.2 now.