For years, you've heard fantastic stories about network-enabled refrigerators and toasters—stories that, from my perspective, have only reduced the credibility of embedding connectivity. However, as the cost of connectivity continues to drop, an increasing number of embedded applications can make serious enough use of such technology to justify the extra expense (Reference 1).

For this hands-on project, I wanted to see for myself just how ready embedded TCP/IP (Transmission Control Protocol/Internet Protocol) is for mass deployment. Given that myriad companies offer networking chips and TCP/IP stacks, I chose to work with several kits to give myself multiple data points. I chose kits from Connect One, Cyan (using a stack from CMX), Rabbit, Ubicom, and Zilog. My goal was to determine whether embedded TCP/IP is truly affordable, in both dollars and development time, what I could expect from vendors, and which processor/software combination promises to best meet the constraints of an application.

Quickly getting the evaluation boards up and running was critical. Foremost, I didn't want to spend a lot of time learning a system just to evaluate it. Some of the technical manuals that come with these kits are daunting; you shouldn't have to read 300 pages just to blink an LED or serve up a "Hello World!" page. I also wanted to be able to evaluate several kits to increase the number of processors from which I could make my final selection. I wanted to take a tour of each platform, quickly loading a demo application, making changes that would better reflect the conditions of my application, verifying performance, and getting an idea of the usefulness of the available tools.

As I worked with the kits, I realized that the price of the processor and software, although important, probably wasn't going to be the most important consideration in my final selection. In general, the vendors seemed fairly competitive on price—in the ballpark of $10 for the processor in volume quantities, including the cost of the stack and development tools. Next, I looked at performance and code footprint, which the vendors often tout as the primary considerations for selecting a processor and stack. However, if you're sending limited data, maximum throughput is less important (see sidebar "Testing throughput"). Also, if your application isn't complex, footprint isn't critical, because you don't need a lot of headroom. Thus, my primary concern became which development environment could most efficiently help me develop my application (see sidebar "Other considerations").

As a strong believer in a positive out-of-the-box experience, when I finally made time to look at an evaluation board, I wanted to begin the evaluation—not discover that I was expected to supply a critical piece of equipment that I didn't have handy. For example, some kits come with an Ethernet cable; some don't. If you're going to directly connect the evaluation board to your computer, however, you need a crossover cable. If you connect through a hub or router, you need a standard cable. Using the wrong cable can set you back for a while until you figure out what you've done.

One way to improve your out-of-the-box experience is to check the kit when it arrives; don't wait until the day you want to use it. One advantage of evaluating several kits is that one kit usually includes the "missing" part from another. (Before you start mixing kits, however, tag each component with a sticker, so that you remember which cable came from which kit.) One difficult-to-locate piece of equipment was an external modem that could connect to the evaluation board over a serial port, so I could test a PPP (Point to Point Protocol) connection through the phone line to an ISP (Internet-service provider). I found one at a local store for the surprising cost of $100. If you have more time to secure a modem, you can probably find one in your garage or over the Internet for less.

Several companies offer a variety of boards with names such as "evaluation" and "developer" or "standard" and "advanced." In some cases, the difference lies in software alone. The evaluation kit, for example, might provide only binaries and a subset of the development tools. Some differences lie in hardware: RAM-based boards, unlike flash-based boards, lose their code image when you crash and have to power down. The developer's kit may also include an emulator for setting breakpoints and capturing code traces.

In some cases, the difference in price is small between the standard and the advanced kits. In general, developing code for a standard board might take somewhat longer than it would for an advanced kit, given limited tools and lack of debugging hooks. It might be worth the extra bucks to be able to see the entire tool suite, because the tools' usefulness will almost surely be a major factor in your final selection. Some features, such as PPP, SNMP (Simple Network Management Protocol), or a real-time operating system, may be optional and require a separate purchase. You'll also often get better tech support with an advanced kit.

Most evaluation kits cost less than $500. Some kits, however, come in at several thousand dollars. In many cases, the vendor raises the price to filter out garage hobbyists, so that they can't overwhelm tech support. If you're a serious customer and have enough leverage, there's a strong chance that the vendor will dramatically drop the price. After all, too many players with solid products in this market are willing to almost give their kits away to get your business. Software vendors, on the other hand, have less flexibility with evaluations, because it's not difficult to steal code and never pay royalties for it once you've got a copy. Then again, if they won't let you use the code and tools, you can't properly evaluate the overall development environment.

The key to a successful and efficient evaluation is proper documentation. Your evaluation is based on what you see, not what's actually there. More than one technical manual was actually an alphabetical catalog of function calls with no clear description of their relationship to each other. After a bit of searching, I usually found a readme.doc or "Getting Started" manual that provided a description of how to bring the board up. A Getting Started manual is especially important for evaluation boards running third-party software and should be written specifically for the board or chip you're evaluating.

The Getting Started manuals don't teach much. They are enough only to get you going on the board within an hour, showing you how to start the development environment and build and download a demo system. My next step was to explore on my own; I began by printing the demo source files in an attempt to figure out what the demo actually did. From this foundation, I was able to strip down the demo code to bare bones, creating a template for developing my own application and understanding how to perform basic connectivity tasks.

For me, the most important part of documentation was the sample applications. Again, I didn't want to have to learn the entire API for the TCP/IP stack just to serve up a test page (see sidebar "Delving into the stack"). I learn better when I'm tearing apart a working example than when I'm mulling over an explanation in a manual.

Some demos are excellent. One shows the status of DIP switches on the board. It provides a simple example without a lot of confusing bells and whistles of how to send a few bits of data dynamically to a Java applet. I ran into trouble, however, when I tried to send a different data type from the one in the demo. Because I had not yet learned the specifics of Java, I had to take a detour to the library and the Web to find a Java primer. Then, I discovered that knowing Java doesn't tell you everything; you have to use CGI (Common Gateway Interface) programs—in other words, C code—to exchange information with the Java applets. Unraveling this interconnected scheme took me longer than I wanted it to. A second and third demo that sent different types of information (or even one page that sent three data types) would have been helpful, so I could learn the differences in the functions.

Unfortunately, the range of demos that each kit includes varies, and some lack completeness. For example, in one kit, I could find neither a demo of FTP (File Transfer Protocol), which is a fairly fundamental network operation, nor a demo of sending e-mail. Kits commonly demonstrated how to send static pages but failed to show how to create or send dynamic pages. Without a demo application, I had to resort to the 300-pg manual to continue my evaluation. Thus, I found that the kits with the more complete range of sample applications were easier to learn and use and offered a more competitive edge.

From this perspective, the embedded-TCP/IP market has indeed reached a point at which TCP/IP is off-the-shelf, meaning that you can buy everything necessary to embed connectivity into a device. Given the maturity and low cost of stacks, you no longer need to develop your own stack. You can use a well-defined API to access it. However, the market is now racing to also bring the development tools and environments up to off-the-shelf standards, moving from requiring you to learn a complex API to letting you work with templates that illustrate how the API works. A proper collection of applications enabled me to create templates to learn how to use functions and to use as foundations that I could drop into my own application. Demos needn't be full-blown applications; rather, they need to illustrate key aspects of a function. To the vendors who argue that it would take only a few hours to develop the code to implement a function such as FTP, I ask: Then, why don't you have one of your engineers do it?

Thus, one key differentiation among systems is the available application library. If the demos are insufficient for building your application, you need to work the cost of learning the API and building your application from scratch (both in dollars and time to market) into your final decision. If you're still a few months out on your project, the lack of sufficient demos will probably become less of a differentiating factor as slacking vendors begin to fill out their offerings.

Still out on the horizon, even for vendors with a fairly complete demo base, is further abstracting connectivity functions into a parameterized library format. Templates are great, but even when you tear them apart, you're still working at a fairly low level. Further reducing complexity to a few canned and configurable functions makes network connectivity even more accessible.

Second to the breadth of the application library is how well the code is documented and organized. Even within a single demo, the documentation often lacks consistency. Often, an editor, such as Microsoft Front Page, generates the HTML (Hyper Text Markup Language) documents, resulting in code without sufficient comments that is not formatted to read when you print it. Despite the fact that Java and C are similar, the Java class code and C code often used different commenting conventions. Some code has a full page of comments describing what it is doing, the variables it uses, and the methods into and out of the function. The other code within the same demo has comments that seem like an afterthought and offer little guidance to understanding how the code works.

Some vendors cram all the relevant demo files into a single directory. Other vendors scatter the code throughout several directories, making it more difficult to locate files or even understand which files are in use for a demo. A proper project manager lists all sources files and their dependencies with one-click access to each. In several cases, I had to break open build files to locate code modules. Connectivity applications are written in several languages, and, if the flow of code isn't documented, it's not always clear which role a function plays (and thus which language it should be written in). One feature I missed in too many instances was a simple list and description of sample code. More than once and only after complaining to vendors, I discovered that code for a function was available but buried in some nondescript directory or documented only through an obscure reference.

I appreciate it when vendors write documentation assuming that the user understands neither the API nor the details of TCP/IP. Some Getting Started manuals reveal explicitly how to set up the computer and the evaluation board, even showing pictures. Others assume that you know what you are doing; a classic example is a manual that fails to mention that you need an Ethernet crossover cable. If you've never configured a network, even a small one, you could run into a lot of trouble. I learned only a few years ago what a subnet is—all devices on a subnet share the first three numbers of an IP address and have a distinct fourth number—when my home router disappeared from the network for two weeks and brought down the DSL line. You might consider inviting someone from IT to share your weekly doughnuts just as backup, lest you find yourself banging your head on the desk over a networking problem.

Some demos offer challenging stumbling blocks. For example, to test an e-mail transmission, I needed access to a mail server. I balked at the idea of setting up a mail server on my computer. Because my deployed device would probably use an ISP, I thought I might develop my design under real-world conditions. The challenge became finding out the IP address, because you can't use the mail.isp.net format that desktops employ. You could call your ISP, although it's probably easier to send an e-mail to yourself and use a packet sniffer to track the message. Additionally, if you work in a corporate office, getting a live phone line that you can use as a modem can be challenging; the system tied to your current phone line may not support modems.

Some development tools are difficult to use because they mix Windows and command-line environments. For example, from the development environments, I had to run batch files in a DOS window, manage my files outside the environment, or run utilities either from a DOS window or a build batch file of my creation. Vendors could have made some of these steps more transparent—allowing the tools to launch a utility from the environment or to automatically create and manage build files. It was also difficult or annoying to complete certain simple and regular tasks. For example, one environment expects you to select the file you want to download every time, instead of defaulting to the last one you downloaded. Granted, the step was neither a major problem nor a major convenience, but my guess is that if the product developers actually used the product, they certainly would have coded such short cuts.

Another aspect that takes getting used to is the use of various languages. Learning the difference between source files (index.htm) and generated files (index.c) takes some careful reading. HTML and JavaScript (which is not at all like Java) are necessary to create Web pages for the Web server (see sidebar "Web-page compression"). Java is necessary to create classes for passing information between the Web-server and the remote monitoring browser. I also needed to run C on the embedded-networking processor to interface the hardware and the application software to the Java applets. And I needed a separate Java development environment; otherwise, I'd have to build and download my application and then serve up pages just to test simple changes (see sidebar "Paying your time tax"). Because these languages closely resemble each other, I had to carefully change my frame of mind when I changed languages, remembering the various subtleties and differences between them. Unfortunately, I still ended up stumped by the occasional frustrating error, because I forgot which context I was working in.

I assumed that every developer's kit had everything I was going to get; nothing else was coming to ease my job. If I had problems with simple issues, such as setup, I got nervous about the rest of the kit. However, the problem was sometimes me; I just didn't understand certain concepts the first time through. If you work with only one evaluation kit, you'll learn whether you like it, but you won't have any idea of whether you should expect more. Thus, I strongly recommend that you look at several kits. Kits cost relatively little, and the cost is effectively zero when you spread it across a high-volume device. You can donate the kits you don't use to a local university for a write-off or sell or give them to a colleague looking to expand his or her engineering skills.

Using different kits worked for me in several ways. For example, looking at different kits showed me which aspects of designing connected devices are constant across processors and which are factors of the individual vendors. For example, once I understood how to post data to a Web page from the Web server with one kit, doing it with the next kit was a matter of figuring out which system call to make. Also, the variety of support tools and the approaches to performing certain types of tasks are varied. One of the most valuable benefits I discovered was that an issue that confused me when working with one kit became clear to me when working with another kit. In this light, I worked with several kits concurrently (see sidebar "Evaluating in tandem") and shortened my learning curve. Switching among kits also enabled me to continue my evaluation on other boards while I waited for tech support to solve a problem that had brought evaluation on one board to a standstill.

A key facet of evaluation is that it takes much less time to work on the third and fourth kits than it does on the first two. While evaluating the first two kits, I struggled with learning how to use certain aspects of TCP/IP; my learning curve with subsequent kits was significantly shorter. My questions evolved from "How do I do this?" to "How does this vendor implement this idea?" In the end, I was able to make a better final evaluation of each processor. I not only had more experience with what I could expect from a processor, but also more options to choose from.

Author Information

Technical Editor Nicholas Cravotta hopes to connect an entire house for his next hands-on project. You can reach him at 1-530-346-8556, fax 1-530-346-9777, or ncravotta@edn.com.