Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

A new and rapidly growing source of Web content will soon be found in practically every office, business, and even in homes: embedded systems. Office buildings can use embedded Web servers to monitor building temperature or door status via the Internet. Factories can use them to monitor (and even control) manufacturing processes. Embedded Internet technology in consumer electronics can let you program your home digital video recorder from anywhere in the world. (See "Channel Partners," September 2002, to read how ReplayTV achieved exactly that.)

But publishing information on the Web and publishing from an embedded system aren't really the same thing. It's tempting to assume that embedded Web servers are the answer. They usually aren't the best solution, however, due to the limitations of current embedded controllers. As system designs increasingly call for embedded data sources, you'll need to decide how to best handle these minute robotic publishers.

Stacking the Chips

Modern embedded systems fall into at least two categories. At one end of the spectrum are PC/104 boards, which are essentially shrunken PCs. PC/104 is a standard form factor for tiny CPU motherboards designed for embedded use. These boards can run DOS, Linux, or special operating systems designed for the embedded systems market, like QNX. Working with them isn't much different than developing for a regular PC.

However, PC/104 boards can be pricey when compared to other solutions. You also have to license the operating system to power them, which only adds to the cost. In addition, although the boards are small, they aren't small enough for many applications. Because of these limitations, I'll focus here on more traditional embedded systems—those built around low-power microprocessors or microcontrollers.

The core of the classic embedded system is an inexpensive central processor—for example, a Microchip PIC or an 8051 microcontroller. These chips are small, fast, and cheap. Once integrated, they also make it easy to take total control of custom hardware projects.

Although embedded systems in this category have grown more powerful over the years, they are typically far less powerful than even an older PC. Despite this, the current trend among embedded systems vendors is to equip their products with TCP/IP stacks so that developers can connect their embedded devices to the Internet. Most often, this connectivity takes the form of a Web server.

In most cases this is little more than a marketing stunt. Granted, there are a few instances where having an embedded controller act as a Web server makes sense. For example, most routers now offer configuration screens via an embedded Web server. However, embedded processors make poor Web servers in many cases, for the following key reasons:

Embedded systems may not have full-time Internet access. They are often installed on factory floors or in remote locations, sometimes connecting only via modem. Those that run on batteries often "sleep" as much as possible to conserve power.

Many embedded systems are too busy to handle incoming Web requests. Time-critical systems can't take time out to process an HTTP request every time a Web browser refreshes.

Beefing up a system to handle Web requests adds cost and complexity. It also takes system resources away from the main task the system is meant to accomplish, in an environment where resources are often limited.

Pass the Buck

Regardless of how much vendors may hype them, embedded Web servers are probably overkill. A better solution is to provide a gateway for the embedded system that can let it push the work to a dedicated server. In fact, this is the only realistic solution for small processors that have network connectivity, but can't (or won't) run a Web server.

One way such a gateway might work is using the UDP protocol. Sending UDP packets places fewer demands on time-sensitive embedded processors than do the TCP connections required to operate a Web server. A gateway could receive UDP packets from an embedded system, reformat that data as Web pages, and then serve those pages from a dedicated Web server via TCP.

A simple way to achieve this is to use software on a networked, standalone computer to act as the gateway. This lets you collect data from the device in the most appropriate way—for example, the gateway might read data via an RS-422 port instead of a traditional network—and then provide it to Internet consumers without taxing the small device. Software to manage this is available commercially, but in many cases the interfaces to embedded systems are unique enough that it makes the most sense to roll your own gateway software.

There's no need to dedicate an entire, full-scale server to act as a gateway for embedded systems, however. In some cases, tiny, specialized hardware devices can do the same job. Of course, these devices are also embedded systems themselves. But the fact that they are dedicated to network connectivity and aren't trying to do other things (such as real-time tasks) eliminates many of the problems mentioned earlier.

Their Own Devices

One example of a small, dedicated device designed to help embedded systems developers give their creations network access is the iModem. Manufactured by Cermetek, a major vendor of embedded modems, the iModem product series allows you to send and receive email using the SMTP and POP3 protocols.

By itself, this feature is a good example of a dedicated hardware gateway. However, Cermetek takes the idea one step further by offering iModem customers the use of a specialized ISP called Press4Service. On its own, the iModem can interact with nearly any ISP (or any other service accessible via a normal modem). When connected to Press4Service, the iModem can not only send and receive mail, but it can also send faxes or transmit information via FTP (for example, to a Web server).

Barely larger than a quarter, the NetMedia SitePlayer provides full Web connectivity via Ethernet.

Another example of dedicated networking hardware is NetMedia's SitePlayer. This inexpensive device is a kind of Internet coprocessor for embedded systems. It lets embedded developers connect devices directly to Ethernet, allowing plug-and-play Web access. Once connected, the SitePlayer module acts as a Web server that can build customized Web pages based on your templates. Of course, any sufficiently powerful computer with a Web server could handle this task. The advantages of the SitePlayer are that it is inexpensive and definitely small (see photo).

Developers who want to roll their own hardware gateways rather than purchasing a device like the SitePlayer might consider the Dallas Semiconductor TINI module, a tiny Java processor with a built-in Ethernet port. There are many similar products on the market that let ordinary microcontrollers connect to the Internet. For example, NetBurner or Kanda's HD-series boards both provide network connectivity over RS-232 serial links.

For the short term, developers will continue to invest in extra hardware to Internet-enable small devices—especially older, legacy devices. However, these add-ons are primarily a stopgap measure. In the near future, some type of built-in Internet connectivity will become practical for all but the tiniest embedded systems.

Thin Servers

It's not hard to accommodate embedded systems that have email or UDP communications built in. All you need to do is provide a brokering infrastructure to distribute the results of the embedded system's efforts to the Internet at large. Eventually, we'll probably even see standards emerge in this area. For now you're stuck rolling your own.

Luckily, today's Web developers have easy access to powerful networking tools. Using languages like Java, it's simple to handle email and UDP packets, or even build custom Web servers. (You can find examples of these in my Java@Work columns in past issues of Web Techniques.) So unless they're really cramming a PC into an embedded system, developers would be wise to ignore the vendor hype and resist the urge to build a Web server into every device.

The gateway approach I've described has other advantages, too. For one thing, the gateway is not limited to acting as a Web server. It might publish the embedded system's data via FTP, or using a message-queuing mechanism like WebSphere MQ, Microsoft Message Queuing (MSMQ), or Java Message Service (JMS). It could store data in a database, perform calculations, or do other customized processing. If you have a need and are feeling ambitious, you might even write your own "embedded switchboard" that lets embedded systems publish Web content and provide email, pager, and fax notifications, all at the same time. The possibilities are limitless.

---

Al is the author of many popular programming books, including Java 2 Network Protocols Black Book (Coriolis). You can find him on the Web at www.al-williams.com.

RELATED ARTICLES Code Signing in Adobe AIR Dr. Dobb's Agile Newsletter 08/08 CUDA 2.0 Released Coverity Intros Software Readiness Manager for Java New Data Center Architecture Proposed		TOP 5 ARTICLES No Top Articles.