Off-The-Shelf Hacker: Comms across Microcontrollers
To date, we haven’t spent much time talking about “inter-device” communications here at the Off-The-Shelf Hacker column.
By inter-device, I mean making microcontrollers talk to each other, as well as to nano-Linux systems. An example might be using an Arduino for some analog inputs, then sending the data to a Raspberry Pi for analysis. Arduinos are real-time and handle analog input just fine. The Pi can’t read analog inputs at all, although it certainly can crunch the data then display it on a Web page and send it up to the Cloud. If you put the two together, you can come up with some pretty interesting and complex projects that just can’t be accomplished with a simple, single microcontroller approach.
Today we’ll cover the three main machine-to-machine interfaces that might be used in off-the-shelf hacker projects, look at their behaviors and investigate how they might be used in the real-world. I’ll gloss over most of the geek-centric details, because you don’t really need to know the nitty-gritty deep-tech stuff to use the interfaces in off-the-shelf hacker projects. Most of the operational details are abstracted away through software libraries anyway. Future articles will delve into important physical aspects you should know about, common practical applications and tips/tricks for your own projects.
We’ll also focus on “serial” communication methods, as opposed to parallel. Serial means sending sequences of bits out over a wire and possibly receiving bits back over the same or a second wire. Parallel sends bits over sets of several wires simultaneously, in bursts. Almost all communication between microcontrollers and connected devices are serial anyway, so that’s what we’ll cover.
Traditional “Serial”
You’re probably already familiar with traditional “serial” communication between microcontrollers. For example, a USB cable is used between a Linux notebook and an Arduino to allow firmware uploading and data monitoring functions with the Arduino IDE. You usually only hook two devices together at a time.
The USB connection between an Arduino and a notebook is a serial connection. Looking at the electrical connections, operationally and programmatically, the USB on a notebook and the TX/RX pins on an Arduino are interchangeable as far as getting data from one machine to the other are concerned. Be sure to examine “communication” examples in the Arduino IDE. You might want to expand your knowledge of “serial communication” in your language of choice, as well. Here are several useful links:
Software Serial Example from Arduino.
Serial Processing from Processing.org.
Documentation for the Python pySerial library.
Traditional serial is used for moderately high-speed, wired data transfer. Since it is available on virtually all microcontrollers, using it for low-bandwidth jobs, like just sending a few characters back and forth, is cheap, easy and very common, as well. Examples include transferring sensor, firmware and possibly audio data between an Arduino and a notebook computer. You might also use it to connect a Raspberry Pi and a CHIP computer together. Or, wire one Raspberry Pi to another. It can handle video data, as well.
It typically uses two wires, plus a ground, for data transfer.
Serial Peripheral Interface
The serial peripheral interface (SPI) is used for short-distance, high-speed wired communications, usually between microcontrollers and peripheral devices. Examples include sending and receiving data with SD cards and LCD displays.
My Steampunk Conference Badges, incorporate SPI communication for both Arduino Pro Mini and the Raspberry Pi model 2 versions.
My badges use the 1.8” color TFT LCD displays from Adafruit. SPI is the preferred communications method in this case because it’s designed for fast data transfer jobs. I show full-motion, color MP3 videos on my Dr. Torq badge without any pixelization, image tearing or lag from a regular old Raspberry Pi model 2. The display is equally fast when connected to an Arduino. Of course, we’re limited to text and firmware-generated shapes and animation when hooked to an Arduino-based microcontroller.
SPI uses two wires for the serial data, one wire for device selection and one wire for clock synchronization, plus the ground wire. There is only one master per bus setup. Each slave device requires it’s own wire for device selection. The number of wires multiplies quickly as you add slaves, which is one of its shortcomings.
Inter-IC
Inter-IC (I2C) handles fairly low-speed data (up to 400Khz) using a simple two-wire bus arrangement to facilitate communication between chips and devices. It was created by Phillips over 20 years ago and is very common in the current microcontroller ecosystem. Its major strength is that it typically allows one master node and multiple slave nodes (up to 120) to communicate over its two wire bus (plus ground). One shortcoming is that high impedance limits the physical bus length to only a few feet. Nevertheless, it’s a good choice when you have a bunch of devices, connected to your microcontroller module. Another great feature is that the microcontroller can address each device, individually, as needed.
I currently don’t have any I2C projects on the old workbench. Adafruit has a little tutorial on setting up the I2C bus, with a Raspberry Pi, that might be helpful to your understanding. The page also has links to several example projects, you can build.
I’ll pick out a few I2C devices and put them on my Christmas list. Feel free to mention it to Santa when you see him. I’ve been a good little hacker this year.
Summary
People still ask me the question, “Which microcontroller should I use?” It depends.
The same is true for making devices talk to each other in your projects. Perhaps, your project requires that a CHIP to talk to a Raspberry Pi. Traditional serial communication might be appropriate. Maybe you have a color LCD display hooked up to your Arduino. The SPI method is your weapon of choice. Finally, you might have a dozen devices that need to send data to/from your Beaglebone Black board. Use I2C.
Like any other engineering solution, each communication methodology addresses specific functions and requirements of a project. Some methods work for one situation but not others. As usual, engineering the physical computing stack always has compromises.
Hopefully, you now have a little better understanding of your choices.
Feature image: Wikipedia.
