Hardware Reference
In-Depth Information
familiar with the various protocols that the Arduino
speaks. Figure 11-2 gives you an overview of them.
and I2C. The serial port was useful for communicating
directly with your personal computer; the I2C option was
useful when working with the microcontroller, because it
left the microcontroller's serial port open for programming
and debugging.
This figure tells you something about the physical layer
(which pins are used for which modes of communication)
and the data layer (which data protocols the device can
speak). You know by now that if you're using a particular
set of pins for its communications functions, you can't use
it for other functions.
When you're planning a project, consider which of your
devices' ports are used for configuring, programming, and
debugging, and try to leave them free when possible. On
the other hand, if the programming interface offers the
fastest and most reliable means of communication, it may
be worthwhile to deal with having to use it for both pro-
gramming and its final application.
Most of the single-purpose devices you used in the topic
spoke only one protocol, but that's not always the case.
For example, the ultrasonic ranger you used in Chapter 8
offers three different interfaces. It has an analog voltage
output (0-5V, the one you used); an asynchronous RS-232
serial port (Tx and Rx) that sends data at 9600 bits per
second; and a pulse-width output (PW), which outputs a
pulse that goes from low to high to low again, changing the
width of the pulse with the distance of the detected object.
All of this is described in the ranger's datasheet, which
you can find online at
www.maxbotix.com
. These multiple
protocols are useful when you're interfacing the sensor to
a microcontroller with no analog inputs; when you want
to talk directly to a computer that has an RS-232 serial
port; or when you're not using a computer at all, and want
to control a simple circuit with a changing pulse width or
voltage.
Picking a Serial Protocol
When planning a project, picking a serial protocol may
seem confusing: synchronous or asynchronous? TTL serial
or RS-232? I2C or SPI? USB? Most of the time, the choices
are made for you because there's some component that
you have to use—and it only speaks one protocol. But
when you have a choice, here are a few things to consider.
What protocols are common to all the devices in your
system?
If all of your devices speak the same protocol, it's
probably the obvious choice.
Do your devices need to be able to decide indepen-
dently when they'll send information?
If so, then any
system that combines them in a master-slave relationship,
like any of the synchronous serial protocols, won't work.
The SonMicro RFID reader you used in Chapter 9 also
offered two different communications options: TTL serial
Do you need multiple devices to communicate over
the same wires?
If so, consider protocols that use a bus
system. Synchronous serial protocols and some asynchro-
nous ones, like USB and RS-485, use such a system. All of
these require some form of addressing.
Figure 11-3
MaxBotix LV-EZ-1 communica-
tions options.
Pulse width out
(147µs per inch)
Is distance or speed a factor?
Many protocols that need
to be able to transmit over long distances use differential
signaling, in which there's both a data+ and data- line. The
same data is sent over both lines, always adding up to zero
volts. This minimizes electrical noise. USB, RS-485, and
Ethernet all use differential signaling. Differential signaling
generally allows for faster data rates as well.
BW
PW
AN
RX
TX
+5V
GND
Analog Voltage out
(~9.8mV per inch)
RS-232 serial
(9600bps, 8-N-1, outputs
“Rxxx\r”,
where xxx is 0-255)
Rx
Tx
