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.
Synchronous Communication
Synchronous communication makes the receiver’s job easier by adding a third clock line to the ground and signal lines. This is the clock the transmitter uses to shift out the bits. The receiver uses the clock to determine when to sample the value of the received bit.
There are other devices in addition to the USART on the Arduino, or other microprocessor chips, that use synchronous communications. Both I2C (Inter-Integrated Circuit) and SPI (Standard Peripheral Interface) are synchronous. I2C uses two lines for Serial Data Line (SDA) and Serial Clock Line (SCL). Each device on a bus is assigned an address and responds when the master sends that address over the SDA. Devices respond back on the SDA making this a half-duplex system.
SPI requires at least four lines: Serial Clock (SCK), Master Out / Slave In (MOSI), Master In / Slave Out (MISO), and Ground. This bus can also use a Slave Select (SS) line for each device. This adds complexity but allows SCK/MOSI/MISO to be attached to multiple slave devices — each will only “listen” when its SS line is active. The master activates the SS, transmits, and waits for the response.
In both I2C and SPI the master always generates the clock. It synchronizes the slave devices with the master. This is synchronous communication.
One issue with a synchronous system is the receiver expects to be receiving data if the clock is active. If the transmitting system needs to pause during a message, it needs to send idle characters, which the receiver discards, to hold the line active.
Asynchronous Communications
Asynchronous communication does not provide the clock signal. The transmitter’s job is the same, to shift the bits onto the wire at the agreed clock rate, but it needs to do more. With no clock, the receiver needs to know when to begin sampling for incoming bits. The transmitter helps by sending synchronization bits: a start bit and then one, one and a half, or two stop bits. There is also an optional parity bit to allow for error checking. For more on this, check out the serial troubleshooting techniques [Elliot Williams] wrote about earlier this week.
Since the transmit and receive clock rates are running independently they are not going to be in phase. Due to this the receiver might not sample the start bit until it is almost completed, throwing off the sampling for the remainder of the bits in the character. To avoid this the receive clock runs faster, sometimes 16 times faster, than the transmit clock to allow it to more accurately detect the falling edge of the start bit.
In a perfect world a USART’s receiver could determine the time for the middle of an input bit, read the signal level, and that would be the received bit. In the real world, it’s not so simple. The transmitter sends a nice square wave but as the signal propagates it decays. The nice sharp rise time becomes a slope, as does the falling edge. There also may be noise on the signal line lowering or raising the signal level. Here again, the receive clock is faster to take multiple readings and average them to determine the input bit.
Heritage: Break and Signal Levels
The telegraph and teletype systems influence serial communications even today. Today we consider a digital signal line’s default, or idle, condition if there is no voltage on it, implying its value is 0. The telegraph system considers an idle line to be high. With the signal line held high operators could detect physical breaks in the line because the signal dropped to zero. To send a message a telegraph operator moved a slide on the key to “break” the line. The slider was put back when the message was completed.
Teletype (TTY) systems continued both practices. A TTY keyboard has a break key that literally interrupts the high signal on the line and any messages being sent. The break key on your computer keypad is a legacy from broken lines on the telegraph systems. Since TTYs were used with early computers the break key was adopted as a means of interrupting runaway processes. A USART can be configured to set an error flag and generate an interrupt if it detects a break, i.e. a low signal for a character period.
The high idle signal level is the other legacy practice. An idle serial line is held high in contrast to most digital signals, which are held low. In legacy terms, a high signal line is a mark signal and a low signal line is a space. A 1 bit is sent as a mark and a 0 bit is sent as a space. This explains why the asynchronous start bit is a space to indicate the end of an idle line and why the stop bits are marks, returning the line to the high idle state.
A final legacy is ability to specify multiple stop bits. TTY mechanisms were not always fast enough to capture a character, print it, and prepare for the next character in the time provided by a single stop bit. The multiple stop bits provided a built in delay time for these mechanical devices to recover.
Errors and Flags
Errors always occur during serial communications due to noise, bad connections, and the whims of Murphy. The USART reports errors and its operating status in an appropriately named status register. It can also be configured to generate interrupts for errors and most status indicators.
One error is the framing error, often caused by transmit and receive clocks running at different speeds. Severe noise disrupting the start or stop bits can also cause this since it is triggered by a character not ending when expected. With the clocks being on two different systems they simply cannot be running at the same speed. If the transmit clock is sufficiently slower than the receive clock the stop bit will occur after that receiver expects. A faster transmit clock means the stop bit is there before the receiver expects which means the receiver sees the next start bit before it is ready. Clocks must be within 3.3%, based on Determining Clock Accuracy Requirements for UART Communications from Maxim Integrated.
Another error is the overrun. This occurs when the USART receives a new character before its system reads the previous character. To avoid this a modern USART will provide a character buffer to clear the way for the next character to be received by the input register. This double buffering provides time for the system to read the buffered character. Transmitters do the same, holding one in the buffer while another is transmitted. Some USARTs provide larger buffers. The 16550 USART available from multiple vendors and used in many PCs, provides a 16 byte buffer for both transmit and receive.
A few more errors and indicators are possible. There is the parity check error when the received character’s parity doesn’t match that calculated by the USART. The transmitter underrun status indicates the buffer and output register are empty. Also, both the transmitter and receiver provide a ready status when their buffers can accept or provide, respectively, a character.
Wrap Up
[Elliot’s] article What Could Go Wrong: Asynchronous Serial Edition digs into the details on connecting two Arduino’s using asynchronous communications. Who will be the first with a project on Hackaday.io that connects a couple of Arduinos using synchronous communications?
“One issue with a synchronous system is the receiver expects to be receiving data if the clock is active. If the transmitting system needs to pause during a message, it needs to send idle characters, which the receiver discards, to hold the line active.”
This makes absolutely no sense. You just said the master was the transmitting system. If the master needs to pause, it simply does not send clock pulses. If somehow you were referring to the slave as the “transmitting” system, timing constraints are generally given in the datasheet, putting the flow control basketball back in the master’s court.
Also, I2C can neatly avoid this problem when the slave is allowed to clock stretch.
Can you please reword this section to make it more coherent?
Also: Manchester encoding, where the data and clock signals are combined, so they can be sent over a single circuit. The clock and data are separated at the receiver. It requires no start/stop bits and is handled as a synchronous transmission, but it does require clock separation circuits at the receive end.
The key word here is “pause”. The transmitter is not ready to relinquish the line for the other system to transmit, e.g. a message is not complete. But for some reason the transmitter is not ready to send data so it has to hold the line in idle.
Only time you would do that is the master need to poll the slave data (i.e MISO), but doesn’t have anything worth while to send. So it sends a dummy byte. Stopping the SCK or deasserting the /SS would be the way to pause the transmission.
What goes “Pieces of seven, pieces of seven” ?
A parroty error……………….
Someone please explain again why we don’t have a “like” button.
because this is HACKADAY, and we aren’t neophyte newbies ?
2nd’d. Likes get lumped in with taking pictures of your dinner.
Oh, I see. It’s a fashion thing.
We are serious engineers
“The telegraph system considers an idle line to be high. With the signal line held high operators could detect physical breaks in the line because the signal dropped to zero. To send a message a telegraph operator moved a slide on the key to “break” the line. The slider was put back when the message was completed.”
Though Teletype was descended from telegraph, they work slightly differently.
They are both current loop systems. Think of the telegraph keys as switches, connected in series (you can have more than two telegraph stations on a circuit). For one key to be able to make and break the loop, all the other keys need to be in the “shorted” position. But a telegraph system uses an open loop as a normal state, closing the key completes the loop and causes current to flow through the sounder magnets (connected in series with the keys in the loop). So between characters sent by one station, the loop is open. Only when the station completes its transmission, does it return the loop to “closed idle” condition.
Teletypes, however, use current flowing as the idle condition and their transmitter switches are closed when they are idle. You can have many Teletypes in a circuit, just as you can have many telegraph stations in a circuit. Everything transmitted by one Teletype in a circuit will be echoed on all the others. This is also known as half-duplex mode, because what is transmitted matches what is received — the transmitter and receiver are connected in series, and are in series with the rest of machines in the circuit. The loop, however, remains closed whenever characters are not being transmitted. Pressing the BREAK key on a Teletype will manually open the loop and alert a transmitting station that another station wishes to interrupt.
Sorry but that is not what I’ve read: “The straight keys used in wire telegraphy also had a shorting bar that closed the electrical circuit when the operator was not actively sending messages. This was to complete the electrical path to the next station so that its sounder would operate, as in the operator receiving a message from the next town.”
https://en.wikipedia.org/wiki/Telegraph_key
An actual railroad telegrapher says: “On land-line telegraph you must always close the circuit with the shorting bar, otherwise no one can send anything if you leave it open.”
http://www.antiqueradiomuseum.org/telegraph.htm
I may put up a project “connecting” 2 arduinos with a rs232 data diode. It wont be synchonous though. Then one could at least send something to an infected pc with low risk of infection.
What?
I know lol. Its this (pdf warning): http://homepage.cs.uiowa.edu/~jones/voting/diode/RS232tech.pdf
I think its interesting, if it works. Lan taps like the throwing star from michael ossman are cool to me too. Im gonna be ordering parts soon and try it out. Im not gonna blabber on it til I build one and hopefully get it working. I think of it like a protocol hack.
“the venerable Intel 8251 “Programmable Communication Interface”, a UART,” The 8251 was a USART, the much more common 8250 (as found on the IBM PC) was a UART
UART — You art, the promised kiss of springtime … That trembles on the brink of a lovely song.
You would be hard pressed to convert USART into verse :).
Yew sarty blartfarst, thou spewest forth the finest babel fish oils.
“Synchronous” communications gets a lot more complicated very quickly. You can have a clock for each direction of data. And the clock can either be provided by the transmitter (“here is my data”) or by the receiver (“send me your next bit of data.”) And the clock might be provided continuously, in which case you also have to figure out how to distinguish actual data from “idle” (usually a higher-level protocol like HDLC or SDLC.) Add specs for how much the clock period can vary, which edges are relevant (and when), and on and on…
I don’t think that’s why the multiple stop bits are there. AFAIK the longer the stop bit, the easier it is to make the characters out individually. If you get a very noisy line with a high transmission rate (e.g. continous data) with 1-stop bits you could get framing errors for long time until you finally synchronize with a true start bit. With double or one and a half stop bits the possibility for a framing error is greately reduced.
My experience with synchronous transmission was with full-duplex modems connecting a mainframe or minicomputer to another computer. In that case the modems were connected by two twisted pairs — one for transmit and one for receive. The clock signal was derived by each receiving modem from the data.
In asynchronous transmission, individual bytes were sent enclosed in start (and parity?) and stop bits for each byte of data. Pausing between bytes was just extra stop bits and not a problem.
In synchronous transmission entire blocks were sent as a continuous steam of bits. There were no individual start, parity, or stop bits for each character. The block was preceded by one or more SYN characters (synchronous idle) to enable the modem to establish bit timing and synchronization and for the USART to establish byte synchronization (to find the start of a byte). Once you started a block, you had to continue sending characters until the end of the block, or you get a framing error, which just means that the USART lost synchronization. If you are not ready to send the next character of a block, you could insert SYN characters, which the receiving program could strip out.The block would be terminated by a terminating character and a checksum. If full 8-bit data was to be sent, various encoding techniques were used.
Depending upon the precise protocol, various characters might be used to start, separate, or end various components of a block. The following site lists various control codes that were used.
http://ascii.cl/control-characters.htm
For IBM mainframes using EBCDIC instead of ASCII the codes are different, but the idea is the same.
I am doing this mainly from memory, so I may have a detail or two incorrect or missing.
You trying to write my next article?
“Hello, this is the German Coastguard. What are you syncing about?”
The clarifying comments by James White are on point, and much appreciated.
A USART is not just a UART with external clocking (a point blurred over by the author’s discussion of bit clocking and clock recovery).
The familiar UART is simple: it implements asynchronous *character* transmission but with relatively high overhead as Start, Character, Parity, and Stop bits.
The USART (“S” for Synchronous) applies to synchronous *block-oriented* protocols such as BSC, HDLC, and SDLC. Hundreds (or thousands) of characters are aggregated into long blocks with only a few bytes of overhead bracketing the synchronous block.
A typical UART channel is a shift register and a holding register and clock and control logic. (Some also incorporate baud rate generators.)
The more complex USART chips incorporate the additional hardware features to support synchronous protocols such as frame synchronization, zero-insertion/deletion, and CRC (cyclic redundancy check).
Overall, I’d say this article needs a rewrite.
“This double buffering provides time for the system to read the buffered character.”
No, it’s not a double buffer. See https://en.wikipedia.org/wiki/Multiple_buffering#Double_buffering_in_computer_graphics