Simple USB / Serial Communication with the CP2102N

Several years ago, a company called Future Technology Devices International (FTDI) sold what may have been the most popular USB / Serial converter on the market at the time, called the FT232R. But this post is not about the FT232R, because that chip is now known for its sordid history. Year after year, FTDI enjoyed their successful chip’s market position – some would say that they rested too long on their laurels without innovating or reducing prices. Eventually, small microcontrollers advanced to the point where it was possible to program a cheap MCU to identify itself as an FT232R chip and do the same work, so a number of manufacturers with questionable ethics did just that. FTDI took issue with the blatant counterfeiting, but they were unable to resolve their dispute through the legal system to their satisfaction, possibly because most of the counterfeiters were overseas and difficult to definitively trace down. Eventually, they had the bright idea of publishing a driver update which caused the counterfeit chips to stop working when they were plugged into a machine with the newest drivers.

FTDI may have technically been within their rights to do that, but it turned out to be a mistake as far as the market was concerned – as a business case study, this shows why you should not target your customers in retaliation for the actions of a 3rd party. Not many of FTDI’s customers were aware that they had counterfeit chips in their supply lines – many companies don’t even do their own purchasing of individual components – so companies around the world started to get unexpected angry calls from customers whose toy/media device/etc mysteriously stopped working after being plugged into a Windows machine. You might say that this (and the ensuing returns) left a bad taste in their mouths, so while FTDI has since recanted, a large vacuum opened up in the USB / Serial converter market almost overnight.

Okay, that might be a bit of a dramatized and biased take, but I don’t like it when companies abuse their market positions. Chips like the CH340 and CH330 were already entering the low end of the market with ultra-affordable and easy-to-assemble solutions, but I haven’t seen them much outside of Chinese boards, possibly due to a lack of multilingual documentation or availability from Western distributors. So at least in the US, the most popular successor to the FT232R seems to have been Silicon Labs’ CP2102N.

It’s nice to have a cheap-and-cheerful way to put a USB plug which speaks UART onto your microcontroller boards, so in this post, I’ll review how to make a simple USB / UART converter using the CP2102N. The chip comes in 20-, 24-, and 28-pin variants – I’ll use the 24-pin one because it’s smaller than the 28-pin one and the 20-pin one looks like it has some weird corner pads that might be hard to solder. We’ll end up with a simple, small board that you can plug into a USB port to talk UART:

Drivers for the CP2102N are included in most popular OSes these days, including Linux distributions, so it’s mostly plug-and-play.

It’s worth noting that you can buy minimal CP2102N boards from AliExpress or TaoBao for about $1, but where’s the fun in that?

Schematic

A basic schematic for the 24-pin version of this chip is pretty simple; I attached LEDs to the GPIO1 and GPIO2 pins, since those can be configured to pulse when ‘transmit’ and ‘receive’ traffic is ongoing. But otherwise, it’s only a matter of implementing the recommendations found in the chip’s datasheet. It’s even got a built-in 3.3V regulator! Here’s the schematic that I wound up with, but you can also find a full KiCAD project in this board’s GitHub repository.

Super-simple CP2102N Schematic. Sometimes I’ll follow the convention which uses an SI prefix instead of a decimal point to save space, so the capacitors marked “4u7” are 4.7 microFarads.

I don’t usually use most of the USART signals besides TX and RX, but I set aside a couple of ‘other’ headers connected to those pins in case I ever come across a project that requires them. The SP0503BAHT TVS diode array seems like a fairly standard part for protecting USB data/power lines, which is good to know about. There are also versions with different numbers of diodes; an SP0502 part has 3 pins with 2 diodes instead of 4 pins with 3 diodes.

Board Layout

There aren’t really any special considerations for designing a PCB around this chip. The trickiest part is that it has an exposed pad on the bottom, which must be connected to ground. If you’re hand-soldering the chip, you should add a large plated via (>=1mm diameter) over the thermal pad connection so that you can melt solder into the hole from the back of the board. The board’s GitHub repository has the footprint which I used, as an example.

It’s a good idea to use thicker traces (>=0.5mm) for power connections, but otherwise you should be able to stuff this board into a pretty small area. I won’t go over the steps in detail, since that would duplicate a lot of what I’ve written previously, but you can check this board’s GitHub repository to see what I ended up with. Still, why not design your own? If you didn’t include the extra two extra headers with the full USART signals, you could probably slim it down a bit.

Configuration and Testing

Once your boards arrive and you assemble them, the chip should work as soon as you plug it in. An easy way to test these converters is to connect a jumper between the TX and RX pins, and connect to the serial port which shows up when you plug the board into your computer. With the ‘transmit’ and ‘receive’ pins connected, you should be able to type into the terminal and see your keystrokes echoed back. If you don’t have a favorite program for connecting to a serial port, screen can actually do the job, for example: screen /dev/ttyUSB0 9600. It’s a little tricky to close the connection, though; you have to hit ctrl+a followed by \, then y. So…hopefully you already have a favorite program for connecting to a serial port?

You can test the board quickly by shorting the ‘transmit’ and ‘receive’ pins, then typing into a terminal on a computer that it is plugged into.

The ‘transmit’ and ‘receive’ LEDs probably won’t work when you first assemble the board, though. You need to configure the chip to assign specific functions to its GPIO pins, and while you can get the chips programmed at the factory if you’re a big customer, I am not a big customer. Fortunately, it’s easy to do this yourself with software that the manufacturer provides without cost. The easiest way to configure one of these chips is to download Simplicity Studio, and use its “Xpress Configurator” utility. As long as the board is plugged into your computer’s USB port, it should be easy to use the graphical interface to set up the chip’s GPIO pins and other settings.

Conclusions

The CP2102N is a nice and easy chip to integrate into your designs, and USB / UART bridges are fairly common requirements for projects using chips that lack a USB peripheral. And even when you have a USB peripheral, it’s still nice that you don’t need to mess around with drivers or vendor / hardware IDs if you use one of these chips.

I dunno, sometimes it seems like the best parts are the ones that sound really simple and boring when you describe them. Boring and predictable is good, when you’re talking about designing electronics. Anyways, here’s the GitHub repository with the board that I ended up with after following the above steps. I’m still waiting to receive this new revision of the board, but it is very similar to the one shown in this post’s pictures.

Comments (3):

Steve

July 14, 2020 at 5:58 pm

Thanks for this.

Are the TX and RX LEDs the only thing you need Simplicity Studio for? Will it otherwise work without customization?
Reply
- Vivonomicon
  
  July 26, 2020 at 1:00 pm
  
  I think so; you should be able to omit the LEDs and use the chips as-is.
  Reply
- Joseph
  
  July 31, 2020 at 9:32 am
  
  I did a similar project. My test script worked without any action other than installing the driver on my machine and plugging in the USB cable.
  Reply

Leave a Reply Cancel reply

“Bare Metal” STM32 Programming (Part 12): Using Quad-SPI Flash Memory

If I had to guess what the world’s most popular footprint for low-density memory chips was, I would probably be wrong. But I’ll bet that the humble 8-pin SOIC / DIP / DFN formats would be near the top. You’ve probably used these before; most ESP8266 and ESP32 modules have one under their little metal shield, and motherboards for computers / cars / synthesizers / etc. often use them for storing UEFI / BIOS / firmware configurations and suchlike.

Pin assignments for a generic Flash module (Winbond W25Q series)

You can get RAM, Flash, EEPROM, and even FRAM memory in these common 8-pin packages. They usually use a SPI interface for communication, with a couple of extra pins for functions like write protection or suspending an ongoing transaction. But if you look in the image above, you’ll see that the /WP “Write Protect” and /HOLD or /RESET wires are also marked as IO2 and IO3. That’s because many 8-pin Flash chips also support a “Quad-SPI” interface, which is very similar to a bidirectional “3-wire” SPI interface, except that it has four I/O wires instead of one.

Some STM32 chips include a QSPI peripheral to interface with these kinds of Flash memory chips. You can use it to manually configure / erase / program the Flash chip, and once it’s initialized, you can also map the external Flash as read-only memory in the STM32’s internal memory space. The peripheral supports prefetching, caching, executing code, and it can even access two QSPI Flash chips in parallel, using 8 data lines in total to transfer a full byte of data every clock cycle.

To learn about the QSPI peripheral, I used the same STM32F723E Discovery Kit from my last post about external memories. In addition to its external RAM and display, this board includes one 64MB QSPI Flash chip connected to the QSPI peripheral. In this post, we’ll learn how to configure the Flash chip for quad I/O access, erase a sector, and write some test values. Then we’ll set the QSPI peripheral to its read-only “memory-mapped” mode, and read those test values by accessing the chip’s internal memory space starting at 0x90000000. If you don’t like copy/pasting, you can find an example project with this code on GitHub.

It is a little bit annoying that you can’t write to the Flash chip in memory-mapped mode, but this peripheral still presents a simple way to quickly read from external Flash using only six I/O pins. And writing to Flash memory has some unique limitations anyways, which is why it is often used to store data which an application rarely needs to modify, like firmware or audio/visual resources. So if you want to learn how to use Quad-SPI Flash memories with an STM32, read on!

“Bare Metal” STM32 Programming (Part 11): Using External Memories

Modern microcontrollers are amazing. They are much faster and cheaper than the sort of processors that powered “real” computers a few decades ago, and they’re also very power-efficient. But software complexity has also grown over time, and as we humans often say about ourselves as we age, it has grown in the wrong direction. Developers have gotten used to having enormous reserves of memory to draw from, so unless an application or library was specifically written for embedded platforms, it probably won’t be able to run with the scant kilobytes of RAM which are included in your average microcontroller.

Fortunately, most vendors include peripherals for accessing external memory when it is needed, and the STM32’s “Flexible Memory Controller” is surprisingly easy to use. Unfortunately, it is not easy to design a custom PCB with parallel memory modules. The interfaces use a lot of signals which are susceptible to electromagnetic noise, so it is important to ensure that all of the traces have the same length and impedance. This is especially hard on hobbyists, because 2-layer boards are not appropriate for these sorts of designs and KiCAD does not support length-matching for more than two traces yet.

So the target hardware for this tutorial will be a $40 STM32F723E Discovery Kit. It is a bit more expensive than the minimal “Nucleo” boards, but it includes 512KB of external RAM and a 240×240-pixel TFT display; we’ll learn how to drive both of those from the FMC peripheral in this post. It also includes 64MB of memory-mapped QSPI Flash memory, which I’ll talk about in a future post.

We’ll use the external RAM to store a framebuffer, which will be sent to the display using DMA.

This evaluation board uses BGA parts, which are almost impossible to solder without special equipment. But it provides an easy and affordable way to learn about writing software for these peripherals. When you are ready to use external memories in homemade designs, you can use QFP STM32s with at least 144 pins, TSSOP memory chips, and a 4-layer PCB.

“Bare Metal” STM32 Programming (Part 10): UART Communication

If you’ve been reading the posts about STM32s that I’ve been writing, I owe you an apology. Usually when people write microcontroller tutorials, UART is one of the first peripherals that they talk about, and I’ve gone far too long without mentioning it. It is such a fundamental peripheral that I vaguely thought I’d already written about it until I got a couple of comments asking about it, so thank you for those reminders!

UART stands for “Universal Asynchronous Receiver / Transmitter”, and it is a very simple serial communication interface. In its most basic form, it only uses two data signals: “Receive” (RX) and “Transmit” (TX). Since it is asynchronous (no clock signal), both devices need to use the same “baud rate”, which is basically the transmission frequency measured in Hertz. If you have a baud rate of 9600, then you expect a new bit every 1 / 9600 of a second. (But technically, your actual transmission frequency will be slightly lower than the baud rate, because the standard includes extra “control” bits which are sent in addition to the actual data.)

One of the most common uses of UART is to transmit strings of text or binary data between devices. That, combined with the availability of cheap off-the-shelf USB / UART bridges, makes it a popular way to add some interactivity and a working printf(...) function to bare-metal applications.

And while a simple 2-wire UART connection is reliable enough for most purposes, there is also an extended USART standard which adds an optional “clock” line to synchronize the two devices’ timing; the extra “S” stands for “Synchronous”. The standards are otherwise very similar, so you might see UART and USART used interchangeably in some places. There are also a set of extra “flow control” signals, but I’m not going to talk about those or USART functionality in this post.

I will cover a few basic ways to use the STM32 UART peripherals, though:

Setting up the UART peripheral to send / receive data one byte at a time.
Implementing the C standard library’s printf(...) function to send text strings over UART
Using interrupts to receive data as it arrives.
Setting up a “ring buffer” to handle continuous data reception.

If any of that sounds interesting, keep reading! The target hardware will be either an STM32L432KC “Nucleo-32” board or an STM32F103C8 “pill” board; they cost around $11 or $2-5 respectively. The “Nucelo” boards are easier to use, because they include a debugger. If you use a “pill” board, you’ll also need an ST-LINK debugger and a USB / UART bridge such as a CP2102 board. And these examples are all available in a GitHub repository, if you just want a quick reference.