I haven't used this part in particular.
You may already know the following, but here is some generic USB-to-
serial advice...
Under Windows, this will get assigned to about COM5 or above. Depending
on the provided drivers and possibly what version of Windows you have,
sometimes the COMx number will bump up by one every time you insert and
remove the device; during development you might manage to run Windows
out of COMx port names. This isn't usually a problem for end users,
because they don't plug and unplug as much as you will, but it might
catch some of them.
The chip probably has a fixed USB vendor and device ID, so it will
always show up as something like "SiLabs CP2102 Serial Converter" to
Windows. If you want it to show up as a "Jamie Niftytron", you need to
be able to reprogram these IDs; some chips support this and some don't.
The whole spiel is to get a USB vendor ID from the USB people, program
that ID into the chip, and then ship a file to tell Windows that vendor
0x4321 is "Jamie" and device 0x1234 is "Niftytron". Note that if you
program your Windows application to assume that the first COMx port that
identifies as a SiLabs CP2102 is your gadget, then your first customer
will have six other SiLabs CP2102 USB-to-serial converters plugged in to
their PC.
One trap to watch out for: the USB-to-serial chip and your
microcontroller have to agree on the serial parameters (bit rate,
parity, stop bits, etc.) When people started retrofitting USB-to-serial
chips onto existing devices, sometimes they forgot this, and their
software would tell the microcontroller to switch to 9600 8N1 while the
USB-to-serial chip was still on 2400 7O2. The end-user fix was to power
cycle, sometimes involving dissasembly to disconnect a battery.
I agree. You probably don't want to write OS-level drivers (for any OS)
if you don't have to. It depends on the end use, but right now you'd
plausibly have to support four different versions of Windows (XP, Vista,
7, 8), at least a couple of different Linux kernel versions (2.6.x and
something newer, probably 3.x.x), and at least a couple of different
versions of OS X (probably 10.7 and 10.8).
For a while, if you wanted it to run on Linux, the standard advice was
to use the Prolific PL2303 chip. The driver for this has been in the
kernel for a while and works well. There may be good drivers for
other chips now; I haven't looked lately.
The chip vendor will often say they support Linux, but the binary driver
they provide will always be for an outdated kernel version that nobody
runs. If the chip vendor provides source for a driver (uncommon), it
will also only build against an old kernel, and be hard for end-users to
install. If the driver ships with the kernel from kernel.org, and is
present on recent versions of well-known distributions (Fedora, Debian,
Gentoo, SuSE, etc), then it will probably work OK.
I don't know what the situation on OS X is like. Probably you have to
trade a $1 chip for a $5 one that comes in a sleek white case, and pay
Apple to get your software on iTunes, or something.
Matt Roberds
