I just wanna be able to tune my car using Parallels or Crossover and the AEM software. My car ECU uses RS-232 and Big Sur broke that.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Anyone have USB to Serial FTDI (or Prolific) support working yet under Big Sur?
- Thread starter adcx64
- Start date
- Sort by reaction score
This forum used to be so great back in like 2012. Now it's nothing technical and all "Do I NeEd AntIvIrUs" that could've been googled. Or someone complaining about the wrong shade of blue on their dock icons in Big Sur. Does anyone here do actual work or have an actual technical background? We used to have guys like ChrisMacGuy and Intell here to have some real tech talks.
So tired of the "Is it okay to charge my laptop overnight" idiots on here.
So tired of the "Is it okay to charge my laptop overnight" idiots on here.
MacOS Big Sur & RS-232 Serial Communications
How can I use RS-232 communication with MacOS Big Sur?
tips.graphica.com.au
Big Sur changed the requirements for 3rd party USB to serial devices. The change was announced in June 2019 (Catalina) and finalized in November 2020 with the Big Sur release. During that time, both kernel extensions (KEXT) and DriverExtensions (DEXT) where supported.
As far as I can tell, FTDI has not released even a beta version of a DriverExtension for their customer specific devices. There are 80 standard FTDI devices which are covered by Apple's FTDI DriverExtension, and 402 customer specific devices that are not
DS
Are you trying to do this with the M1 mac in your signature?
i.e. using a Windows for ARM insider release under Parallels 16.5 ?
if so then while FTDI, Prolific and Silicon Labs are all supported on the Big Sur side of things, the same isn't true of Windows for ARM itself:
Prolific PL2303 don't have an ARM64 Prolific driver
FTDI have a beta ARM64 one
Silicon Labs CP2104 has an ARM64 one as part of their universal driver file for Windows - however the ARM64 driver in there doesn't have an installer You'd need to do an old fashioned driver update/locate manually/point to the folder you extracted the archive to style install Once its installed you'd also need to access the drivers power management settings and turn off the option to have windows turn the device off to save power (or the device will just endlessly restart)
Under x86 Windows 7/10 on an intel mac any recent build of Big Sur should enumerate all three of those devices on connection to the mac and Parallels should then be able to have them assigned to be under its' control rather than MacOS.
You then just need the appropriate Windows 10 x86/64 driver to use them within Windows which all three brands have.
i.e. using a Windows for ARM insider release under Parallels 16.5 ?
if so then while FTDI, Prolific and Silicon Labs are all supported on the Big Sur side of things, the same isn't true of Windows for ARM itself:
Prolific PL2303 don't have an ARM64 Prolific driver
FTDI have a beta ARM64 one
Silicon Labs CP2104 has an ARM64 one as part of their universal driver file for Windows - however the ARM64 driver in there doesn't have an installer You'd need to do an old fashioned driver update/locate manually/point to the folder you extracted the archive to style install Once its installed you'd also need to access the drivers power management settings and turn off the option to have windows turn the device off to save power (or the device will just endlessly restart)
Under x86 Windows 7/10 on an intel mac any recent build of Big Sur should enumerate all three of those devices on connection to the mac and Parallels should then be able to have them assigned to be under its' control rather than MacOS.
You then just need the appropriate Windows 10 x86/64 driver to use them within Windows which all three brands have.
In Big Sur 11.3.1, I can use an old Keyspan USA-28 or USA-28X (not FTDI devices) using a driver made for Mac OS X 10.6 (still works with 11.3.1)
Driver for USA-28XG (Mac OS X 10.6.x to 10.8.x)
A driver just needs to make a couple devices (tty and cu). Then any Unix command line app can use them (such as
cu or screen). Or an app like Serial.app or MacWise.app or Parallels.Parallels can create a serial port device that points to a Mac's dev/cu.* device. Or it can point to a socket file (for communicating between two virtual machines, or other purposes). In either case, a standard Windows com driver will get used to handle the emulated port.
Another way to add a serial port to Parallels is to give control of a USB device to Parallels. In that case, macOS has nothing to do with it. You just need the Windows driver for the USB device.
Of course none of the above applies to M1 Macs. I don't know the issues with those or how Parallels works with them.
Last edited:
On M1 adding a serial port to Parralels by pointing at the cu device on the MacOS side doesn't really work*:
If you configure one that way then the Parallels menu Devices list does show a serial port entry and does show that its being pointed at that cu device - it'll even complain if you then open a connection using that port on the mac side of things (which kinda proves it is aware of it and knows that it should be making use of it)
but it never goes the last mile to enumerate it to the system in order to create an entry in Win 10 device manager, so as far as any serial app running on the Windows VM is concerned there is no COM port
Which leaves you back at only remaining option of handing off the device to Parallels direct control at the hardware level, rendering it invisible to MacOS and needing the Windows ARM64 drivers
*or at least that's the behavior I get with the Standard edition.. Whether its been deliberately hobbled so that its only functional in the Business and Pro subscription editions I couldn't tell you*
If you configure one that way then the Parallels menu Devices list does show a serial port entry and does show that its being pointed at that cu device - it'll even complain if you then open a connection using that port on the mac side of things (which kinda proves it is aware of it and knows that it should be making use of it)
but it never goes the last mile to enumerate it to the system in order to create an entry in Win 10 device manager, so as far as any serial app running on the Windows VM is concerned there is no COM port
Which leaves you back at only remaining option of handing off the device to Parallels direct control at the hardware level, rendering it invisible to MacOS and needing the Windows ARM64 drivers
*or at least that's the behavior I get with the Standard edition.. Whether its been deliberately hobbled so that its only functional in the Business and Pro subscription editions I couldn't tell you*
Last edited:
1) So this is a problem with Parallels not creating a COM device? or whatever it would be called on ARM - if ARM even has com devices? Does the ARM VM created by Parallels emulate PCIe? In that case, there exists PCIe serial ports which Parallels could emulate...
2) So this is a problem with Windows not having ARM drivers for USB serial port devices.macOS can use the USB serial device using the cu and screen commands?
Which leaves you back at only remaining option of handing off the device to Parallels direct control at the hardware level, rendering it invisible to MacOS and needing the Windows ARM64 drivers
Neither of these issues is related to Big Sur (except that M1 Macs can't using anything other than Big Sur).
Aye, if the OP is running Windows for ARM on an M1 mac thru parallels, then they'll have no USB to Serial without a manufacturers ARM64 driver
which at the moment seems to be Silicon Labs CP210x as the only choice
Their CP210x Universal Windows drivers can be downloaded from here on Si Labs site
yes, Windows for ARM does have COM ports, parallels just doesn't present its usual virtual ones to it
and yes it really doesn't look like its any sort of Big Sur issue - unless conventional Parallels also fails to present it's virtual serial ports under Big Sur too ..Which I can't say one way or the other as the only parallels 16.x that I'm running is on an M1 device (rest of mine are on years old versions of parallels and MacOS)
which at the moment seems to be Silicon Labs CP210x as the only choice
Their CP210x Universal Windows drivers can be downloaded from here on Si Labs site
yes, Windows for ARM does have COM ports, parallels just doesn't present its usual virtual ones to it
and yes it really doesn't look like its any sort of Big Sur issue - unless conventional Parallels also fails to present it's virtual serial ports under Big Sur too ..Which I can't say one way or the other as the only parallels 16.x that I'm running is on an M1 device (rest of mine are on years old versions of parallels and MacOS)
On M1 adding a serial port to Parralels by pointing at the cu device on the MacOS side doesn't really work*:
If you configure one that way then the Parallels menu Devices list does show a serial port entry and does show that its being pointed at that cu device - it'll even complain if you then open a connection using that port on the mac side of things (which kinda proves it is aware of it and knows that it should be making use of it)
but it never goes the last mile to enumerate it to the system in order to create an entry in Win 10 device manager, so as far as any serial app running on the Windows VM is concerned there is no COM port
Which leaves you back at only remaining option of handing off the device to Parallels direct control at the hardware level, rendering it invisible to MacOS and needing the Windows ARM64 drivers
*or at least that's the behavior I get with the Standard edition.. Whether its been deliberately hobbled so that its only functional in the Business and Pro subscription editions I couldn't tell you*
Thanks for the actual thoughtful discussion here everyone. Looks like the newest build of Windows for ARM supports the prolific chipset. I got it working.
@adcx64 what version of Windows for ARM did you have to update to to get your Prolific chip to work?
I just updated to Win10Pro Build 21390.2025 (Insider ARM64 build) running in Parallels 16.5.0 (50692) and my USB to Serial controller (VID_067B&PID_2303) is still coming up as unrecognized (code 28).
I also tried the Prolific 2.0.6 driver recently released on 2021-06-02 but I guess that still isn't ARM64 native.
Finally, forcing it to use Microsoft's usbser.sys (Browse For Drivers => Ports => USB Serial Communications) in Device Manager also didn't seem to work.
This is all on a MacBook Air M1. Parallels sees the USB device fine and passes it through to show up in the Win10 Device Manager, but the drivers don't seem to be present.
Thanks!
Last edited:
Sorry for the later reply. I used device manager and added the driver manually under "ports" it said something along the lines of just COM port or the such, I am away from my desk, if you still haven't got it, let me know and I will walk you though it.
You may have selected the wrong driver. Windows knows its a USB device, just not a COM port. So I believe "USB to Serial Communications" would not work, I believe I just made it a COM port.
You may have selected the wrong driver. Windows knows its a USB device, just not a COM port. So I believe "USB to Serial Communications" would not work, I believe I just made it a COM port.
Thanks. See attached screenshot for the options I have to choose from under "Ports".
I chose "USB Serial Device", and said "install anyway" to the warning that followed. I don't see an option for just "COM port", USB Serial means it should enumerate it as a Serial (COM) device. Once it's installed I do get the usual configuration details for a serial/COM port, but any of the software I'm trying (radio programming sw) can't make use of the device.
I chose "USB Serial Device", and said "install anyway" to the warning that followed. I don't see an option for just "COM port", USB Serial means it should enumerate it as a Serial (COM) device. Once it's installed I do get the usual configuration details for a serial/COM port, but any of the software I'm trying (radio programming sw) can't make use of the device.
Attachments
Last edited:
Okay, try the modem one, if that doesn't work, I can go out to the car and get the USB to serial adapter and verify 100% for you.
Even works on Monetary beta 1.
Even works on Monetary beta 1.
I'm asking for help. I have updated my Mac Book Air to oc Big Sur. I had a FTDI driver to control my radio. After the update, I can't install this driver. Who will post a step-by-step installation guide and which driver you need to choose to get virtual ports.
Use the windows built in USB to serial modem driver, when you select from the list of drivers in Windows.
Came across this thread while waiting for my M1 Pro 14.2" to arrive in a few days. I was not aware there was such a huge issue with drivers or that M1 required ARM version of Windows until I already ordered the new Mactop. I use Parallels v17 for programming Motorola two-way radios and police scanners, which require either Prolific/FTDI USB to serial conections or their own USB to serial drivers. The upgrade from v16 to v17 led me to have to figure out the + Serial Port in hardware tab in Parallels, and from what I see there the drivers are on the MacOS side and not required on the Windows side? Anyone have a late October update on how that functionality is playing out in Windows 11 ARM Insider Builds? I am seriously considering walking the new Macbook back into Apple store unopenned for a refund if I am going to completely lose the ability to program using Windows on Parallels. I currently have a 16" i9 Intel Macbook Pro, so it would not be the end of the world.
Paul
Paul
I am attempting to use Windows 11 (arm) in Parallels v17.1.7 on my M1 Mac mini, so that I can use my two USB programming cables for a Baofeng radio (CHIRP with FTDI cable) and Radioddity DB20-G radio (their v2.02 cps software with their USB to RJ-45 cable, which I believe is Prolific).
So far, I am able to get the FTDI cable to work with Windows CHIRP using the instructions from NeilT4 (Post #15) on this thread in the Parallels Forum:
USB Device Pass Through
So far, I am able to get the FTDI cable to work with Windows CHIRP using the instructions from NeilT4 (Post #15) on this thread in the Parallels Forum:
USB Device Pass Through
Last edited:
It's not cheap, but Serial handled everything on Big Sur (Intel) that I needed. [$40 USD]
Free 7 day trial. Native support for Apple Silicon.
Free 7 day trial. Native support for Apple Silicon.
USB/Serial Bridges
Serial includes built-in support for cables and devices that are USB CDC (Communications Device Class) compliant or that use one of the following USB/Serial bridge chips:Virtual Com Port (VCP) Bridges
- FTDI FT232R, FT232B, FT232H, FT2232H, FT4232H, FT230X, FT231X, and FT234X
- Silicon Labs CP2101, CP2102, CP2102N, CP2103, CP2104, CP2105, CP2108, CP2109
- Prolific PL2303 device family
- WCH CH340 and CH341
- Texas Instruments TUSB3410
- ASIX (formerly MOSCHIP) AX78120, AX78140, MCS7810, MCS7820, and MCS7840
- Magic Control Technology MCTU232
HID (Human Interface Device) Bridges
CDC (Communications Device Class) Bridges
Devices
The following devices are known to work well with Serial:- Particle Photon, Electron, Xenon, Argon and Boron
- BeagleBone Black
- Sparkfun's Arduino Pro Micro 5V/16MHz and Arduino Pro Micro 3.3V/8MHz
- Moxa UPort 1000 Series Devices
- Keyspan/Tripp-Lite USA-19HS
- USB Modems that list CDC compliance - "soft modems" often are not compliant
- Any other USB CDC compliant device
Last edited: