In this chapter, we will open our embedded board up to exchange information with the outside world.  Up until now, the only link that we have used is the built-in USB programming interface on the Wonder Gecko Starter Kit and some GPIO lines for controlling a few discrete components. Now we will share data across a communication protocol.

Our EFM32 has quite a few built-in communication standards.  It is quite the Swiss army knife.  We will begin learning about the simplest of these interfaces in this chapter before learning about more in upcoming chapters.  You can use these communication protocols to enrich your project by connecting multiple smart devices together and share information.  The IoT is all about connected devices, and this is where it begins.

First, we will cover the basics of serial communication protocols, terminal emulator programs, UARTs, USARTs, and serial cables.  Then we configure the chip for USART communication using the Simplicity Studio Configurator tool, that takes care to make all of the connections and communication settings for the USART, through the GPIO block and to the outside world.  We will build an interrupt handler to let us know when there is data received on the serial interface and see what signals look like on an oscilloscope, to make sure that things are really toggling like we expect.  Finally, we will construct a print function so that we can use this newly acquired connection to aid in our debugging process.

Materials Needed for This Lesson

• CP2104-MINIEK USB-to-Serial Port adapter
• Hook up wire
• Terminal emulator software and a computer

Communication Classes

Communication is achieved between devices via three classes of communication methods:

• Parallel
• Synchronous Serial
• Asynchronous Serial

The parallel communication method is generally the fastest class.  In a future lesson, you will learn about parallel communication in order to transfer large amounts of data quickly to graphical displays.  When your peripheral is on the same PCB board as the MCU, a parallel interface makes a lot of sense if fast speeds are needed and pins are available.  But when your embedded system needs to communicate with other external devices, all of those conductors create complicated connectors and bulky, expensive cabling.  In the early days of the PC, all computers had a parallel port that allowed transferring large amounts of data form the PC to a peripheral, normally a printer.  The cables were never cheap or light..

A serial communication method forces the transmitted data to march in a single-file line, as all of the data flows bit-by-bit one after another.  This is generally a slower form of communication but requires fewer wires between devices.  This type of communication can be transmitted in a synchronous mode, which means that there is a clock line to coordinate the bits at the other end, or without a clock, which is an asynchronous mode. I will be using and explaining asynchronous mode in this lesson.

The large majority of your embedded system operates in a synchronous mode.  Nothing ever happens if the clock doesn’t toggle.  Therefore, the devices that utilize asynchronous signals must be able to bridge the gap between clocked and clock-less domains.  This presents some challenges in finding proper clock sources. 

The standard that is most often used for asynchronous serial communication is the RS-232 standard, which is based upon the UART communication protocol.  More on this later.  This standard describes how devices asynchronously communicate information, including the voltages and optional flow control siganals.  It is not required to make use of this particular standard, but it is most common and the one that we will be using for this lesson.  However, just because there is a standard doesn’t mean that all systems will work well together.  The standard doesn’t specify how software should deal with the data that is transferred.  In addition, the RS-232 interface specifies a +5V and -5V as part of the electrical signaling and we will not be implementing that part, as both the EFM32 MCU and the USB-to-serial port adapter don’t use these voltages, but instead use 3.3V and 0V as the logic 1 and logic 0 values.  RS-232 also adds optional flow control signals such as the Request To Send (RTS), Clear To Send (CTS), to manage the bidirectional transmission of data between two systems, usually modems, and we don’t need all of that extra signals.  So what I am referring to as RS-232 here is really just the packet format and not much more.  This happens a lot in technology.  It’s hard to keep track of all of the nuances between different specs and even different versions of specs.  The people who make the components get confused at times too.  That’s why it’s so hard to get things to work together sometimes!

Serial Interfaces and Terminal Emulator Programs

In 80’s and 90’s, all computers shipped with a serial port that had a ridiculously large DB9 connector, by today’s standards, and implemented the full RS-232 standard.  Sometimes it was necessary to enter into the computer’s BIOS setup utility and turn them on, or assign them to a different address range or IRQ lines to not conflict with your groovy new drawing pad or speech synthesizer.  Those were the days. 

Today, you will most likely need a USB-to-serial adapter to access this old interface.  You can use a breadboard-friendly CP2104-MINIEK breakout board for this task.  The drivers are available on the Silicon Labs website so that your computer will detect this breakout board.

USB has supplanted RS-232 to be used for most peripheral needs, and wireless links are replacing those.  But, the lowly serial port is still used wherever a design calls for a cheap and easy way to get some rudimentary console-based access to a host system.  Embedded designers routinely choose serial ports for diagnostics and debug of heavyweight computers that otherwise have multi-GB interfaces.  When those beasts fail to boot up properly, the serial port can be the salvation to figure out what went wrong.

Often, the data that is transmitted via an serial interface is ASCII text for human consumption or as commands to be sent to a device.  ASCII stands for American Standard Code for Information Interchange and is the binary code behind all of the text that makes up the alphabet, punctuation characters, and other miscellaneous characters.  But it is also possible to transfer information data over a serial interface in a pure binary format in order to program a part with new machine instructions, for example.  To interface with the serial port on your computer, you will need to find a suitable terminal emulator program.

A computer terminal was widely used in the days before PC’s as the primary human interface to mainframe computers.  It had a keyboard, a display screen and just enough smarts to send and receive RS-232 data.  Today, since our computers are so much more capable than just displaying text and accepting keystrokes, you can download a program that emulates a terminal in a window on your computer.  This terminal will be the portal in which you will communicate with your embedded device.

Windows users of any recent installation need to turn to external software to be able to access the serial port.  Putty and TeraTerm are two of my favorite free terminal emulators.  Download and install one of those now. 

Note that Linux and Mac computers have a built-in terminal and a built-in serial port device at /dev/ttyX, in which X is the identifier of the serial port.  Serial input and output can be routed to the built-in terminal with just a simple command like:

 screen /dev/ttyUSB0 115200

where ttyUSB0 is wherever your USB-to-serial port adapter is located, and 115200 is the baud rate, described below.

Configure the following parameters in your chosen terminal emulator:

• Baud Rate – The speed at which the serial port will transfer data. Default is 9600 baud, which means that electrical signals will wiggle high and low up to 9600 times per second
• Data Bits – The number bits that make up a single packet on the interface. Default is 8 bits.
• Parity – Whether or not to use make use of a parity bit, which offers some rudimentary error checking. Default is off.
• Stop Bits – How many transitions at the end of the data packet indicate the end of the data packet. Default is one bit.

The most customary settings going back decades for all of these settings is known 9600 8N1.  This means 9600 baud, 8 data bits, no parity, and 1 stop bit.  I will actually be using a faster baud of 115200, which is a more modern standard speed.  In fact, most implementations can now support non-standard speeds like 115201, etc. 

Once you have a serial port adapter connected to your computer and a terminal emulator program up and running, it is time to put them to use and communicate with your MCU on the Starter Kit.

USART Peripheral

There is a very powerful Swiss army knife of a peripheral on the EFM32 MCU called a Universal Synchronous Asynchronous Receiver Transmitter (USART).  Aren’t you glad that I explained what those big words meant beforehand?  What that basically means is that the USART can universally handle just about any kind of serial transfer, whether that be synchronous or asynchronous, and it can receive as well as transmit.  The MCU USART hardware, as well the software libraries that are built on top of that hardware, are at your disposal to automate a lot of the data transmission process, allowing your software to do other things and make the programming easier.

You don’t need a USART to make this happen at slower speeds of 9600 baud or so.  The serial interface is still around because it one of the simplest of communication protocols and can be designed completely in software in today’s modern embedded systems.  However, your resources are always limited, and it still takes some CPU time and energy to toggle GPIO pins to emulate a serial link in software.  It is better to use a USART if you have it and allows for much higher speeds like 115200 baud.

We will configure USART instance 0 through the use of the Configurator tool in Simplicity Studio in the next section.

PREVIOUS | NEXT