Download off-the-shelf embedded-network connectivity

hands-onproject Embedded-network connectivity
complete range of sample apfact that Java and C are similar,
plications were easier to
the Java class code and C code oflearn and use and offered a
ten used different commenting
more competitive edge.
conventions. Some code has a full
From this perspective, the empage of comments describing
bedded-TCP/IP market has inwhat it is doing, the variables it
deed reached a point at which
uses, and the methods into and
TCP/IP is off-the-shelf, meaning
out of the function. The other
that you can buy everything neccode within the same demo has
essary to embed connectivity into
comments that seem like an afa device. Given the maturity and
terthought and offer little guidlow cost of stacks, you no longer
ance to understanding how the
need to develop your own stack.
code works.
You can use a well-defined API to
Some vendors cram all the relaccess it. However, the market is
evant demo files into a single dinow racing to also bring the derectory. Other vendors scatter the
velopment tools and environcode throughout several directoments up to off-the-shelf stan- The RCM3000 evaluation kit from Rabbit Semiconductor comes
ries, making it more difficult to
dards, moving from requiring you with an evaluation board, a connectivity module, a power suplocate files or even understand
to learn a complex API to letting ply, a compiler and other application tools, a manual, board
which files are in use for a demo.
you work with templates that il- specs, and schematics.
A proper project manager lists all
lustrate how the API works. A
sources files and their dependenproper collection of applications enabled less of a differentiating factor as slacking cies with one-click access to each. In sevme to create templates to learn how to vendors begin to fill out their offerings.
eral cases, I had to break open build files
use functions and to use as foundations
Still out on the horizon, even for ven- to locate code modules. Connectivity apthat I could drop into my own applica- dors with a fairly complete demo base, is plications are written in several lantion. Demos needn’t be full-blown ap- further abstracting connectivity func- guages, and, if the flow of code isn’t docplications; rather, they need to illustrate tions into a parameterized library for- umented, it’s not always clear which role
key aspects of a function. To the vendors mat. Templates are great, but even when a function plays (and thus which lanwho argue that it would take only a few you tear them apart, you’re still working guage it should be written in). One feahours to develop the code to implement at a fairly low level. Further reducing ture I missed in too many instances was
a function such as FTP, I ask: Then, why complexity to a few canned and config- a simple list and description of sample
don’t you have one of your engineers do urable functions makes network connec- code. More than once and only after
it?
tivity even more accessible.
complaining to vendors, I discovered that
Thus, one key differentiation among
Second to the breadth of the applica- code for a function was available but
systems is the available application li- tion library is how well the code is doc- buried in some nondescript directory or
brary. If the demos are insufficient for umented and organized. Even within a documented only through an obscure
building your application, you need to single demo, the documentation often reference.
work the cost of learning the API and lacks consistency. Often, an editor, such
I appreciate it when vendors write docbuilding your application from scratch as Microsoft Front Page, generates the umentation assuming that the user un(both in dollars and time to market) into HTML (Hyper Text Markup Language) derstands neither the API nor the details
your final decision. If you’re still a few documents, resulting in code without of TCP/IP. Some Getting Started manumonths out on your project, the lack of sufficient comments that is not format- als reveal explicitly how to set up the
sufficient demos will probably become ted to read when you print it. Despite the computer and the evaluation board, even
EVALUATING IN TANDEM
Working with several kits at one
time has its drawbacks. Sometimes, I confused the function
names. Also, because each vendor uses a different directory
scheme for managing the various
types of files—HTML (Hyper Text
Markup Language), Java, C, compiled code, headers, and so on—I
sometimes forgot where I should
put files. This lapse led to various
compilation problems, such as
52 edn | November 14, 2002
using the old, incorrect version of
code instead of my new code.
Another difficulty was that each
evaluation board used a different
subnet, requiring my computer to
use a different IP (Internet
Protocol) address. If I wanted to
try an idea between two boards, I
would have to change the IP
address and reboot my computer. To keep my sanity, I created a
profile for each board, describing
the equipment, including cable
type and the setting to use on
the switch box, if required, and
each IP address it used. A profile
serves as a checklist to ensure
that you always correctly set up
the board. It also works for a single evaluation board when you
have to clear your desk to work
on another project.
Working with multiple boards
allowed me to see just how
portable my code was among
boards. Ideally, I should have
been able to use the same Web
pages and Java applets and support C code, but each board
worked slightly differently with
the stack. Abstracting the stackfunction calls and creating my
own API (application-programming interface) made it easier to
port all types of code.
www.edn.com