All You Want to do is Talk, Talk
Microcontrollers are designed to talk. They want to
talk serial, they want to talk I2C, and they want to talk TWI
and SPI. Sometimes they can talk fast, and sometimes they
need to talk slow. Some of them can even speak CAN,
USB, and Ethernet. But they all want to talk!
Many microcontroller projects need to communicate
with modules, other microcontrollers, or the outside
world. The way they do this is using the protocols I
mentioned in the previous paragraph. Whether you’re
building a weather station, a home automation system, a
remote temperature sensor, or even a simple clock, you
will need to use one or more of these protocols.
This month, we’ll be covering one of the older and
more common serial modes: UART (universal
asynchronous receiver/transmitter). If you’ve been around
for as long as I have, you’ll remember the days before PCs
had USB ports, and most communication took place
through an RS-232 serial port — modems, tape drives,
joysticks, mice, and even PC-to-PC communications. When
we talk “serial” in this article, we’re kind of talking about
that serial (although technically, what we’re working with
isn’t identical — but that’s a discussion for another time).
There are other serial modes that are extremely useful
(critical, even) to building more complex microcontroller
projects. These include SPI and I2C, and will be covered in
Where and When?
Just why is serial communication so useful and worth
having an entire article dedicated to it? Personally, I rely
on serial in three main areas in my projects — but these
are by no means the only or best ways to use serial.
Stamping Out the Bugs
If you’ve been using an Arduino board for any length
of time, I’m certain that you’ve used the serial library to
help with debugging your sketches. Programming a
microcontroller is quite different to programming a PC, in
that the compiled file is uploaded to a remote MCU. This
makes it more difficult to debug, as the code is running on
a separate piece of hardware to your IDE (integrated
development enviroment). Thankfully, there are debuggers
available that allow you to step through your code on your
microcontroller, but these don’t work in all IDEs. In my
Arduino days, I relied a great deal on the
function to help me troubleshoot my code by sending
messages to my PC at select points in the program. As I
was learning, I bumped my head many times and
Serial.print() helped to slow the graying of my hair by
speeding up my troubleshooting process!
Even though I now have a debugger that works with
my IDE (debuggers aren’t, by the way, supported by the
Arduino IDE), I still sometimes fall back on the serial port
to trace execution of longer programs or of events that
happen less frequently.
Sometimes you want to be able to log or stream data
from your microcontroller project for later analysis. For
example, I’m currently working on building a reflow oven,
and I want to be able to record and graph the
temperature profile of my oven on my PC. As serial
communication is so ubiquitous, it is incredibly easy to
record incoming data on your PC. For one-off analysis, a
simple terminal program will do the trick; copied and
pasted into a spreadsheet. In the case of my reflow oven, I
wrote a short program in Python that collected and
graphed the temperatures.
Some really impressive front-ends have been written in
a range of languages — Python, Processing, C, and Visual
Basic are among the more popular.
56 June 2015
Talking to Your AVR Microcontroller
This week, we’re going to touch on
one of the older more reliable ways
to talk to your microcontroller
project: using serial communication.
You’ve likely used this with your
Arduino board, so let’s dive into
using it with the microcontroller