I have been asking for over a year for a fix to the current CP210X OS X drivers which will allow sane naming of multiple device names. The seemingly random assignment of a number to the end of the SLAB_USBtoUART device name is causing havoc every time I restart my Mac with two CP210X devices attached.
Other drivers for other devices append something unique to the device, like a serial number, to the device name so that it is not only unique but associated with the same physical component no matter what. Will you folks please look at doing this soon with the CP210X driver?
Thanks for pinging us! This is on our list to do and will be rolled into the next maintenance release of the Mac OSX driver. We don't currently have a time frame for when this will happen, but you're welcome to ping us for an update at any time.
Thanks Tabitha. This fix alone will solve multiple issues that our customers are having here, and I know other software developers who are looking for this fix. I appreciate the update and am glad to hear it's in queue!
It's been a while since there's been any update on this request. Can you provide one? Thanks!
I saw you already create a ticket in our technical support portal.
Maybe you could update that case.
good luck with this...they still don't have GPIO support for either Mac or Linux for the CP2103 devices..
I don't see the ticket in my list of open tickets. Do you have a ticket number?
The case number is:
I'm not exactly sure how I got two accounts, but I'm posting under another username.
Folks, it has been over TWO YEARS since I created this support ticket. I even provided suggestions as to how you could tackle this problem. It's a basic expectation of a driver to handle multiple device instances without mangling up the names.
Can you please get this fix scheduled? It's been way too long.
One year later, any news on this issue? The problem is still there
Is there any solution to this problem? I mean, is there anything that can be reconfigured in the CP2102 EEPROM using e.g. the "Xpress Configurator", to individualise each VCP on a Mac? It's a real pain in the ass every time I pull the USB cable of the hub with four CP2102 device: I must reconfigure all my test software!
sure best way would be to to modify the EEPROM of the CP2102 in order to serialize them. I have not tried this. Instead I tried to identify my CP2102 devices in the USB device tree of my computer. That way I was able to retrieve the specific CP2102 device name. Once you know how your USB ports are numbered in the USB device tree of your OS your are able to automatically identify your CP2102 plugged into a certain USB port.
I was using Python. Here are the main lines of code:
from packaging.version import Version #"pip install packaging"
from optparse import OptionParser
import sys, os
import serial.tools.list_ports #"pip install pyserial [--upgrade], needs min 3.0 because API of serial.tools.list_ports.grep returns ListPortInfo objects instead of a tuple
e], needs min 3.0 because API of serial.tools.list_ports.grep returns ListPortInfo objects instead of a tuple if Version(serial.VERSION) < Version('3.0'): s = "pyserial needs to have at least version 3.0. Have %s " % serial.VERSION raise Exception(s) # serial.tools.list_ports.grep(() returns a regexp match on "name|description|hwid" (case insensitive) # name|--------------------description---------------------------------------------------------|------------------hwid-------------------------------- # MacOS : None| CP2102 USB to UART Bridge Controller - CP2102 USB to UART Bridge Controller|USB VID:PID=10C4:EA60 SER=0001 LOCATION=20-18.104.22.168.4.5 # Windows 10 : None|Silicon Labs CP210x USB to UART Bridge (COM13) |USB VID:PID=10C4:EA60 SER=6 LOCATION=1-2.9 # Linux : |'Linux Foundation 1.1 root hub |USB VID:PID=10c4:ea60 SNR=0001' # common part regex all 3 OS: "USB VID:PID=10c4:ea60" # common part regex MacOS & Win: "CP210. USB to UART Bridge" ports = serial.tools.list_ports.grep("USB VID:PID=10c4:ea60") #Make new list from generated 'generator' objects returned by grep above pl =  for p in ports: pl.append(p) #Sort list by object attribute 'location' pl.sort(key=lambda x: x.location, reverse=False) for p in pl: print "-----------------------------------------" print " device : " + p.device print " location : " + str(p.location) print " name : " + str(p.name) print " description : " + p.description print " device : " + p.device print " hwid : " + p.hwid print " vid : " + str(p.vid) print " pid : " + str(p.pid) print " serial_number: " + str(p.serial_number) print " manufacturer : " + str(p.manufacturer) print " product : " + str(p.product) print " interface : " + str(p.interface)
Interesting. However, I use the four CP2102 adapters with minicom. Each time I unplug and re-plug the hub with the four adapters (or only one of them), the serial port becomes another name. How is someone supposed to work under these conditions? the /dev/uartxxxx name must be provided as a parameter (-D) to minicom.
On the other hand, I have an application written in C on MacOS, but I have no idea how could I get the USB tree info using the serial I/O POSIX API.
I had the same problem. I am using an extern 10x USB hub to which 10 CP2102 adapters are connected.
By using the script above you get the USB tree information (which is not changing when using the very save USB hub hardware) together with the information of all CP2102 devices plugged into this USB hub (including the always changing device names /dev/uartxxxx or similar). I tried this on Linux/MacOS/Win10, all worked. Take the Python lines above as a starting point, the core information should be already output.
Assume you will connect your minicom to the CP2102 which is inserted into the 3rd USB slot of you USB hub. If you once know which USB tree location the 3rd USB slot is, just find them with my script and output the CP2102 device name to stdoutput. I use them like this:
minicom -D `findCP2102.pl 3` which results e.g. in minicom -D /dev/uart1234
When you replug the USB hub all device names are changed, but the minicom command line remains the same:
minicom -D `findCP2102.pl 3` which results e.g. in minicom -D /dev/uart5678
Ah, I see. I am not a Python specialist, but it seems a clever solution. I will try it tomorrow.
On another hand, I tried to modify the serial number using the "Xpress Configurator", which indeed does the change. However, the MacOS driver still kept increasing the name of the tty devices.
I had a chat with another Mac developer about this yesterday. They are doing something similar in their software to the above solution: walk the USB tree to find all CP210X devices. They then cleverly use file system linking to alias the SLAB_USBtoUARTX device name to another "device name" on the file system.
It works for that application, but other applications must do the same "walk and link" trick for it to be effective across the platform.
While expedient, it is the wrong way to do it. The driver should append the serial number of the device (which I *hope* is unique among CP210x's) when the device name is generated. This is the sure fire way to ensure that multiple devices are easily identifiable in a consistent and unambiguous manner.
If you look at the second message above (Aug 04 2015, 5:21 PM), you'll see that a representative indicated this would go into the next maintenance release. Obviously that never happened and that was almost five years ago. Meanwhile, technology marches on... DriverKit for the Mac has been introduced which changes the driver writing paradigm for the better, but will require resources from Silicon Labs to adapt.
It's disappointing to point out a real issue to a vendor, proffer a solution, and then watch for half a decade as nothing gets done, while the users are still inconvenienced.
This is still bugging me after the latest 6.0.1 driver release.
I get multiple instances of "CP2102 USB to UART Bridge Controller" and for example Arduino IDE or VSCode with PlatformIO on Mac cannot connect ESP32 with CP2102 at all. This makes programming those chips almost impossible on Mac...
However I tried similar setup on Windows and seems to work with no problems.
But I would prefer to do my coding on a Mac as it feels more natural after my 25 years of history on Mac platform (key shortcuts ,etc)...
I do surely hope that Silabs get this issue fixed with new DriverKit development style.