I'm happy to report that I've solved the problems listed in my last post. I now have 17 COM ports working under Windows 11 ARM on my 14" Mac M1 Max!
The biggest breakthrough was realizing that my two 8-port USB-to-RS232 hubs weren't receiving 12VDC power (Duh!) Once I corrected that, the Mac saw them and passed the 16 individual COM ports to Parallels. That means the FTDI drivers on the Mac side work with multiport hubs.
As expected, the ports showed up under USB in the Windows Device Manager with exclamation points. I loaded the FTDI beta ARM drivers by disabling driver signing checks as instructed by kduminwa. I used beta CDM v2.12.32.B3 for ARM64. Does anyone know if there's a more recent version?
The COM ports initially showed up with no port names, but by updating the device drivers a second time port names were assigned. I think it's really this -- loading the device driver twice, rather than adding the PortName field in the registry entries under Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ -- that assigns the port names.
However, the COM ports had the wrong numbers for the software I'm using, and the port names started with COM11, rather than COM3 as they do on my desktop. Evidently, COM1-COM10 were in use. And, as I reported above the COM port names can't be changed in Properties for the devices. But when I went to change the port names, I found that none of the entries under Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ contained port names. Where were they?
The key was finding this document published by FTDI in 2016:
https://www.ftdichip.com/Support/Do...Assigning_COM_Port_Numbers_Using_Registry.pdf
The document indicates that FTDI ports entries are found under Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FTDIBUS\. Sure enough, each of the entries there contained a Friendly Port Name (what you see in Device Manager) and a PortName. The FTDI document also describes this important key:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\COM Name Arbiter
This field has a bit for each COM port. A one (1) indicates that the port has been allocated. Sure enough, I found that COM3-COM10 were allocated, even though those devices don't exist on my system. I uninstalled all my COM ports, set the corresponding bits to zero, and reinstalled my COM ports. They started with COM3 this time.
The next problem was that the COM ports still didn't match the numbers used in my software. I could have changed that in some of the software, but other older programs limit the COM port number range to COM1-COM8 and need ports that were assigned higher numbers on my Mac M1. First, I had to test each port to see what it actually connected to. Next, I had to change all the COM port names. It's a major pain to change COM port names on the fly in the registry because it won't let you rename a port to have the same name as another port (a problem that also comes up when you change COM ports in the Properties page for the device, when that's working.) So, I followed the instructions in the FTDI document for changing COM port numbers by dumping the FTDI key to a file, manually editing the COM port numbers, and re-loading the file into the registry. I had to reboot to get the changes to take effect, but it worked like a charm. All the COM ports are working just as they do on my huge desktop PC, which I can now retire because the Mac M1 can do everything it does.
The one remaining problem is that I have to boot with driver signing check turned off whenever I want to use the COM ports. Hopefully FTDI will fix that. Again, does anyone know of a beta or released version of the drivers that's newer than CDM v2.12.32.B3 for ARM64?
