Resolve Mac OS setting Prolific Technology adapter#194
Resolve Mac OS setting Prolific Technology adapter#194skmagiik wants to merge 2 commits intoserialport:mainfrom
Conversation
This resolves an issue where the baudrate would not be
recognized on Mac OS. The adapter details for the faulty adapter are
below:
Device Descriptor
Descriptor Version Number: 0x0200
Device Class: 0 (Composite)
Device Subclass: 0
Device Protocol: 0
Device MaxPacketSize: 64
Device VendorID/ProductID: 0x067B/0x2303 (unknown vendor)
Device Version Number: 0x0300
Number of Configurations: 1
Manufacturer String: 1 "Prolific Technology Inc."
Product String: 2 "USB-Serial Controller"
Serial Number String: 0 (none)
|
I think this issue is very important... |
…ort-rs and mio-serial. The problem comes with their baudrate fd mechanism is different compare to all others in macOS. Related issue : serialport/serialport-rs#194
|
Thank you for this PR @skmagiik! I finally managed to get some PL2303 devices and give the proposed changes a spin (on top of the current master (with 7ee2b5a/sirhcel/pr-194-prolific-baud). For me, just running the tests with a pair of FT232H Mini module and a PL2303 cable fails at several points: My default test setup uses SiLabs CP2102N dongles and the changes makes some tests with a pair of them failing as well: I will have a more in-depth look into this the next days. But at a first glance this looks like - besides the timing issue with the PL2303 - the changes are breaking baud rate setting via Could you please give the tests a spin in your setup @skmagiik or @pmnxis? |
|
Looking deeper into my results from #194 (comment) with an oscilloscope, I was surprised that I did see data output from the PL2303 cable (with a blue connector housing) only in rare cases. For example, running the example I did testing with macOS 10.15.3 on a M1 machine using the driver shipped with the OS. I learned that there is also a driver from Prolific distributed via the Mac AppStore and with this one, things look better: Some test cases are still failing (with timeouts) but baud rate setting and transmitting at the set speed (with sirhcel@51df58f) seems possible. Which version of macOS, which CPU architecture and witch device driver are you using @skmagiik and @pmnxis? |
|
@sirhcel Hello Thanks for looking on this issue , it would be very helpful. I am working on egui based serial-terminal on macOS/Linux/Windows. Some interesting thing is that the some of PL2303 is a counterfeited chip from China, and it's not clear how it will behave on a macOS depending on whether it's a counterfeited or legit. I'll try to get a good PL2303 and a cloned PL2303 and compare the differences. And may need check if all of prolific's products have different termios access. The code I forcibly modified with unsafe is a hotfix method used by prolific in macOS environments, but I'm not sure if it's a good method because I only tested it on PL2303HX. |
I have not booted up Windows yet, but running my test from above on Linux worked just fine.
I read about it. And was wondering what I have bought because of the strange behavior with the driver shipped with Sequoia. Sourcing PL2303 devices feels a bit challenging as my usual "purveyors of the court" do not list them. So i ended up buying some cables at Amazon. Let alone soucing individual ICs. Do you have a trusty source for PL2303 ICs or devices? How do you tell genuine and fake devices apart? Looking at the screenshots in #194 (comment): Where do you get this information about the assocated device driver from? |
It's decisivetactics's commercial software, Serial 2. |
Thank you for these pointers @pmnxis! I will try to get my hands on a Waveshare device. Do you have devices from FTDI and/or SiLabs at hand for comparing test results with the changes proposed here? |
|
@sirhcel Yes I can test them SiLabs(CP****) and FTDI(FT232). 2025-02-15 : FT232 updated |
|
@sirhcel updated the list #194 (comment) Most of devices working with |
|
Thank you for checking out and your update on #194 (comment) @pmnxis. The result is unfortunate as this would require a decision on whether to break the support for CP2102N or leave the one for PL2303 broken. And in this case I would opt for keeping the CP2102N working. I did not research. But do you know whether other serial libraries handle this differently in a way that would allow both devices to work? Could you give the Prolific driver from the Mac App Store a try? My first shot with it in #194 (comment) was not the worst I've made. |
Tried with prolific just now. It's not working with original way for legit one and counterfeited one.
Hmm I think drop the PL2303 first then take a support with extra feature flag, in example // features ['macos-prolific-hotfix`]
let mfn = u.manufacturer.clone().unwrap_or("".to_owned());
log::info!("mfn : {}", mfn);
#[cfg(all(
any(target_os = "macos", target_os = "ios"),
feature = "macos-prolific-hotfix"
))]
if mfn.to_lowercase().contains("prolific") {
println!("Prolific Device on macOS should be handle with different ways.");
prolific_apple_patch::open(config)?
} else {
open(config)?
}If you agree on this, I will make PR for this |
- Serial TTY considered TerminalBackend - PTY prefix to TTY - macOS PL2303 hotfix (serialport/serialport-rs#194 (comment)) - basic example for serial monitor






This resolves an issue where the baudrate would not be recognized on Mac OS.
fixes #190
The adapter details for the faulty adapter are below:
Device Descriptor
Descriptor Version Number: 0x0200
Device Class: 0 (Composite)
Device Subclass: 0
Device Protocol: 0
Device MaxPacketSize: 64
Device VendorID/ProductID: 0x067B/0x2303 (unknown vendor)
Device Version Number: 0x0300
Number of Configurations: 1
Manufacturer String: 1 "Prolific Technology Inc."
Product String: 2 "USB-Serial Controller"
Serial Number String: 0 (none)
I tested with other adapters (mostly FTDI adapters) and baudrates and this has not provided me with any adverse side effects.