SparkFun Forums

[sparky]

For all those who are wondering about Linux support for the CP2102 USB to UART IC - this is the response I got from SiLabs. The updated ftp login information is here as well as a linux explanation. I am not a linux person. Can a guru verify what it means or if '2.4.x kernel version' support is good enough?

-Nathan

Hi Nathan,

The latest VCP drivers are located on our ftp site:

ftp://ftp.silabs.com/Release
user : cp210x
password : cp210xxfer

IMPORTANT: If you have a Windows CP210x driver currently installed,
please uninstall that using Windows Control Panel "Add or Remove
Programs" (uninstall the "CP210x USB to UART Bridge") BEFORE attempting
to run the new installation.

After running CP210x_Drivers.exe, the "C:\Silabs\MCU\CP210x\WIN\" folder contains v4.28 drivers (WHQL certified). The drivers in "WIN" can be installed by running "PreInstaller.exe" before plugging in the CP210x.

Also, you can generate drivers customized with your company/product
information using AN220:
http://www.silabs.com/public/documents/ ... /an220.pdf
AN220SW:
http://www.silabs.com/public/documents/ ... N220SW.zip

Note that once you have generated customized drivers using AN220, the
v4.28 drivers will no longer be WHQL certified. Please let us know if
you would like more information about the WHQL certification process.

>Are the latest drivers now open source for Linux users? The last
correspondance I had stated these were to be released in April...

The beta Linux source package is available on our ftp site:

ftp://ftp.silabs.com
user : cp210x_linux
password : linuxdriver

The Linux source package contains the complete source code for the
CP210x Linux VCP drivers. This code can be compiled for various Linux
2.4.x kernel versions without "tainting" the Linux kernel. The zip file
contains source files, Makefile and driver load scripts, a Readme with
instructions, and a tar file that contains the driver binary files.

To use the CP210x on Linux:
1) gunzip the files
2) untar the files
3) load the driver (using "load_mcci_usb" on an account with
administrative privileges)
4) the CP210x has to be plugged in for "mcci_x" to appear in /proc
5) the command "cat /proc/mcci_x" lists the device, which should look
like ttyUSB#
6) set the serial port device in the appropriate application to
"/dev/ttyUSB#"

>Are the latest drivers fully compatible with OS X?

Yes. The latest driver package includes default drivers for Mac OSX.
If you would like customized drivers, please fill out and return the
attached form.

Please let us know if you have any questions.

Best Regards,
Tabitha

[JamesC]

This is a good step, but I'm still waiting for 2.6 support.

I believe, based on our prior conversation and the link that you sent me, that a CP2101/2 module may actually be rolled into the next minor kernel release, which should be 2.6.12 Sorry that I don't follow these releases closely, but I'll check for this when it's out. This would be a big deal, as it means that the end user doesn't have to compile a kernel module to get it to work (not always a trivial task).

My FTDI adapters (such as the olimex AVR-USB board) required zero work on my part to use with recent 2.4 or 2.6 kernels. Plug them in and go. I'm hoping that the CP2101/2 eventually works the same way.

[keshava5]

*******To use the CP210x on Linux: *************
1) gunzip the files
2) untar the files
3) load the driver (using "load_mcci_usb" on an account with
administrative privileges)
4) the CP210x has to be plugged in for "mcci_x" to appear in /proc

I HAVE DONE all the above steps but i am unable to do how to set it
can u kindly help me out
to do step 5 and 6 javascript:emoticon(':(')
Sad

which command i need to use ?? i am very new to linux. i need to write my program for cp2101. it works fine with normal serial com. as ttyS0
but in cp2101 i dunno how to find which port it has got set and how to set it toooo

5) the command "cat /proc/mcci_x" lists the device, which should look
like ttyUSB#
6) set the serial port device in the appropriate application to
"/dev/ttyUSB#"
javascript:emoticon(':roll:')
Rolling Eyes
I am using Fedora core 1 kernel ( 2.4.22 )
Thanking you
keshava

[mistered]

It's unfortunate that this driver is a perfect example of a vendor that doesn't "get it." This driver is supposedly GPL, yet has been run through some mechanical translation in order to obfuscate it. Despite the fact that this is contrary to the purpose of the license, it really serves no purpose anyway.

Do they really think something like

Code: Select all

#define \
l111110100 \
  \
(010304)
int
mcci_vids
[
]
=
{
l111110100
,
0
}
;

is going to prevent anyone who cares from understanding what their driver is doing?

[riden]

Obfuscators (even bad ones) generally will mangle identifier names and do other unhelpful things to the code. This example looks more like a code beautifier gone bad. It seems to be breaking up each token, but instead of indenting and generating newlines as needed, it always inserts a newline after the token.

[mistered]

Nah, I just took an example from the file that defines the device & vendor ID; if you look at the actual driver it's very clearly an intentional obfuscation:

Code: Select all

if
(
l1000000001
==
NULL
)
{
printk
(
"\045\144\040\157o\160s \165sb\137s\145ri\141l_\160o\162\164 \160\157i\156t\145r\040i\163 \116UL\114\012"
,
__LINE__
)
;
return
;
}
l1000001100
=
l1000000001
->
serial
;

so you're right that it's sticking a newline after each token, but it's also replacing those indentifiers that it can with generated ones, scrambing strings, etc.

[riden]

I see what you mean. What kind of identifier name is "l1000001100" supposed to be anyway??? Life is short. I value clean and easy-to-read code and I make every effort to create such code. Don't you wish everyone did?

[mistered]

Indeed. I started to play around with sed + indent and such to see what it would take to make it readable, but it's not worth it when there are other vendors of equivalent parts offering documentation, sample devices and support to the open source community. I'll just use their parts instead. Luckily they're also available from sparkfun .

[cabbage]

Couldn't you run it though cpp (i.e. do gcc -E source.c >source.txt to do the macro substitution at least and it might look a little more sane?

Edit: tried that (obviously I'm bored - I don't even have one of those devices!) but actually it's not much of an improvement...

[powool]

I decoded this source file once - I'll see if I can find the source I cobbled together. I got it to the point where I could reverse engineer it if needed, but gave up and bought an FTDI based USB interface.

It gets a lot clearer after doing a bunch of simple cleanup - first remove extraneous newlines, then go through and start doing obvious variable and function name substitutions.

It helps to look at one of the other basic Linux USB serial drivers - see where things plug in and how, and use the same kinds of names, etc, and you'll see an awful lot of the code just drop right out. The strings are 'encoded' as octal, so just go through and convert them back to normal strings, and by then you'll even start figuring out which driver they ripped it off from. Oh, and the debug prints include some of the variable names in them as well, so you can get clean nice names of some of their 'hidden' names.

The tricky stuff is setting up the control bits based on baud rate, etc, but that too gets pretty easy to decode when looking at a similar driver.

It is very childish, possibly illegal and definitely immoral of them to have done this, and they should not be rewarded for it - buy another product if you possibly can.