Hardware Reference
In-Depth Information
Ask Politely for Clarification
Messages get garbled in countless ways. Perhaps you hear
something that may not make much sense, but you act
on it, only to find out that your partner said something
entirely different from what you thought. It's always best
to ask nicely for clarification to avoid making a stupid
mistake. Likewise, in network communications, it's wise
to check that any messages you receive make sense.
When they don't, ask for a repeat transmission. It's also
wise to check, rather than assume, that a message was
sent. Saying nothing can be worse than saying something
wrong. Minor problems can become major when no one
speaks up to acknowledge that there's an issue. The same
thing can occur in network communications. One device
may wait forever for a message from the other side, not
knowing, for example, that the remote device is unplugged.
When you don't receive a response, send another
message. Don't resend it too often, and give the other
party time to reply. Acknowledging messages may seem
like a luxury, but it can save a whole lot of time and energy
when you're building a complex system.
X
assume that communication errors are in the element of
the system with which you're most familiar. They're most
often in the element with which you're least familiar, and
therefore, are avoiding. When you can't get a message
through, think about every link in the chain from sender
to receiver, and check every one. Then check the links you
overlooked.
Agree on How You Say Things
In good relationships, you develop a shared language
based on shared experience. You learn the best ways to
say things so that your partner will be most receptive,
and you develop shorthand for expressing things that you
repeat all the time. Good data communications also rely
on shared ways of saying things, or
protocols
. Sometimes
you make up a protocol for all the objects in your system,
and other times you have to rely on existing protocols.
If you're working with a previously established protocol,
make sure you understand all the parts before you start
trying to interpret it. If you have the luxury of making
up your own protocol, make sure you've considered the
needs of both the sender and receiver when you define
it. For example, you might decide to use a protocol that's
easy to program on your web server, but that turns out to
be impossible to handle on your microcontroller. A little
thought to the strengths and weaknesses on both sides of
the transmission, and a bit of compromise before you start
to build, will make things flow much more smoothly.
Tools
As you'll be working with the physical, software, and electrical interfaces of objects,
you'll need physical tools, software, and (computer) hardware.
Physical Tools
If you've worked with electronics or microcontrollers
before, chances are you have your own hand tools already.
Figure 1-1 shows the ones used most frequently in this
topic. They're common tools that can be obtained from
many vendors. A few are listed in Table 1-1.
NOTE:
You'll find a number of component suppliers in this topic. I
buy from different vendors depending on who's got the best and
the least expensive version of each part. Sometimes it's easier to
buy from a vendor that you know carries what you need, rather
than search through the massive catalog of a vendor who might
carry it for less. Feel free to substitute your favorite vendors. A list
of vendors can be found in the Appendix.
In addition to hand tools, there are some common elec-
tronic components that you'll use all the time. They're
listed as well, with part numbers from the retailers
featured most frequently in this topic. Not all retailers will
carry all parts, so there are many gaps in the table.
