SILICON LABS USB-TO-UART Bridge Controller EVM - Review

Table of contents

RoadTest: SILICON LABS USB-TO-UART Bridge Controller EVM

Author: boncester@gmail.com

Creation date:

Evaluation Type: Evaluation Boards

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?:

What were the biggest problems encountered?: Confusion as to whether the Baud Rate was selectable through software or the device driver properties

Detailed Review:

I am interested in this development board for the simple reason that I need something with which I can run up a quick to implement USB to UART interface for communicating with ESP8266 boards.

I've used other devices to perform this task before, but I've found that using them was a little bit fraught with worry with the USB extension leads and long breadboard cables.

This was creating fragile, easy to disconnect points along the wires all the way back to the computer, and frankly when flashing a new firmware to ESP8266, having to worry about fragile wire connections adds another whole level of error checking into the process, so to see a simple breadboard ready unit that the USB lead connected into really would solve any worries around a lead falling out etc.

 

So, this development board would enable me to securely connect a UART bridge through from USB, removing the worry of wires becoming disconnected part way through a firmware update.

 

First impressions

The unit comes in a box seated in a foam board with basic pinouts printed on it so you can get started quickly.

It directs you to the Silabs.com website where you can download drivers, read up the white-pages and get some example usages for some ideas.

URL: CP2102N Mini Evaluation Kit | Silicon Labs

 

Installing the driver was simple, although when I tried to do this on a mobile device I found the mobile experience was extremely poor.

Short story? My advice is not to use the Silabs website on a mobile device, use it on a laptop or computer.

Device Driver URL: USB to UART Bridge VCP Drivers | Silicon Labs

 

When I had driver it was a simple process to install onto my Windows laptop, presented no surprises etc and when the CP2102n device was then plugged into that laptop it immediately showed in Device Manager.

 

There was one aspect that was not particularly well documented, however. It was simply 'can the board change the UART Baud rate based on a application setting?'.

The reason this became a concern was that early in the instructions or usage, for Windows you are shown how to change the Baud rate inside the Properties of the device  in Device Manager, which seemed a little clunky given that most Serial Terminal software will happily set the expected Baud rate for you and reading around on the internet it wasn't entirely clear whether this indeed was possible or whether you would have to change the internal driver properties in Device Manager to affect a Baud rate change on the CP2102n.

 

I had found references around the internet that the CP2102 chip should be able to dynamically change the Baud rate based on application setting but before getting any further I definitely wanted to check this.

So, I connected the CP2102n using Tx and Rx to an Arduino Uno that was tied in reset causing it to be essentially an expensive USB to UART bridge, then used two serial terminals to the two devices to test that when they were both set to the same Baud the messages were echoing to the other terminals in both directions, and that when the Baud rates were not the same, the echoed response was garbled, and this was indeed the case.

 

This was brilliant news as I know that the ESP8266 chip will react very differently based on the incoming Baud rate of the serial connection.

 

So, I connected the Rx and Tx to Tx and Rx on my ESP8266, connected the VRegin to the ESP8266 power pin and the Ground to the ESP8266's Ground pin, plugged in the CP2102n to my laptop and opened Putty.

I started up a Serial session on Baud 115200 and it opened up the serial session window as normal.

The serial window displayed the ESP8266 firing up and left me at a python cursor point of '>>>', so I entered into the serial session 'print("this works!")  and pressed enter.

..and it worked!

 

This means that this is a brilliant little board to have in my toolkit that when I need to flash new firmware to a ESP8266 or just debug some running code on one.

I can put it on to a breadboard, connect up the ESP8266 running the serial lines to it and safely do what I need to without a whole lot of trailing wires, running risk of shorting or falling out half way through.

 

In short, it's a very welcome addition to my development toolchain, it's already proving itself.

Anonymous
  • Hi Michael,

     

    From what I saw at a quick glance was that the unit is based, probably loosely, on the old Intel 8051 serial chip dating back to the 8080 and 8085 days.

    The interface registers looked similar and the function clearly matches what I used the older devices for.

     

    So it might be a reverse engineered core or a new design, but the functions look very familiar.

     

    DAB

  • main reason to use 8051 type controllers is that their license lifetime has expired. That makes them a good candidate as the brain for smart ICs (that run a state machine internally) and mass produced low price products.

  • Hey Mark,

     

    They do apply to USB COM ports too, but only if the controller chooses to execute the instruction to set the line coding.

     

    If you have control over the firmware of the USB controller, you would normally ignore that command if the serial port you're exposing is either tied to an IC with known serial port parameters (at design time) or if it's not a serial port at all, but it's exposed as such for convenience.

     

    Razvan

  • Sorry DAB - what is an old 8051 - my reading of the data sheet for the CP2012 and the app note AN169 is that the the CP210x bridge parts are not actually 8051s. I had wondered if they were just pre-programmed standard Silabs 8051 parts but the data sheet implies not.

     

    BTW, Silabs 8051s are not old 8051s such as you might have used in 1980 - the SIlabs 8051 core is much faster  - offering  a much better instruction cycle to clock cycle ratio and some parts with 100MHz clock capability. The horrible instruction set and architecture is almost identical. There was a brief period (about 12 years ago) when they were attractive but the rise of the ARM Cortex has left them looking rather passe.

     

    MK

  • Ah, now I see, it is just an old 8051.

     

    I used these back in the early 1980's for serial communication between systems.

     

    In those days we had to use the RS-232 driver chips to make sure we could support the legacy devices.

     

    DAB

  • Nice review.

    I've always wondered about the windows setting of the com port, and rightly or wrongly, decided that it only applies to hardware com ports, not a USB device.

     

    There is some additional info here.

    http://www.silabs.com/documents/public/application-notes/AN169.pdf

     

     

    Mark

  • Short story, 5v (or less).

    You'd likely want to get your signal to 3.3v on your signalling device, just to be comfortable.

  • For what I thought was an overly simple board that a review could not really be done on you did an AMAZING job!!!

     

    Thanks for the worthwhile review

    Kas

  • Nice test report.

     

    I am assuming that the UART in this case will only support 5v or less devices?

     

    It did no look like the full RS232 UART capability was included with the simple chip.

     

    DAB