XML embedded Web support eases design

However, designers of resource-constrained embedded projects will find that a more efficient approach is to implement Web support directly in hardware. Options for such an approach range from full 32-bit processors plus Web servers, to cost-efficient hybrid solutions that combine lower power drains with high data throughput.

Currently, Web support is available for most major embedded architectures, including Z80, MIPS, ARM, X86 and others. Since thousands of different offthe-shelf embedded ICs exist, support options vary, so designers should investigate; sometimes it's software only, and often an external board is required to handle the network connection. Web support can be most cost-effective when the most important hardware component required for Web support-the Ethernet controller-is included on the chip, as is the case with the Zilog eZ80 Acclaim microcontroller.

An overview of XML embedded Web support using the eZ80 Acclaim shows that the device is a Web-capable microcontroller that combines a high-performance embedded processor with a complete, Internet-ready software stack to create a complete embedded connectivity system. The standard TCP/IP network protocols are supported within the software stack, along with Ethernet and serial drivers.

Web support implemented on an embedded processor differs from a Web server running on the PC architecture. In contrast to the standard personal computer and Internet-based Web setup, where Web pages are maintained on a mass-storage device such as a disk drive, the Web pages created by an embedded processor are accessed as embedded data elements. Resources for an embedded implementation are constrained, both in terms of memory and power. An XML-capable, Web-enabled embedded system has got to be leaner, meaner and smarter than its bloated PC counterpart.

One benefit of folding Web support into an embedded application is that it frees engineers from the time-consuming burden of user-interface design. That's because embedded Web pages, written in HTML/XML and converted to C/C++ code, provide ready-made user-friendly interfaces that have the ability to support complex embedded systems.

XML, which is such a boon to data exchange, is the Extensible Markup Language. XML provides a processor-independent way of encoding data for interchange between diverse systems. XML uses defined tags to place coded definitions inside Web pages. Designers are developing different sets of tag definitions for different application environments that use XML syntax. For example, available tag sets include vocabularies for electrical engineering, e-commerce, multimedia data and straight document info.

It's possible to transmit XML documents to and from other systems in a number of ways. For one, they can travel as HTTP objects. This means that support for Web services such as Simple Object Access Protocol or XML-RPC must be incorporated into the server.

Including XML and HTML support in embedded systems requires special provisions in the software tools chain. Specifically, the compiler-linker tied to the embedded part must be designed to allow the XML code to be embedded within the application program's C-language or assembly code.

In the real world, accessing the XML capability is fairly easy-the programmer incorporates a bunch of "#include" statements into his or her programmer. That's how it's handled in tools such as Zilog's ZDS II developer's suite, which works with the eZ80 Acclaim. Many developer's suites also include sample HTML/XML pages, a feature which greatly simplifies any project.

Implementation angle

Despite the easy path the use of "#include" statements provides, developers must take into account several other software elements to access embedded Web functionality. First off, in the applications code, the developer must incorporate a command that calls an HTTP initialization function. However, the most important-and lengthiest-part of the process requires Web pages that will be accessed by the embedded system's user to be built into the Web server.

Let's take this step by step. In operation, the Web page gets cranked up in the embedded processor when the code being executed hits that initialization function. The initialization function looks something like this: http_init (http_defmethods, http_defheaders, website, port).

For our example, the most relevant portion of this command is the "website" parameter, which the user creates and which defines the Web pages that will be included in the site the embedded processor will support.

Before we delve deeper, it's important to note that two categories of Web pages exist: static HTML pages and dynamic HTML pages. Static Web pages don't change. Many corporate Web sites, which feature blurbs about their services and product catalogs, are basically static; all visitors to the site view the pages the same way. Conversely, dynamic HTML pages change their content based on user feedback. Search engines and online banking sites typify these types of pages, where the view changes depending on data the user enters into a field.

The implication for our embedded Web server is that static pages are easy to create; they can be saved as a string of characters within, say, a C-language software program. (They often can't be saved as simple ASCII text files because pure embedded devices don't have file systems.) On the other hand, dynamic pages can't be saved as files because their content changes. They have to be generated at run-time.

This means that dynamic files must be pieced together from a list of functions or parameters. When the Web page is called up, the list of C functions, each of which corresponds to a section of the on-screen Web page, is executed.

This generates the XML/HTML page, which then moves on to the browser. It is via these function calls that a programmer can make an embedded system do the type of stuff it's called upon to do-for example, read a temperature sensor and generate a page that displays the temperature reading to the user. It is also within such function calls that a programmer writes code that will read in user input, which is typed into a form embedded within the Web browser. Based on the information in the form, the programmer can adjust a thermostat, turn on a motor, and so on.

Accordingly, the "website" parameter defines an array that makes up the structure of our Web pages. (Note that there must be one "webpage" parameter for each page in the Web site.)

Along with the initialization function, a few other nitty-gritty details have to be taken care of before an embedded Web page can be transferred.

For example, a time limit for the connection has to be set, some network processes have to be launched, and a shell must be set up and then opened on the serial port so commands can be sent back and forth. In the embedded Web server's program, the command lines that have to be included look (in abbreviated form) something like the listing at top right.

How, specifically, does the HTTP server receive the function call and return a requested Web page? Like most network protocols, HTTP uses the client-server model.

An HTTP client opens a TCP connection and sends a request to an HTTP server. The request includes a universal resource identifier that identifies the Web page of interest. The server then returns a response message containing the resource that is requested.

Now we've arrived at the moment of truth, where the program finally adds the most important element-the Web page itself. An abbreviated chunk of what that code might look like is shown in the list at right, bottom.

This elegant Web-on-a-chip solution allows universal connectivity over a TCP/IP network, enabling easy system control, simple code updates and better compatibility.

Dick Jensen is director of development tool platforms and third-party programs at Zilog Corp. (San Jose, Calif.).

See related chart

See related chart

See related chart