September 12, 1997

Hands-On Project:

Going global in the real world:
Putting an embedded system on the Internet

David Shear, Contributing Editor

An embedded system--be it an office copier or a robot--can tap a world of resources if it's connected to the World Wide Web. The design of EDN's embedded Web server shows you how.

My perception of the Internet spans the range from delight to disgust: so much potential, so little fulfillment. The typical application wastes a lot of perfectly good technology and creates a black hole of productivity as people produce slick--but not very useful--online material.

If you look beyond the typical, though, you can see how the Internet can really help you. If you design embedded systems, for example, the Net can provide hardware and software resources that greatly enhance your system even though they're physically nowhere near it (Reference 1). All you have to do is add a Web server to your embedded system, which is what I did for an EDN hands-on design project.

Extra resources are important for embedded systems, which usually can't afford luxuries such as display screens and online data storage and which sometimes have to work in out-of-the-way locations. An office copier, for example, is a complex embedded system (usually controlled by an embedded 32-bit processor) that requires frequent troubleshooting and repair by an off-site technician. If you can hook the copier to the Internet, a technician can run diagnostic tests from any location where there's a PC connected to the Web. As a bonus, any Web browser, such as Netscape or Internet Explorer, can give the technician a standard, familiar user interface.

A particular advantage of an embedded system on the Net is the system's ability to tap remote data storage (see box "The Web as a virtual embedded system"). Many embedded systems are too size- and power-limited to provide much data storage of their own. Consequently, online documentation, help screens, and onboard diagnostics are unaffordable luxuries. By connecting to the Internet, though, a size- and power-limited embedded system does not have to be feature-limited.

With that kind of potential for the Internet in mind, and with the Internet becoming ever more pervasive, I decided to explore the promises and pitfalls of putting an embedded system on the Web. I didn't care if the system was actually useful; what I wanted to do, really, was to see what's involved in making an embedded system "Web-aware" by giving it its own Web server.

A useful application

I came up with an extremely useful application, though. It's essentially a nerdy version of solitaire for engineers who need a distraction from serious work. It challenges you to exercise a "black-box" circuit via the Internet and try to figure out what the circuit's components are (see box "EDN's Mystery Circuit"). I've connected the circuit to an analog I/O board, which in turn connects to a single-board computer. The single-board computer connects to the Internet and runs software that implements an embedded Web server; the Web server sends HTML code to inquiring Web browsers to implement a Web page. The single-board computer also runs a C program that I wrote for exercising the Mystery Circuit via the analog I/O board.

The idea of putting some of my embedded system's resources outside the embedded system came when I was about halfway through developing the system and ran into a problem: The system I was designing had to be easy to modify so that overworked editors in EDN's main office could quickly and easily change to a new Mystery Circuit every now and then to give you a fresh challenge. Modifying the software of an embedded system can be difficult, though; it's usually more complex and time-consuming than modifying software on a desktop PC. There had to be an easy way to maintain the system, or EDN's Mystery Circuit would stop providing new mysteries.

That's when it hit me. I realized I could separate typical embedded-system functions from the Mystery Circuitt functions by using the power of the Internet. All my embedded system needs to do is to set and read voltages and digital values. Another Web server can provide snazzy graphics about the Mystery Circuit and tell you how to exercise it (Figure 1). Your Web browser can access both servers. So whenever someone at EDN decides to change to a new Mystery Circuit, all that's necessary at the embedded system is to unplug an old circuit and plug in a new one. Any changes in documentation, instructions, or graphical display can occur on another Web page running on any Web server anywhere.

Using Web technology isn't without risks, of course, and one particular concern is security. How can you protect a system from attack by people who have a total lack of morals and way too much time on their hands? In my case, I decided that protecting EDN's Mystery Circuit from terrorists wouldn't be a top priority, so I took the industry-standard approach to security. I ignored it.

Another concern is reliability. You can lose your connection to the Internet, or the Internet itself can go down. Still, it didn't seem essential that EDN's Mystery Circuit always be available without fail, so I followed the industry-standard approach for reliability, too. As with security, I ignored it. If you can't always access EDN's Mystery Circuit, there's always Windows solitaire.

Development tools that help

If you develop Internet applications (and probably even if you don't), you can't help noticing how quickly the Net changes. Keeping up with these changes can be a full-time job in itself. If you're already creating embedded systems, as I am, that can be one job too many. Consequently, for this project, I used Internet software and tools from outside vendors, just as I do to develop embedded systems. You wouldn't think of developing your own real-time operating system or a TCP/IP stack. The same attitude should prevail when you develop an embedded Web server.

But if you stand on the shoulders of others, and if those shoulders are weak or unstable, you'll certainly feel it. So you have to select your tool and component vendors with care. In my case, just making an embedded system Web-aware was enough of a challenge. To minimize the risk in selecting system components and tools, I turned to Phar Lap for its Embedded ToolSuite (ETS) and to WinSystems for an LBC-586Plus single-board computer. I know both companies make quality products and provide excellent support.

Phar Lap's ETS helps you develop software on a host computer and get it running on a target system (Figure 2). A typical desktop PC served as my development host, and the WinSystems board--an embedded PC--became my target. Because I was basing my application on an embedded PC, I could have used any PC as the target during development. That's one of embedded PCs' greatest advantages.

EDN's Mystery Circuit connects to my embedded system through a 12-bit analog I/O board, WinSystems' PCM-AIO. This PC/104 module attaches directly to the LBC-586Plus single-board computer and allows the embedded system to send inputs to the circuit and to read outputs from it. The two-board combination mounts on top of a WinSystems development system, a box that includes a power supply and that has space for a hard-disk drive and a floppy drive. During development, you can easily access system components in the box by removing panels that are held in place by thumbscrews.

I didn't need a hard disk for this application, although my development system included one for versatility. I used the floppy drive to boot the monitor program (the monitor could have been stored in EPROM instead) and then, with the monitor, downloaded code from the host. The monitor program occupies 32.1 kbytes of storage; the application code I developed takes 288 kbytes.

Mountains of manuals

I began my project by looking at a mountain of manuals and considering my significant lack of knowledge about developing a Web server. I could imagine countless scenarios leading to failure. Most frightening was the thought of software from various sources, all of which needed to run nicely together on hardware where it hadn't run before. Failure seemed not merely possible but probable.

The only way I could convince myself to attempt such a project was to have tremendous faith in my development tools. If everything worked as it should, I'd be able to assemble the needed software components and quickly put a Web server online. If everything didn't work properly, I'd be up a creek without a paddle.

Like most embedded-system developers, I'm always leery of using code from elsewhere. We've all been burned too many times by bugs in someone else's code. But you have to put yourself at the mercy of software written by others. The embedded world has become so complex, there's no way you can roll your own and still get a product out within budget and on schedule. Still, it's unfortunate that the same level of quality monitoring that has improved hardware hasn't found a home in software. You buy software with known bugs and no guarantee.

Enough worrying. I started to scale the mountain of manuals. By the time I got to reading about network programming for Phar Lap's real-time ETS kernel, I was more than a little overwhelmed. It seemed I had to be more than just a Web-browser expert; I also had to be knowledgeable in Visual C++, an expert on Phar Lap's OS, and an expert on networking. Fortunately, Phar Lap's documentation was very good in explaining most of what I needed to know.

Connecting the hardware

My first task was to get the hardware running and test a serial connection between host and target. That would at least demonstrate that the host and target could talk to each other and prove that I had a complete, working chain of development tools. The WinSystems computer came up quickly and easily, but the serial connection, which I thought would be easy, turned out not to be so simple. The problem, I eventually discovered, was that my host system's serial interface was configured for hardware handshaking, which Phar Lap's ETS doesn't support. Reconfiguring the host's serial interface in Windows 95 fixed the problem.

Next, I reconfigured ETS to connect the host and target via the parallel interface. This connection transfers programs much faster than a serial connection does and leaves the serial ports available for my application's use. The change from serial to parallel is easy--just a matter of using a switch on the command line in ETS utility runemb, which downloads program code from host to target. In an upcoming release of ETS, it will be even easier. Version 9, which I'm now evaluating, blends the entire tool suite into Microsoft's Visual C++, so you don't have to switch back and forth between C++ and command-line utilities.

Now that I had a working development system, I turned my attention to the application itself. I wanted to demonstrate three uses of Web technology (Figure 3). With the first method, which uses a direct serial connection between host and target, a Web browser essentially becomes an embedded system's virtual front panel. With the second method, the computers on an Ethernet (10BaseT) LAN become an intranet. The third method connects a browser to an embedded system via the Internet and the World Wide Web.

I began by using a sample program from Phar Lap to see if the embedded Web server would work properly over a serial link using a PPP (point-to-point protocol) connection. Once again, though, I had problems with the serial link. By calling Phar Lap's tech-support group, I learned that using Win 95 in a direct serial PPP link is not exactly trivial. In fact, rather than trying to explain it over the phone, the Phar Lap folks e-mailed me a few chapters from an upcoming manual on how to connect ETS to various networks. They also referred me to a null-modem driver I'd need. It was on the Internet (www.vt.edu:10021/K/kewells/net/), and I easily downloaded it.

Continuing, I connected my host and target computers via serial and parallel ports. Following Phar Lap's documentation, I then attempted to use both connections. My intention was to use a host-resident Web browser over the serial connection as part of my application and to use the parallel connection for development tasks, such as host-to-target program transfers.

Serial killer

As Phar Lap had warned me, though, using Win 95 with a PPP direct serial connection can be complicated, and I soon found myself running out of time and patience. But Phar Lap's support folks had also told me that it's usually easy to get a LAN interface working. You don't have to worry about baud rate, handshaking methods, finding the right cable, nine- or 25-pin connectors, or finding a null-modem driver. You just connect a cable and start it up. So, eager to make some progress, I changed my approach. I decided to get a LAN version going first and then come back to the PPP version. (As you'll see, the direct connection did eventually work.)

I began my LAN approach by having to modify my Win 95 office LAN. I had been using the IPX/SPX protocol; for an intranet application, I needed to reconfigure to TCP/IP. That done, I got the new LAN up and running, and I was then able to run some network and Web examples from Phar Lap's manuals. Ah, progress.

On to learning how to create Web pages with HTML. By this time, I'd bought a book, HTML: The Definitive Guide (Reference 2), which was recommended in the ETS manual and which turned out to be an excellent guide. I learned a lot from it.

Initially, you set up a Web page locally on a single computer. With a text editor or an ASCII-based word processor, you can write HTML code directly to create a Web document. With Microsoft's Word 97, you can also create a WYSIWYG screen and save it as HTML code. I found this approach useful in the beginning just to see how HTML code corresponds to on-screen features, but I ended up writing HTML code directly for the most part. There are also "authoring" tools that can help you create Web pages, but writing HTML directly really isn't all that difficult. Once you've created a Web page, by whatever method, you can use a Web browser on the same computer to see what the page looks like.

Using HTML to create a Web page can be time-consuming, though, if you let it. You can create a presentable page in hours or even minutes once you've gotten some experience, but then it can be tempting to keep adding a lot of neat things to make your page look better. Also, learning HTML is like learning any other language. The basics come quickly, but expertise take time. I didn't become an expert on this project, but I learned enough to get the job done.

After I learned some HTML basics, it took me only about 15 minutes using Word 97 to get a basic Web page running locally on my desktop PC. However, when I moved the page to my embedded system and accessed it via my intranet and my PC's Web browser, I found that the page no longer looked the same. Where logos of Phar Lap and WinSystems had previously appeared on the screen (I wanted to give these companies a little exposure for helping with my project), there now were blank gray spaces. It seems I'd transferred my Web page's HTML code to the embedded system, but I'd forgotten to transfer the logos' GIF image files.

It was gratifying, though, that the system didn't crash; a lot of software with missing chunks would have bitten the dust. My Web browser (Internet Explorer) apparently has some fall-back options. After I moved the GIF files from my PC to the embedded system's hard disk using Phar Lap's makehd utility, the embedded system's Web page looked just like the host version.

My embedded Web page's spiffy look came at a price, however. For one thing, 15 GIF images had taken up residence on my embedded system, and they required a lot of data-storage capacity. For another, I found myself agonizing over which graphical background to put in my Web page, which color would look best, and generally how to give the page a real "professional" look. How easily we fall victim to the Internet's black hole of productivity! Playing with a Web-page layout for just a "short" time to make it look a little bit better is a kind of Internet equivalent of keeping up with the Joneses.

Remember, too, that it takes a lot of bandwidth to produce glitz. A graphics image can easily occupy 200 kbytes of data. That image might look impressive once a Web browser gets it loaded, but it takes time to load, and it uses some of your embedded system's valuable resources. Always ask yourself if the glitz is worth it. I did, and I ended up removing from my embedded system all the logos and special pages that describe my project's sponsors. Pages running on other Web sites can do a better job of that anyway. As mentioned earlier, the glitzy stuff can go on any Web server, not just your resource-limited embedded system.

A Web page on the fly

I further reduced the amount of data storage my embedded system needs by having the system generate its Web page on the fly, rather than retrieving a stored Web page from disk. Unlike a PC- or server-based Web page, in which all the sequential HTML code for displaying a Web page resides on a hard disk, my embedded system's on-the-fly Web page exists in the form of small chunks of C code. Calls from the C code to functions in an ETS library result in the generation of HTML code segments on the fly; together, these HTML segments create a Web page whenever it's requested by a Web browser. Multiple use of some code segments reduces the amount of disk space or memory needed to store the page.

If the concept of building a Web page on the fly is difficult to grasp, consider the creation of a page that contains a graphical table or matrix. Much of this table repeats itself: One cell is like another cell; one row of cells is like another row of cells. You don't have to store an HTML description of the entire page; you just have to send an HTML sequence that an inquiring Web browser can use to assemble an entire page. For an analogy, think about the use of loops in a C program rather than sequential in-line code. In a similar Web-page example, an inner loop can repeat cells, and an outer loop can repeat rows of cells. The amount of required HTML code is much less than for an entirely stored Web page.

Unfortunately, creating a Web page on the fly isn't easy. Fortunately, there are tools that can help. The tool I used, part of Phar Lap's ETS, is called (appropriately enough) HTML-On-The-Fly. This software, which you invoke from a C program, assembles chunks of HTML code and sends them to an inquiring Web browser to build an entire Web page.

I'm getting ahead of myself, though. At this point in the project, the only Web page I had produced was just a basic design, serving no real purpose. I had created it just to prove I could do it. I still needed to create a page that I could use for exercising my embedded system's Mystery Circuit. No use putting it off: I went back to the HTML grind and created an actual working page.

Running without a host

I had also, until now, been running in "host" mode. The host was transferring application code to the embedded system; the embedded system wasn't yet running independently. Now it was time to cut the umbilical cord. I copied the application code to a floppy disk, setting a nowaithost ("don't wait for host") switch on the ETS real-time kernel, and put the disk in the embedded system's floppy drive. I now had a true embedded Web server running on its own.

My next step was to address the problem of multiple users trying to exercise the Mystery Circuit simultaneously. If two people set the circuit's inputs in quick succession, the first person could see circuit outputs that correspond to the second person's inputs, not his own. That could make for a pretty difficult puzzle. To avoid this problem, I needed to allow only one Web surfer at a time to change the inputs and read the outputs. Phar Lap's ETS has resource-locking routines that make this easy. I just needed to identify the sections of C code where circuit I/O occurs and to call EnteringCriticalSection before the section and LeavingCriticalSection after it.

My LAN-based intranet system was now working, and I wanted to get back to the serial-connect implementation. There's so much potential in a direct serial connection between an embedded Web server and a PC with a Web browser. A PC-based Web browser can be a wonderfully versatile (and removable) "front panel" for an embedded system. If you have to change the user interface, you do it with software. You don't have to resort to crude measures such as removing a metal front panel, drilling an extra hole in it, adding a switch, and sticking on a Dymo label.

As I'd discovered earlier, though, the serial interface was surprisingly tricky. Phar Lap tech support and I went through all kinds of setup options without success. I also made an error along the way; earlier, I'd set up my Win 95 network to use TCP/IP, and now I was inadvertently using the same address for the serial link. As a result, Win 95 was routing my would-be serial connection to the LAN. About the time I discovered this, I also moved to a new version of the ETS real-time kernel, which Phar Lap was preparing for release. With a new IP address and the new kernel, I was able to make a PPP connection. It's a bit slower than the LAN interface but still quite usable.

Using the serial connection is easy; all I have to do is go into Internet Explorer and select "ETS Connection," the name I gave to the null-modem driver that I installed for my serial connection. Setting up the serial connection isn't so easy, though, although it's simple enough conceptually. Essentially, I had to fool Internet Explorer (via Win 95) into thinking it was talking to an Internet service provider through a modem instead of talking to an embedded system through a serial link. I did this by setting up the dial-up network in Internet Explorer's "My computer" folder and by installing a null-modem driver.

Moving to the Internet

With a serial connection and a LAN connection now working, it was finally time to try an Internet connection. For an Internet service provider, EDN chose TechOnLine. Because I'm in Oregon and TechOnLine is in Massachusetts, I packed up my embedded system and sent it across the country. Before I did, though, I changed the ETS kernel to give my system the Internet address it would have at TechOnLine. By the next morning, TechOnLine had connected the system to the Internet at its site.

From the very beginning, I could start my Web browser and exercise the Mystery Circuit on the other side of the country. The embedded Web server I'd implemented would accept circuit inputs from me and would show circuit outputs to me. However, I hadn't yet created a top-level Web page that included instructions for exercising the circuit, so no one else knew what to do with my embedded Web page. I started getting calls from EDN editors and people at TechOnLine wanting to know how to go about solving the Mystery Circuit puzzle. Naturally, without a diagram showing the circuit's connections, a solution would be impossible. Significant resources of the application were still missing.

Creation of a top-level Web page didn't take very long. I created the page, which is implemented on the same system as EDN's home page, by writing HTML code directly. Compared to creating an embedded Web page, it was easy, and there are lots of books that can provide all the instruction you need.

The top-level page for my system has three frames. One frame has links to my project sponsors' Web pages; a second shows an image of connections to the Mystery Circuit and includes instructions for exercising the circuit. The third frame comes from my embedded system; it accepts user inputs for the Mystery Circuit and displays resulting circuit outputs.

At last, the system was working with its own home on the Internet. All that remained was for someone to solve the Mystery Circuit puzzle. If you've got some time to spare, give it a try. You'll find it on EDN's home page at www.ednmag.com.

References

1. Quinnell, Richard, "Web servers in embedded systems enhance user interaction," EDN, April 10, 1997, pg 61.

2. Musciano, Chuck, and Bill Kennedy, HTML: The Definitive Guide, O'Reilly & Associates, Sebastopol, CA, 1997.

Acknowledgments

I'd like to thank the technical-support people at Phar Lap and Bob Burckle of WinSystems for their assistance in making this project possible.

| EDN Access | Feedback | Table of Contents |