💡 [FEATURE] Support for CP2104 serial devices

[gritd]

The changelog states the mt32pi can handle CP1202 serial devices but I have a board which uses the CP1204 which is not recognised, is that correct? Does this serial chip variation gets ignored or is this a matter of initalization time increase?

[dwhinham]

No idea, no-one's tried a CP1204 until now.

Please run a debug build and provide logs showing the result of plugging in this device.

If we're lucky we might just need to add a VID/PID.

[gritd]

should be compatible but I can try and make a debug mt32pi, meanwhile, the VID/PID is: PID: 0xEA60 / VID:0x10C4

[ajhuitsing]

Hi,

Here's a patch which enables support for CP2104 USB serial chip, as suggested by @gritd

The Circle library already supports CP2102 USB serial chip, but restricts it to CP2102 by detecting the chip variant during initialization. This is too restrictive: the CP2104 is compatible (has even the same VID/PID) So this patch simply removes the explicit CP2102 variant check, and then it works like a charm :-)

circle-support-cp2104.patch.zip

@dwhinham: thanx for making this inspiring project!

[gritd]

confirmed! - CP2104 is detected and works super, thanks - hope this can make it into the next rev.

[dwhinham]

Thank you both for the patch and for testing.

I can certainly include this patch for the next release, but really we should be aiming to upstream a fix into Circle so that other projects can benefit too.

cc'ing @rsta2, @hinxx:
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.

Would it make sense to rename the driver to "CP210x" and lift the part number check?
Unfortunately I don't have any of these devices myself to test but maybe we should track this issue upstream and gather more feedback?

Thanks!

[rsta2]

@dwhinham Good idea and thank you for giving an info to us! Unfortunately this cannot be included in the next Circle release any more, which was already scheduled for today, but I think we can deal with this soon after the release. I will come back on it.

[dwhinham]

Thanks Rene, and no problem with missing the window for the new Circle release as we have a workaround for the time being and it's easy enough for me to maintain patches.

I've applied a patch to deal with this in mt32-pi for now in 772fb15, so I think we can close this here and follow on with this issue over at rsta2/circle#329.

Cheers!