Serially, Are You Syncing or Asyncing?

I know you’ve heard of both synchronous and asynchronous communications. But do you really know the differences between the two?

Serial communication was used long before computers existed. A predecessor is the telegraph system using Morse Code, one of the first digital modes of communication. Another predecessor is the teletype, which set standards that are still used today in your Arduino or Raspberry Pi.

All you need is two wires for serial communications, which makes it simple and relatively robust. One wire is ground and the other the signal. By interrupting the power with predefined patterns, information can be transferred over both short and long distances. The challenge is receiving the patterns correctly and quickly enough to be useful.

I was a bit surprised to find out the serial port on the Arduino Uno’s ATmega328P microcontroller is a Universal Synchronous Asynchronous Transmitter Receiver (USART). I’d assumed it was only a UART (same name, just leave out synchronous) probably because my first work with serial communications was with the venerable Intel 8251 “Programmable Communication Interface”, a UART, and I didn’t expect the microcontroller to be more advanced. Silly me. Later I worked with the Zilog 8530 Serial Controller Chip, a USART, the term I’ll use for both device types.

All these devices function in the same way. You send a byte by loading it into a register and it is shifted out one bit at a time on the transmit (TX) line as pulses. The receiver accepts the pulses on a receive (RX) input and shifts them into a register, which is then read by the system. The transmitter’s job is pretty easy it just shifts out the bits at a known clock rate. The receiver’s task is more complex because it needs to know when to sample the incoming signal. How it does this is the difference between asynchronous and synchronous communications.

Continue reading “Serially, Are You Syncing or Asyncing?”

What Could Go Wrong: Asynchronous Serial Edition

It’s the easiest thing in the world — simple, straightforward serial data. It’s the fallback communication protocol for nearly every embedded system out there, and so it’s one that you really want to work when the chips are down. And yet! When you need it most, you may discover that even asynchronous serial can cost you a few hours of debugging time and add a few gray hairs to your scalp.

In this article, I’m going to cover most (all?) of the things that can go wrong with asynchronous serial protocols, and how to diagnose and debug this most useful of data transfer methods. The goal is to make you aware enough of what can go wrong that when it does, you’ll troubleshoot it systematically in a few minutes instead of wasting a few hours.

Continue reading “What Could Go Wrong: Asynchronous Serial Edition”

Receiving asynchronous data bursts

[Johan’s] been working on a chunk of code for about seven years and he thinks it’s ready to help you with your next project. He calls it D1 (The One) and it lets you receive asynchronous data without the need for a hardware USART. It’s capable of working with signals from an IR or RF remote, as well as tangentially related transmissions like RFID and magstripe readers.

It uses timer and port interrupts to sample the incoming data. Once it’s captured a transmission, the code sets a flag so that you can pull what it got into your own application. If you’re expecting to receive a protocol that sends packets several times in a row a verification module is also included which runs as a precondition of setting the received flag. The package is written in PIC assembly, but with all the information that [Johan] included in his post this shouldn’t be hard to port over to other chip architecture.