The Bits Go Marching One by One

In this week's FANTM Microupdate we'll be exploring one way that data can flow from one computer to another. When we need to communicate between devices, both need to be on the same page about how they're going to be talking. Think of this like languages that people speak: someone speaking English to someone who only speaks Spanish will not be able to communicate, and all of the information will be lost. Computers need to speak the same language to each other as well, and these languages can be primarily classified in two ways, serial and parallel. Serial is when we send each bit (the one's and zero's that make up how computers understand everything) one after another down a single wire, and parallel is when each bit is sent simultaneously across many wires. Serial communication is generally simpler and requires less hardware, so FANTM usually uses serial protocols. When we're pulling data from an Arduino with the DEVLPR shield, that data is being sent using either UART (Universal Asynchronous Receiver-Transmitter) or USART (Universal Synchronous-Asynchronous Receiver-Transmitter). We'll focus on UART because it's simpler than USART, has a lot of overlapping functionality, and this author has worked with it more.

So what is UART? It fundamentally refers to a computer chip that converts data into a standard UART format other computers can read with their UART chips. It is the translator that turns English into Spanish and vice versa. However, it's more helpful to think of what it's doing to the data itself because the patterns can help shine light on other forms of digital communication. For starters, and unlike human languages, most messaging protocols, like UART, rely on both parties agreeing on how fast they want to send data and that's represented by a "baud rate" or the number of bits per second. Once there is an established speed, both sides need to agree on how the bits should be arranged. Each packet, or chunk, of data in UART is prefixed by a single "0" bit that tell the other side something is on its way, followed by a data frame of 5 to 9 bits of data, and concluded by a "1" bit indicating things are finished. One common twist on this is the concept of parity, or more simply even and odd numbers. Often times one bit in the packet is turned into a "parity bit" to indicate whether there is an even or odd number of "1s" in the packet. This becomes useful when the receiver gets the packet and confirms that the number of "1s" matches what the parity bit thinks it should be and thus can recognize corrupted data.

There are advantages and disadvantages to using UART for communication. The first big benefit is that it only needs two wires if their ground connection is shared (and three if it's not). Our metaphor is a little imperfect here, but you can think of this like needing a single translator whereas many other communication systems require two or more. Another great advantage is that is that it's flexible: if both devices want to do something a certain way, they can as long as they agree because UART is just the hardware providing communication capabilities. A disadvantage is that it's only one-to-one, so if five devices need to talk to each other they all need to be connected separately, and to continue to beat the metaphor to death this effectively means you need a translator for every pair of people communicating.

Those are the basics of UART communication. It can be a little confusing, but if you have any questions or would like further clarification please don't be a stranger and leave a comment below. There are a ton of different protocols out there, each with useful properties, but most of them are variations on the same idea: set a common speed, organize data, and catch errors. On your FANTM DEVLPR you can see UART happening when you send data through your USB cable for libdevlpr to graph on the Arduino IDE, or the devlpr daemon to move into a python environment. Thanks for reading and we're going to be on hiatus until August 27th, so check back then! 💪🤖