Internet Connectivity: Stacking the Odds in Your Favor
For those of you tasked with implementing connectivity in your next design, this article presents a look at TCP/IP and offers some practical advice to keep you out of trouble.
America is the land of the salesman. Companies deluge consumers with products that are more fashion than function: double mocha decaf espresso, scented toilet paper, telephones disguised as cartoon characters. Sales people help us confuse "need" with "want." Everyday products possess a staggering number of unimportant variations.
The latest golden goose for entrepreneurs of all stripes is the Internet. Today's '49ers have discovered that all products "need" a connection to the 'Net. The hype that surrounds the Internet, though, hides the vast network of interconnected embedded systems that already exists. Every credit card transaction verified by a quick modem uplink is a part of a network. ATMs and gas pumps, point-of-sale terminals and cell phones are all interconnected embedded devices. It's clear that embedded systems are already parts of LANs and WANs and will become much more connected in the future.
Internet hysteria and the proclivity of salespeople to sell anything, even if it doesn't exist, means that many developers are being told to add TCP to their products, even if sales, marketing, and engineering don't know just what this "feature" really means.
Some applications are obvious Internet candidates; some, in fact, require a 'Net connection as their raison d'etre. Set top Web boxes, for instance, are embedded systems already being produced in the millions.
Others are less obvious. An invisible yet widely prevalent embedded application is the point-of-sale (POS) terminal. From the dawn of the embedded age, smart cash registers replaced mechanical monstrosities. Many of these are now connected via sophisticated LANs and even proprietary WANs. One of Walmart's claims to fame was the rooftop disk on every store, which uploads sales and inventory information and downloads new pricing data in nearly real time.
Even traditionally low-IQ systems may benefit from networking. Coke machines that call the distributor when the cash box is full or the cola supply is running low saves unnecessary and expensive visits. Smarter versions that signal a failure minimize down time, maximizing profits. Data acquisition equipment might use the Internet to send results to a remote facility. And, wouldn't it be nice if the vendor could log into that "broken" piece of equipment, downloading a code update or perhaps offering more interactive, higher quality help to the poor confused user?
The Internet hysteria has skewed our thinking, though, to the point that we have a difficult time distinguishing communications from the Internet. The acronym TCP/IP too often creates an immediate image of a phone connection to an ISP. In fact, TCP/IP is not the Internet! TCP/IP is nothing more than a part of a suite of communications protocols. Yes, it's the basic Internet lingua franca, but Unix hands know that it possesses a much wider range of applications.
Suppose you're building a submersible deep ocean probe. It's connected to the mother ship via a thousand feet of armored cable. In a trailer on deck, a skilled operator drives the device by sending commands down the cable. You've got to connect the submersible's embedded brain, which controls the unit's thrusters, to the computer on the ship using some sort of communications link.
In the past, these sorts of applications invariably used a custom comm protocol, one developed by the engineers and painfully extended each time a new shortcoming appeared in the protocol's design. Now we've learned the value of using standards of all sorts; a much more natural choice is TCP/IP. You'll be able to buy comm software instead of creating it (at great expense).
An important secondary benefit is that some day, as the world invariably becomes more wired, someone will want that submersible connected to the Internet. Using TCP/IP means that it's already speaking the right lingo.
Though more and more embedded systems will indeed be nodes off the global Internet, the vendor claims of networked toasters are perhaps a trifle premature. Understand that TCP/IP is an enabling technology suitable for small local networks of just a few computers, as well as for connections to the entire world. If you're connecting embedded systems together, these days it makes an awful lot of sense to consider using TCP/IP as the communications protocol.
Think of TCP/IP as a widely available suite of protocols and allied applications. You can use it for basic low-level communications. Or, buy (or even download code from the 'Net) higher-level applications software like Telnet, FTP, and the like that resides on top of the TCP/IP stack to give you robust control and data transfers. Add a Web server, if needed, to support a graphical interface to your device. Add a PPP module if the device should dial into an ISP and get on the real 'Net. Pick and choose the pieces to fit your application.
TCP/IP is a much misunderstood buzzword. It is actually nothing more than a collection of well-behaved protocols that operate together to transfer data between a physical device (modem, Ethernet, and the like) and an application.
Figure 1 depicts the relationship of each of the protocols. It looks a bit like a set of children's building blocks, piled on top of each other; for this reason, it's often referred to as the protocol stack, and the software that implements this set of protocols is called the TCP/IP stack.
Click on image to enlarge.
The lowest level of the stack is the actual connection to a physical communications device. A device driver, in the network interface block, is the software responsible for communicating with this device.
TCP/IP is independent of the physical communications medium. You can use a plain old telephone line and modem to connect to an ISP. Hang an Ethernet between devices. Use an RS-422 link in noisy factory environments. Some systems actually run TCP/IP over the I2C interface built into some microcontrollers.
One level up we see "IP," or Internet Protocol. IP supports the routing and delivery of packets. It uses a unique address-the IP address-to send packets to the proper destination. The IP protocol provides fragmentation and reassembly of datagrams and error reporting. It uses the ICMP (Internet Control Message Protocol) to generate error messages for reporting routing failures back to the source.
ARP (Address Resolution Protocol) and RARP (Reverse ARP) translate the IP address, which might be global to the entire Internet, to Ethernet addresses used on the local communications devices.
TCP and UDP lie above the IP layer. TCP (Transmission Control Protocol) is a robust, flow-controlled service that moves data in packets that are serialized and acknowledged. When a communications glitch destroys a packet, TCP identifies the lost data and requests a retransmission.
UDP (User Datagram Protocol) is much simpler than TCP and is used where TCP's high reliability isn't required. Some applications software uses UDP instead of TCP (for example, Simple Network Management Protocol, or SNMP).
Application programs live at the top of the stack. Telnet, FTP, and Web services are common applications on an Internet-based system.
TCP comes with its own simple API, one that bears a striking resemblance to disk I/O. You call services within TCP from the application program to request communications. Typically, you'd open a connection, send and receive data, close the connection, and get status information. So, you can write your own communications code that uses the resources provided by the TCP stack.
Having a more sophisticated API sandwiched between an application and TCP isn't unusual. Probably the most common of these is the Berkeley interface, used in BSD Unix and provided with many embedded TCP/IP stacks.
The TCP/IP stack shown in Figure 1 is pretty much the minimum amount of software needed to implement a TCP-based communications link. You'll add the physical device at the bottom of the stack and applications at the top.
Though "re-use" is the mantra of the '90s, it seems there are few software components one can actually purchase and re-use. This isn't the case for Internet suite software, as an army of vendors will happily sell you the code needed to implement any part or all of the entire Internet suite, from the TCP/IP stack to a complete set of programs for Telnet, Web hosting and browsing, mail, and FTP.
The stack itself is a complex and sizable set of code. Attempting to write this code yourself is foolish, as the cost will soar towards infinity, probably paralleled by the bug rate. Though the price of a commercial stack is non-trivial, it's a pittance compared to the cost of doing one in-house.
An astonishing variety of products aimed at developers working with TCP/IP exists. Most fall into the following categories (though this isn't an all-inclusive list of vendors and products).
All or parts of the Internet suite are available from a wide number of vendors. Some, like Fusion from Pacific Softworks, are stand-alone TCP/IP stacks and related Internet applications programs. Expect very complete TCP/IP implementations, and optionally pretty much any sort of program you're used to as a 'Net user, from e-mail to FTP to BOOTP and DCHP (programs that discover the protocols' IP addresses and other setup information).
Other vendors sell the stack as part of an RTOS, often unbundling the TCP protocols into a separate product. There's a natural synergy between an RTOS and a TCP stack. The complexity of establishing and maintaining a TCP link is such that in a real-time application, you'd usually want to pass a buffer of data to a task, letting the task handle the communications at its own rate as other processes continue.
Most of the more popular commercial RTOSs already either include TCP/IP or offer it as an option. US Software's USNET, ISI's pSOS, QNX,
ESP's RTXC, Phar Lap's ETS, and a dozen others have protocol suites available today. Most are optimized for embedded applications where size and speed are critical concerns.
But why stop at just a software solution? Some companies provide a complete, or nearly complete Internetworking package that includes both software and hardware. These vendors are generally pushing their own CPU, adding TCP/IP software and a reference design as a form of differentiation and as enticement for those who really would rather not design their own system from scratch.
For instance, Vadem's iPump consists of their VG330 memory (a 16-bit single-chip PC based on NEC's V30MX), and a Rockwell modem chip to provide a complete Internet connection. You buy the parts ($25 in volume), use their reference design, and build the system yourself. The complete TCP/IP stack and Internet software is included in the price.
For large volume applications Vadem will sell you the VG330 core as intellectual property (another "IP" acronym not to be mixed up with Internet Protocol, IP in this context refers to a set of VHDL, or Verilog HDL, equations containing the CPU and peripherals you can turn into your own custom IC).
OSICOM's NET+ARM is an ARM-based processor that includes all of the hardware needed except RAM, ROM, and the physical networking link. It comes with object code for the entire TCP/IP stack, as well as many higher level Internet applications.
National Semiconductor is using TCP/IP as a way of promoting their ns486 processor. Their product is also a PC reference design bundled with a complete set of Internet software from QNX.
The TCP/IP stack is invisible to your product's user. Their interface may be via buttons, lights, or a GUI of some sort.
Several companies focus on the user interface itself (or, in the case of QNX, offer a GUI as an adjunct to their RTOS). For example, Spyglass offers several Web browsers that are configured for embedded applications like smart telephones.
The other side of the browser is, of course, a Web server. Though this is part of the Internet suite and is available from dozens of companies, one outfit offers a truly tiny version. EmWare's EMIT server uses a somewhat proprietary communications protocol to serve Web pages from an embedded device very efficiently. Unlike other Internet applications EMIT is not dependent on TCP/IP; it will run on top of any comm protocol, greatly reducing code bloat on tiny CPUs.
The decision to make a product Internet-aware, or even to use a TCP/IP stack for point-to-point communications, is not one taken lightly. Costs are high and processor/memory requirements significant.
All TCP/IP packages are big, complex beasts. As with any new tool, figure on spending a couple of weeks mastering the software's subtleties. Take time to run through and test example code included with the package before plunging in and building your real application.
A lot of hooks may exist between a TCP/IP package and your RTOS. Porting a commercial stack to an OS for which the vendor hasn't qualified the stack is probably unwise-or at least expensive. Often, an interface layer lies between the stack and the OS, one that is highly optimized to maximize the stack's performance. Though an interface layer may seem a trivial bit of code, some vendors report up to an order of magnitude performance degradation of the entire system when this layer is poorly implemented.
Several companies focus exclusively on the x86 market. QNX and Phar Lap, for instance, sell stacks and RTOSs exclusively for embedded 32-bit x86 processors. They exploit the sharp decline in the price curve of yesterday's hot PC processor (say, 486s) to form cost-effective yet high-performance embedded systems.
Other RTOS/TCP products run on a number of platforms. The "big three" RTOS/TCP packages (ISI's pSOS, Lynx's LynxOS, and Microtec's VRTX) are aimed primarily at 32-bit processors ranging from Hitachi's SH to MIPS, ARM, 68K, x86, and the like.
In general, you'll find that the performance and specifications of the Internet suite of programs will be well characterized on big 32-bit processors. Most vendors will quote realistic communications speeds and memory requirements.
Everything changes, though, if you're planning to use a TCP/IP stack on a microcontroller. Though some vendors do sell stacks for even 8051s and Z80 variants, few are willing to quote actual size and bandwidth statistics. Microcontrollers come in so many flavors, each often offering several different memory models and configurations, that creating realistic benchmarks is problematic at best. Suffice to say that a realistic TCP/IP configuration will burn up a lot of resources on an 8-bit CPU.
TCP/IP stacks are big, generally eating up at least 30K of memory. Add other parts of the Internet suite and memory requirements will go up sharply. PPP alone can eat up at least another 30K. Include a Web server, Telnet, and the like, and you're suddenly faced with hundreds of kilobytes of code.
Though the servers are usually small, a Web browser is a monstrous beast. Some vendors offer "lite" versions for smallish embedded systems, complemented by full-featured browsers for bigger applications.
The beauty of the Internet suite, though, is its modularity. Given a TCP/IP stack, you'll add just the components needed for your application, incurring the size penalty in a reasonable tradeoff vs. features. The problem with this modularity is that it's difficult for vendors to quote all size variations. This is a function of the features you use, the compiler, and the processor. Work closely with your vendor before making a purchase, so you're not surprised by a ROM image that's 200K bigger than you anticipated.
Don't be lulled into complacency by an advertised microscopic package. For instance, emWare's sub-1K Web server doesn't include TCP/IP. It's a nifty niche product that requires you to add your own communications protocol. If the touted size seems amazingly small, look to see what's missing.
A standard way of pricing TCP/IP stacks and Internet applications software simply doesn't exist. Companies selling hardware often give the code away for free (as long as you buy their chips). Software outfits use the RTOS pricing model: some sell it outright, some require you to pay royalties on each unit shipped, and some require a purchase/royalty mix.
Suffice to say that TCP/IP does not come cheap. An outright purchase may run tens of thousands of dollars; $15,000 is a fairly typical figure, though be warned that pricing is all over the map.
Part of the pricing decision will come down to whether or not you want the source code. If you're concerned the product may become unsupported in five or 10 years, surely there's value in having source code around. But, except possibly for the API, are you really going to modify the code? Few of us are truly adept at the nuances of this complex protocol; don't plan on becoming the TCP/IP low-level whiz unless you're willing to invest a year or more at it.
You'll need the source if your target CPU is a small processor like a microcontroller or even an x86 operating in real mode. The eternal "cost vs. performance" quest gives these chips a vast number of memory models; no vendor will provide stacks compiled for all possibilities. Instead, you'll need to get the source and compile it yourself, using your system's memory model.
Persistent rumors that baffle verification suggest some microcontroller linkers crash and burn when faced with a big hunk of code like a TCP/IP stack. All reputable tool vendors have a limited time try-before-you-buy policy, so run size tests early when returning the product is still an option.
A lot of software ported from the PC world to embedded systems inherit the sins of the desktop. Floating-point libraries, for example, have a long history of being non-reentrant, creating many tough-to-find problems for people doing math in more than one task.
Don't assume that a TCP/IP stack is reentrant. Check with the vendor. If you're planning to run a multiple task system, with more than one task performing communications, a non-reentrant stack will create havoc.
The flip side of the coin is the oldest reentrancy trick in the world: disable interrupts during impure operations. If the stack disables interrupts for more than a handful of microseconds, your real-time hardware may not be properly serviced. Again, question the vendor carefully.
Even a pure TCP/IP stack is problematic if the communications device driver (say, for Ethernet) is non-reentrant. Unfortunately, many of these are ported from Linux and Windows, and may or may not be reentrant.
An Enticing Option
Communications has long been a fact of life in embedded systems. Now we're seeing more comm demands, over small local networks and even globally.
If your application can stand the size and costs, TCP/IP is a logical choice for the communications protocol. You get the benefit of a robust standard with off-the-shelf implementations readily available, a scaleable code base, and the possibility of an easy connection between your device and a user who's a continent away.Jack G. Ganssle, a not-so-old embedded hand, helps companies improve their embedded engineering processes. His "Break Points" column appears monthly in Embedded Systems Programming. Contact him at email@example.com.
Click here to access PDF version of article.
All material on this site Copyright © 2012
CMP Media Inc./UBM Electronics/UBM--All rights reserved.