Summary
This document is a
non-technical survey of communication standards that have, or may have, some
usefulness for embedded applications. It contains a brief description of
each standard, but focuses on the comparative advantages and especially the
disadvantages of each.
The Electronic Industries
Association formerly released all of its specifications as RS (Recommended
Standard) plus a number. More recently, the EIA changed its name to the
Electronic Industries Alliance, joined forces with several other single
industry standards organizations, and changed its standards designations to
EIA- plus a number.
EIA 232
The original RS 232
specification described how to connect a mechanical Teletype machine to a dumb
modem. For all other applications, the engineer was left to his own
imagination. Engineers responded with great imagination, and eventually
entire books were written on connecting machine A to machine B.
For many years, EIA 232
was available on every desktop computer, but this is no longer true.
Apple Macs don’t have any EIA 232 ports. Home and home office machines
from Dell and HP don’t include serial ports, although their larger
(“professional”) machines still do. These ports are being replaced by
USB, but EIA232 is still the fastest path to a solution for point-to-point
short-range communication, if only because every embedded programmer already
has a filing cabinet drawer stuffed with routines written years ago.
EIA 232 is specified for
data rates to 20K bps at distances up to 50 feet, or 2500 pF. What the
heck is that equal to? For telephone grade wire, which is 24 gauge solid
unshielded twisted pair (UTP) with PVC insulation, it works out to about 100
feet. For Cat 5 UTP, which is only about 15 pF per foot, it is about 160
feet. These distances are for the maximum bit rate. Texas Instruments
ran some tests years ago that showed that at 9600 bps EIA 232 would work
perfectly well with 500 feet of cable.
The required hardware can
be cheap, if the board already has +12V and –12V digital power available.
Otherwise, the required DC-DC converter requires several capacitors, and the
cost and board space can become a consideration.
The primary drawbacks to
EIA 232 are that it connects only two points, the data rate is not up to
modern requirements, there is no standard communication format, and there is
very little noise immunity.
EIA 561
EIA 561 is the same as EIA
232, except that it uses modular (telephone) connectors.
EIA 422
EIA 422 was originally designed as an RS
232 “extension cord”. It uses differential signaling, so it isn’t plug
and play but it can handle data rates to 100Kbps and 4000 feet of cable.
EIA 422 also specifies a party line mode with one transmitter and up to 10
receivers. There are some very non-standard dual half duplex concoctions
that allow bi-directional communication after a fashion, but EIA 422 is not
true multi-point. These set-ups offer no advantage over EIA 485.
EIA 485
EIA 485 was the first high
speed, long distance fully bi-directional communication specification.
It is still the only EIA hard wired (that is, non-RF) communication standard
that allows multiple transmitters and receivers in a bus configuration.
A configuration can get by with a single two wire twisted pair if half duplex
is sufficient, while two, two-wire twisted pairs will provide full duplex.
Half duplex is very easy
to hook up, although, since the standard connector is a DB9, there are still
several opportunities to get it wrong. Since EIA 485 is differential, it
is very reliable, especially in noisy environments. The required
hardware is low cost, about mid-way between EIA232 and CAN bus.
The specification allows
for up to 32 “unit loads”. But not all transceivers are unit loads. The
more recent designs are ¼ or even 1/8 unit load and so a network can have up
to 128 or 256 devices respectively.
The specification allows
data rates up to 10 Mbps and cable length to 4000 feet. “Short” cables
don’t require termination, but termination is required for longer cables.
A short cable is defined as one where the rise time of the signal is at least
four times the propagation delay through the entire cable. There are two
ways to terminate the cable correctly. One is to put a 120-ohm resistor
across the inputs to the units at both ends of the cable. The other way
uses that resistor, plus “fail safe” resistors to power and ground, also at
both ends. The fail-safe resistors force the inputs to a known state
even when the cable fails or falls off. However, the termination and
fail-safe resistors greatly increase the power required. One way to
reduce the power is to use zener diodes instead of resistors for the
termination. They are much more expensive, but draw no power at all
unless there is an over- or under-voltage condition.
One of the drawbacks to EIA 485 is the
output structure is optimized for high-speed. A side effect of this is
that both transistors are on simultaneously during every output transition.
This “feature” enables high-speed operation, but draws enormous amounts of
power; in fact, for CMOS transceivers about 99% of the total power drawn
during normal operation is used during this transition. It also injects
noise into the output signal, which can be very hard to get rid of.
There are several ways to help cut the fat out of this power budget. One
is to send fewer, longer messages. This reduces the number of overhead
bits sent, which in some formats is considerable. Another tactic is to
disable the transceiver in idle mode. This works best when used with
transceivers that wake up and connect automatically when a message is
detected. Active termination? REVISIT THIS LATER.
EIA 644
High data rates, low
power, low noise differential signaling
800 Mbps at up to 30 feet
or so
Many uses in PC
backplanes, 3G base stations and video
CAN
CAN was originally
developed as the Car Area Network by Bosch for automotive engine controller
applications. As such, it is extremely reliable in noisy environments,
very low cost, widely available, and has lots of development support.
Renamed the Controller Area Network, it has found wide acceptance in many
stationary applications including vending machines. Consistent with its
automotive heritage and widespread use in vehicles, CAN is the lowest cost
communication protocol. It is an excellent choice for large networks of
hard-wired controllers that need to exchange medium quantities of data at
medium rates
CAN is fully differential
and has built-in CRC and automatic message resend if necessary. The CAN
controller handles all error detection and message retransmission; the
designer does not have to even think about them. However, this does mean
that message timing can be described as elastic at best. Messages will
eventually get through, but priority must be planned carefully in advance.
All messages are broadcast to all nodes. Every message is accepted
either by every node or by no nodes. In the latter case, it will be
retransmitted automatically. Although a node receives every message, it
only acts on some as described below.
CAN was specifically
designed for reliable communication in difficult circumstances. All
random errors of up to 5 bits per message are detected. All burst errors
of up to 15 bits are detected. All errors of any odd number of bits are
detected. The odds of an undetected corrupted message are less than
4.7X10-11. Detected corrupted messages are automatically
resent
A message can be acted
upon by one, several or all other nodes. Nodes don’t have addresses, so
a node can be added or subtracted at any time. Nodes act upon messages
based on message acceptance filters. This means that one message can be
accepted and acted upon by multiple nodes and that any one node can accept and
act upon multiple message identifiers.
Message identifiers are
always either 11 bits (“Standard format”) or 29 bits (“Extended format”).
Messages may have zero to
64 bits of data. Zero length messages can use the identifier to send
simple commands such as a command to turn a particular control on or off.
Every node can transmit
data whenever the bus is idle. Arbitration is handled bit by bit.
Every node that is transmitting is also monitoring the bus. When the
level on the bus doesn’t match the level that the node is transmitting, then
that node has lost arbitration and immediately stops transmitting. It
will automatically retry when the bus goes idle.
USB
USB was designed to simplify the
connections between a host PC and up to 127 associated peripherals. In
particular, it was intended to open up the PC to peripherals that didn’t exist
at the time that the USB bus was created. It is designed to be low cost
and very easy for the average end user to connect and use.
Unfortunately, none of the readers of this document are likely to qualify as
average end users, and USB has significant drawbacks for engineers and
programmers.
There are three
transmission standards under the USB label.
The first is Low Speed.
It is designed for human interface devices (HID) with short, infrequent
messages. Example devices are keyboards, mice, and monitor configuration
applications. Data rates are limited to 10 to 100 Kbps and messages are
limited to 8 bytes or fewer. The specification states that devices in this
class are limited to one 8-byte message every 10 ms, although Win98 doesn’t
enforce this limit.
The second is Full Speed
or Medium Speed. It is designed to take over audio and telephone
applications and can run at 500 Kbps to 10 Mbps Maximum data payload is 8, 16
32 or 64 bytes per message. Full Speed guarantees message latency and
bandwidth.
The last is High Speed,
which is designed for video and disk applications. It can run at 25 to
500 Mbps. It also guarantees latency and high bandwidth.
USB uses differential
signaling and connectors that at first glance resemble each other, but there
are really two different connectors. All “downstream” connectors are
alike. All “upstream” connectors are alike, but are different from, and
not interchangeable with downstream connectors. Downstream connectors are the
squarish ones, while upstream connectors are flat rectangles. The
connectors can also distribute power to downstream devices. Power is
limited to 5V (at the source) and at least 500 mA but no more than 5A.
Devices taking power from the bus can’t count on any more than 4.4V.
The host is always totally
in charge of the communication link. When a device is connected, the
host tells it to reset, and then the host assigns a unique address to the new
device and configures it.
Error handling consists of
CRCs and up to three retries before the host controller informs the client of
a problem. Other error recovery is up to the client program, but USB is
not intended for noisy applications. In particular, the CRC used is the
IBM EBCDIC generator polynomial, (x16 + X15 + X2
+1) which will detect all single and double bit errors. It is not
intended to be as bulletproof as the patterns used by CAN.
The primary disadvantage
of USB is that there is no such thing as a generic interface, and no
equivalent to a terminal emulator. Every application needs a custom PC
program. Also, for low speed interfaces (the only practical kind for
microcontrollers like the 68HC908 and others of that class) the message
structure is limited to 8 bytes at ten millisecond intervals.
The primary advantage of
USB is that it is now found on every new PC, both desktop and laptop.
Bluetooth (802.15)
Bluetooth is primarily
intended for short-range cable replacement applications. Products
available now include wireless mice, keyboards, headphones, wireless hands
free cell phones and RS232 cable replacement. Bluetooth features cheap
hardware, at least in comparison to other RF solutions, but certification
costs offset this in low volumes. Bluetooth must co-exist with many
competing transmitters in the same band including microwave ovens, portable
phones, garage door openers and many other radio services including Wi-Fi and
ZigBee.
A Bluetooth connection is
designed for either point to point with exactly two ends (called unicasting),
or a point to multipoint configuration (multicasting). This second
mode has one master and up to seven slaves arranged in what the standard calls
a piconet. For both types of links, the master always initiates every
message exchange. The slaves never communicate with any other slave, and
never initiate communication with the master. A device may be part of
more than one piconet at the same time, and may be a slave in one and a master
in another. One device may never be the master in more than one piconet
at a time. This is because the piconet is synchronized to the master’s
clock.
All Bluetooth links must
one of the predefined protocols. There are more than two-dozen, covering
every application from headphones to FAX, but only a few are of any interest
for embedded applications. These are the Serial Port Profile (SPP) at
the “higher” level, and some lower level protocols including RFCOMM, Link
Access Protocol (LAP), Link Manager Protocol, (LMP), and the Logical Link
Control and Adaptation Protocol (L2CAP). The Serial Port Profile is
specifically intended to replace RS232 cables, and so many Bluetooth features
are optional. This includes authentication, encryption, authorization,
and bonding. RFCOMM is used as the transport protocol for the Serial
Port Profile.
There are a very few
commercially available, off the shelf, fully certified products to connect two
BT equipped products together in SPP. This is the simplest, cheapest (in
low volume) and fastest to implement solution, and should be used whenever
possible. Up to eight devices can be connected together by using the
RFCOMM and lower protocols directly. This method is significantly more
complex, even for exactly two devices.
Bluetooth is advertised as
being capable of 700 kbps and up to 300 meters. Naturally, this doesn’t
mean at the same time; tests show that at 9600 baud, the range is a bit less
than 10 meters. The Serial Port Profile ensures data rates up to 128 K bps.
Support for higher rates is optional. Bluetooth also inherently adds a
time delay to all data, although for a message stream this delay is more or
less constant. This delay is not defined in the specification.
Tests on one system showed that message exchanges that took 60 ms on a wired
connection took from 120 ms to over 200 ms on Bluetooth. This can be
much longer (several to many seconds) in a noisy environment, or at large
distances (> 20 feet or so) between receiver and transmitter.
Bluetooth is not
particularly low power, and the highest power mode is when a device is
searching for another device. An attempt has been made to reduce power
by defining a variety of times when the device is not available, presumably
for transmit power off rest modes. These modes are park, hold, and
sniff. Park and hold use less power than sniff, but neither mode allows
data to be transferred. Sniff mode does allow at least some data
exchange.
A significant difference
between Bluetooth and a wired cable is the reliability of the received data.
Bluetooth uses several types of error correction at each level including
Forward Error Correction (FEC), Header Error Correction (HEC), CRC, and
multiple rebroadcasts. Despite that, the specification doesn’t offer any
hard numbers about error rates that can be expected. In fact, the
specification makes it clear that in a poor RF environment, Bluetooth should
be considered inherently unreliable. Anecdotal reports are that the user
won’t see bad data, but for virtually all of the intended applications
(headphones, etc), the odd dropped bit won’t be noticed. If data
integrity is paramount, the application needs to be able to guarantee the data
itself, without relying on Bluetooth.
The biggest disadvantage
to Bluetooth is its complexity. The objective is to replace any data
cable, from mice to streaming video. Consequently, the basic
specification is 1200 pages, which does not include any of the transmission
protocols. A result of this, and the second biggest disadvantage is the
expensive and time-consuming certification process. $10,000 seems to be
pretty typical, and several times that is common. A product must be
certified to display the Bluetooth logo.
ZigBee (based on 802.15.4)
IEEE 802.15.4 is an as yet
unreleased document that describes the two lower layers of a communication
standard. As usual, these are the physical layer and the media access
control layer. The ZigBee Alliance is building the upper layers from the
network layer to the application layer
ZigBee is being designed
specifically for low power, very low data rate wireless embedded control and
monitoring applications. Hardware costs are supposed to be very low, on
a par with CAN and RS232. But since there isn’t any hardware yet, this
remains to be seen.
Estimates are that ZigBee
software requirements vary from 2% to 10% of a Bluetooth link.
ZigBee is extremely low
power, much lower than Bluetooth. It is intended for very long battery
life with non-replaceable batteries. One suggested application is
reading household utility meters while driving by. The long battery life
is achieved partly by leaving the radio in sleep mode for more than 99% of the
time.
Messages can be up to 104
data bytes. Message overhead consists of a 4-byte preamble, one byte start of
frame delimiter, and one byte frame length byte all sent before the data.
A 2 byte CRC follows the data.
Transmission speed is up
to 250 Kbps at up to 30 meters at a base frequency in the 2.4 GHz band.
As might be imagined, antenna design is critical. ZigBee networks are
supposed to be able to form autonomously, but the specification does not
define what that means. ZigBee networks may contain up
to 65,534 devices, compared to eight for Bluetooth.
Channel access is Carrier
Sense Multiple Access with Collision Avoidance (CSMA-CA). The networks
can be star, mesh or cluster-tree topologies. Star is best for lowest
power, mesh is better for scalability, and cluster-tree is a combination of
both.
The primary drawback to
ZigBee is that it doesn’t really exist yet. There are some products, but
the certification process has not been completed and isn’t expected to be
until late 2005. Only two certification houses have been selected (TUV
in Europe and National Testing Services (NTS) in the USA.) Although
ZigBee is being developed under IEEE auspices, the ZigBee Alliance is really a
private concern. Membership in ZigBee Alliance costs $10K per year for
the entry level, and almost nothing is possible without membership. You
can’t even download the specification or browse the FAQs. Protocols are
closely held and proprietary and are about two years behind schedule.
Philips and Motorola were both early supporters but recently have cut back.
This may not mean much, Motorola has a history of supporting concepts and then
cutting back just as it takes off. Even so, it remains to be seen
whether ZigBee will be a success.
Ultra Wide Band (UWB) (IEEE 802.15.3a)
Only legal in the USA, UWB
is strictly experimental for now. The FCC is allowing only five applications
for the near future. They are:
-
Home and office applications
known as Wi-Media that can only be used indoors.
-
Automotive collision detection
systems. (Dibs on calling it Wi-Boom)
-
Automotive suspension systems
that respond to road conditions.
-
Short-range ground penetrating
radar for locating underground pipes etc.
-
Through the wall imaging for law
enforcement and search and rescue applications.
UWB is designed to send
data in very short pulses over a very wide bandwidth. Proponents claim
that the pulses are so short that they will not interfere with competing radio
broadcasts.
UWB is expected to achieve
110 Mbps at up to 10 meters or 480 Mbps at up to one meter.
Ethernet for Embedded Applications
Although Ethernet seems to
have been around since mastodons roamed the earth, it has only recently been
feasible to use it for embedded applications. This is primarily because
low cost micros have only recently acquired the horsepower to handle Ethernet
requirements.
References
Specification of the
Bluetooth System: Core Specification v.1.2. Downloaded from
www.bluetooth.org, which is separate from www.bluetooth.com.
Survey of Selected 802.xx
Wireless Standards by David Benson and Michael Gold. White paper on the
web site of SRI Consulting Business Intelligence at:
http://www.sric-bi.com/DF/DFnews/802.xxSurvey/2003-08.pdf
Universal Serial Bus
Specification Revision 1.1
ZigBee: Wireless Control
that Simply Works by William C. Craig. Downloaded from
www.zigbee.com. This is a popular title, as it references two other
documents with virtually identical titles.
