Microcontroller Applications -> 'Internetworking' treads on MCU turf

'Internetworking' treads on MCU turf
By Olaf Pfeiffer, Founder, Embedded Systems Academy, John Rodrigues, Vice President of Sales and Marketing, CMX Systems Inc., Framingham, Mass., EE Times
May 21, 2001 (2:26 p.m. EST)
URL: http://www.eetimes.com/story/OEG20010521S0066

These days, it seems as if almost any product that requires an embedded microcontroller, microprocessor, microcomputer or digital signal processor (DSP) is suddenly a serious candidate for what is commonly referred to as "Embedded Internetworking." This term is used to categorize all embedded applications that require access to the Internet.

Some of the goals of Embedded Internetworking are anytime, anywhere control of an electronic device, self-maintenance of the device and pervasive, wearable computing.

There are, by far, more 8-bit processor-based products than those designed with larger processors, so it is only natural that engineers working on these products will soon hear a resounding cry from their marketing departments: "We need to get our 8-bit product on the Internet, now!" But do we really need a toaster with Web access?

And, what do we hope to gain by putting our appliances online? The answer is that everything needs to be put into perspective. Sure, it's hard to believe that a toaster or even a coffee machine would be substantially improved by an Internet connection. There are a number of circumstances, however, where networked appliances could provide tangible benefits, proving that there are good reasons for the development of such functionality.

One example is the deregulation of power utility services. Deregulation means that prices for power vary during the 24-hour day and that power is more affordable during off-peak hours, the timing of which can vary on a daily or even hourly basis.

If energy-hungry appliances, such as air conditioners, washing machines, dryers and dishwashers, could be designed to recognize off-peak hours themselves via online updates from the power utilities, they could actively help to lower their own operating costs.

For example, if a person did not need clothes and dishes washed and/or dried immediately, he/she could effectively program the machines to start the ope rating cycle as soon as they recognized an off-peak, lower-cost operating time. The current California energy crisis adds a new twist to this concept by highlighting the potential need to track not only optimal operating-cost time periods, but also actual power availability. Embedded Internet functionality, in essence, could be used to fine-tune energy consumption to minimize the necessity for widespread blackouts.

Obviously, if Embedded Internetworking features cost consumers more than they can potentially save, they will be a tough sale, unless additional benefits, such as self-maintenance, are part of the bargain. In such a scenario, a washing machine manufacturer, for example, recognizes that a product that has been on the market for a year could be improved with a software update. But how can that update be distributed to every customer? Sending a service technician to every home to replace the software would be too expensive. However, if the washing machine has Internet access, it could be prog rammed to regularly monitor the manufacturer's Web site for software updates and then download them automatically.

The benefits of Internet access for appliances also extend to commercial applications. Let's look at industrial coffee machines for restaurants as an example. If a machine were networked, once an order of coffee is entered into the register, a message could be sent to the coffee machine to brew one cup of fresh coffee of a certain type and specified strength. The machine also could send messages when it requires service, such as refilling beans or cups.

There are many potential applications for Embedded Internetworking. In general, most of these do not actually require that the Internet be the network that is to be used-it just facilitates the process by allowing the end user to access the embedded system with interface tools that are very familiar to him/her, such as a Web browser or e-mail program.

Eventually, the number of embedded electronic devices attached to the In ternet will grow at a faster rate than the number of online PC-style computers. This prediction is based on two facts:

• Embedded microcontrollers already outnumber PC-style processors by far. Even the PC itself comes with a variety of embedded microcontrollers in the drives, printers, modems, displays, keyboards and other peripherals.

• Even lower-end, embedded microcontrollers are becoming more powerful, providing enough processing power to handle networking tasks. In most applications, newer designs use a more powerful (faster or wider bus) microcontroller than the one used in the previous design. Networking functionality might already be built into the hardware (a free serial port could be sufficient) or can be added for a nominal additional cost.

So it is really just a matter of time as to when we will reach the point where the number of embedded controllers online exceeds the number of PCs online.

Of course, as with any new technology, challe nges exist. Because the Internet supports many different protocols and connection methods, one of the first decisions to be made regarding Embedded Internetworking devices is, which protocols and options are required for the application?

A careful evaluation of the different available protocols and applications is required to decide what is needed and what can be omitted. This is a crucial consideration because Embedded Internetworking devices often lack sufficient CPU and memory resources to handle the entire TCP/IP stack and all of its variations. Located in the middle of the entire communication stack, the TCP/IP layers ensure proper point-to-point communication and take care of the routing and delivery of packets. And, the smaller and more cost-effective an Embedded Internetworking device needs to be, the tougher it is to strip down the system to the bare essentials.

When implementing the TCP/IP protocol stack to medium- or low-performance microcontrollers, a number of functions normally used within the TCP/IP stack can be safely omitted, depending upon the specific application requirements.

Support for fragmentation is one of the first candidates we can consider dropping completely. In the IP layer, messages that are longer than 1,500 bytes are fragmented during transmission and then reassembled by the receiver. On an 8-bit microcontroller with a total address range of 64 kbytes, you don't want to waste any of your valuable code space. In any case, the device must generate an appropriate error response, if anybody tries to send a large, fragmented message to it.

Unfortunately, knowing exactly what to save and what to omit in a TCP/IP stack can be a daunting task for engineers who lack Embedded Internet programming experience. By far the fastest and easiest way to produce a more cost-effective TCP/IP stack is to look for a commercial software vendor that can provide a minimized TCP/IP protocol stack specifically optimized for 8-bit and 16-bit microcontrollers.

Impleme nting an embedded Web server atop the TCP/IP stack in your 8-bit processor will offer customers, support personnel and others a familiar graphical user interface for interacting with your product. A true HTTP Web server capability, as offered by CMX-MicroNet, will enable the display of HTML, graphics files, CGI scripts and Java applets on any of the standard browsers that your employees and customers use to access the Internet.

Web friendly

A virtual file system integrated with this type of Web server offers an easy way to integrate Web pages and other static portions of files that will be stored in the processor's ROM. Support for Web-form functionality will allow dynamic modification of Web page content to display values of inputs and also provide for the uploading of data to the Web server so that changes to outputs or uploads of data files can occur.

A number of methods exist to help minimize memory consumption with a Web server on an 8-bit device, including eliminating mul tiple directories and subdirectories in the file system, not providing caching for served files and shutting off log files for access statistics.

In fact, all static pages, graphics and other files can be kept on a regular Web server as long as the main entry page is kept on the embedded Web server.