uart

67 Articles

Serially, Are You Syncing Or Asyncing?

June 28, 2016 by 25 Comments

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

June 22, 2016 by 50 Comments

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” →

Audio Out Over UART

April 11, 2016 by 40 Comments

There’s a reason that the bog-standard serial port will never die. It’s just so robust and simple. When you need a console that will absolutely work with minimal software and hardware, UART is the way to go. Because of this, UART hacks abound. Here’s a new one to us, and a challenge to our readers.

[Tiziano Bacocco] decided to use UART signals as a type of PWM to create audio. That’s right, he’s plugging the serial TX line straight into a speaker. This gives you eight possible PWM output voltage levels. The trick is using some Python code (using the awesome pyserial module) to down-quantize the audio data to fit these eight possible values and then push them out at the correct sampling rate. ffmpeg is used to pre-process the files.

Continue reading “Audio Out Over UART” →

Break Your Wrist? Twitter-Enable That Plaster Cast

December 31, 2015 by 1 Comment

Plaster casts are blank canvases for friends and family to post their get well messages. But if it’s holiday season, adding blinky LED lights to them is called for. When [Dr Lucy Rogers] hurt her hand, she put a twitter enabled LED Christmas tree on her cast.

The hardware is plain simple – some RGB LEDs, an Arduino, a blue tooth module and a battery. The LEDs and wires formed the tree, and all the parts were attached to the plaster cast using Velcro. This allowed the electronics to be removed during future X-ray scans. The fun part was in connecting the LEDs to the #CheerLights project. CheerLights is an “Internet of Things” project that allows people’s lights all across the world to synchronize to one color set by a Tweet. To program the Arduino, she used code written by [James Macfarlane] which allowed the LED color to be set to any Cheerlights color seen in blue tooth UART data.

Connectivity is coordinated using MQTT — lightweight standard popular with connected devices. By connecting the MQTT feed to the cheerlights topic from [Andy Stanford-Clark’s] MQTT feed (mqtt://iot.eclipse.org with the topic cheerlights) the lights respond to tweets (Tweet #cheerlights and a color). The LED colors can also be selected via the phone from the color picker tool in the controller, or directly via the UART. If the Bluetooth connection is lost, the LEDs change colors randomly. Obviously, delegates had great fun when she brought her Twitter enabled LED blinky lights plaster cast arm to a conference. It’s not as fun unless you share your accomplishments with others!

Arduino And IR Remote Turn Off Raspberry Pi

July 18, 2015 by 18 Comments

With all of the cool features on the Raspberry Pi, it is somewhat notable that it lacks a power button. In a simple setup, the only way to cut power to the tiny computer is to physically remove the power cord. [Dalton63841] found that this was below his wife’s tolerance level for electronics, and built a simple remote control for his Raspberry Pi.

[Dalton63841] started this project by trying to use the UART TX pin, but this turned out to be a dead-end. He decided instead to use an Arduino to monitor the 3.3V power rail on the Pi. When the Pi is shut down in software, the Arduino can sense that the Pi isn’t on any more and disconnect the power. The remote control is used to turn the Pi on. The Arduino reads the IR code from a remote and simply powers up the Pi. This is a very simple and elegant solution that requires absolutely no software to be installed on the Raspberry Pi.

We know that this isn’t the most technically complex project we’ve ever featured, but it is a good beginner project for anyone just getting started with a Pi, Arduino, or using IR. Plus, this could be the perfect thing to pair up with a battery-backup Raspberry Pi shutdown device that allows it to power itself down in a controlled way when a power outage is sensed.

Calibrating The MSP430 Digitally Controlled Oscillator

March 15, 2015 by 25 Comments

The MSP430 is a popular microcontroller, and on board is a neat little clock source, a digitally controlled oscillator, or DCO. This oscillator can be used for everything from setting baud rates for a UART or for setting the clock for a VGA output.

While the DCO is precise – once you set it, it’ll keep ticking off at the correct rate – it’s not accurate. Without a bit of code, it’s difficult to set the DCO to the rate you want, and the code to set that rate will be different between different chips.

When [Mike] tried to set up a UART between an MSP430 and a Bluetooth module, he ran into a problem. Setting the MSP to the correct baud rate was difficult. Luckily, there’s a way around that.

There’s an easy way to set the DCO on the MSP programatically; just set two timers – one that interrupts every 512 cycles, with its clock source set to the DCO, and another that interrupts every 32768 cycles that gets its clock from a 32.768kHz crystal. The first timer clicks off every second, and by multiplying the first timer by 512, the real speed of the DCO can be deduced.

After playing around with this technique and testing the same code on two different chips, [Mike] found there can be a difference of almost 1MHz between the DCOs from chip to chip. That’s something that would have been helpful to know when he was playing around with VGA on the ‘430. Back then he just used a crystal.

Easier UART To 1-Wire Interface

January 29, 2015 by 28 Comments

The 1-Wire protocol is usually found in temperature sensors, but you’ll also find it in chips ranging from load sensors, a battery sensor and LED driver that is oddly yet officially called a ‘gas gauge’, and iButtons. It’s a protocol that has its niche, and there are a few interesting application notes for implementing the 1-wire protocol with a UART. Application notes are best practices, but [rawe] has figured out an even easier way to do this.

The standard way of reading 1-Wire sensors with a UART is to plop a pair of transistors and resistors on the Tx and Rx lines of the UART and connect them to the… one… wire on the 1-Wire device. [rawe]’s simplification of this is to get rid of the transistors and just plop a single 1N4148 diode in there.

This would of course be useless without the software to communicate with 1-Wire devices, and [rawe] has you covered there, too. There’s a small little command line tool that will talk to the usual 1-Wire temperature sensors. Both the circuit and the tool work with the most common USB to UART adapters.