dacs.doc electric

Close your eyes. Picture a web server. I’d bet that what comes to mind is at least a tower PC, if not an array of machines. Now, try going in the other direction--how small can a web server be and still do something useful? I’d bet that few of you went far enough. The topic of this article is a web server that the folks at NetMedia have come up with--the SitePlayer (www.siteplayer.com)--a 1" square, 2- chip web server with ethernet, serial and I/O connections. Not too long ago, this device was being referred to as the world’s smallest web server, but I doubt that distinction still holds true.

There are currently two contrary trends in the computer industry, exemplified by the thought exercise above: The most familiar leads to faster, more powerful systems with more functions; while at the other end of the spectrum is a trend to move intelligence and connectivity down the food chain--to devices that were never envisioned to be intelligent. Evidence of the latter trend includes the increased use of microprocessors in formerly dumb things: cars, appliances and the like; the spread of networking into the home and even in the underlying protocols of the internet itself. Most of us are using IPV4 (Internet Protocol--the IP part of TCP/IP), where one of the base design features is an address space based on a combination of 4 eight bit numbers
(the familiar dotted-quad address: xxx.yyy.zzz.aaa). Not long ago, it was realized that these addresses were running out, so IPV6 was developed, with a much larger address space-one that was half-jokingly characterized as being able to assign an IP address to every lightbulb in the world (something that might not be too farfetched!).

In a previous dacs.doc article (www.dacs.org/archive/0002/feature2.htm), I wrote about the use of embedded processors, using an example of distributed control for an audio system. That article addressed distributing the intelligence, but not the connectivity (a direct wired connection was used). Recently, I’ve been experimenting with more uses for my home network (100Mb ethernet wired to most rooms in the house) beyond the obvious internet connection sharing and music distribution. The siteplayer has opened up many new possibilities by providing an easy-to-use ethernet connection and a common communications protocol (http). First, I’ll describe the siteplayer in more detail, then outline some of the uses I’m developing.

The siteplayer itself consists of a Philips 89C51 microcontroller coupled with a Realtek RL1019AS Ethernet transceiver chip. Beside the ethernet port (meant to be hooked up to an RJ45 LAN connector with built-in transformer), there are eight general purpose I/O lines and a serial port. The siteplayer has 48Kbytes of flash memory to hold web pages and 1Kbyte of SRAM is available for storage. There is no conventional operating system available; instead, there is a small control program that supports internet protocols (which currently include ARP, ICMP, BOOTP, UDP, TCP/IP, and HTTP) and the way that it deals with web pages. Aside from some simple math functions which are used in conjunction with variable replacement on web pages (described below), the siteplayer has no real computational facilities available--if general processing is required, it would be expected to be provided by a companion processor.

The 48Kbytes of flash can be used to hold any web pages that fit (as well as the associated assets—for example graphics files and sound clips). Besides creating the web page, “programming” also involves defining variables (which are mapped to memory locations in the 1Kbyte SRAM space). A value can be associated to a variable through a communication on the serial port, or by mapping the variable to the address of one of the I/O lines, where a change in state on a given pin will be directly reflected in the variable’s value. On a web page, the use of a special leading character (‘^’) in front of a variable name results in the replacement of the variable with the value found at the associated memory location when the web page is delivered. Conversely, by use of the query parameters in an http get request, variable values can be directly set from clicks on a web page. This seems quite confusing at first, so a few examples might be in order:

• Assume that during programming, a variable called TEMP is defined. An external thermometer periodically measures the temperature and passes the value to the siteplayer using the serial port. The following HTML statement in a web page:

The temperature currently is ^TEMP

 

will result in the current temperature being displayed on the page (replacing the ^TEMP in the text string above).

• Assume that the goal is to be able to remotely monitor the on/off state of a device and that the device is able to place a logic high (‘1’) on one of the I/O pins when on and a logic low (‘0’) when off. If a variable named STATE is mapped to the I/O pin address and two graphic files are placed in the siteplayer (led1.gif for on and led0.gif for off), then the follwing HTML statement in a web page:
  
  <img src="led^STATE.gif>

would result in displaying the appropriate image file to show whether the device is on or off.

 

• Assume that the goal is to be able to set an LED to be on or off based on which link was clicked on a web page. The LED would be appropriately wired to an I/O pin and a variable named LED mapped to the address of the I/O line. The following link would turn the LED on:

Turn LED <a href="tr.spi?LED= 1">on</a>

 

and this one will turn it off:

 

Turn LED <a href="tr.spi?LED= 0">off</a> .

As you might guess, the discussion above only scratches the surface of what can be done. To summarize, the siteplayer allows both the setting and reading of variables and I/O connections through simple interactions with a web page. It should be noted that while these interactions would be done via a web browser most of the time, it’s a relatively simple matter to use http transactions from any sort of program to achieve the same results.
Now, what am I doing with these devices? As usual, none of my playing is absolutely necessary, but from a techie’s viewpoint, it’s fun.

1. Network connected character display: One of the items that’s been lying around my surplus collection for many years is a serially connected 16 character vacuum fluorescent display. This display is quite easy to read from a distance, but had turned out to be difficult to interface. The siteplayer has pre-defined variable "COM", which is directly mapped to its serial port. Any data assigned to the COM variable through an http transaction will be directly output on the serial port. I’ll be mounting this display in the kitchen, connected to my LAN through the siteplayer’s ethernet. Most of the time, one of my servers will be periodically sending weather information scavenged from the internet (to provide a real-time weather display in the kitchen). The siteplayer will also hold a web page that will allow my kids to send messages to the display from their computers (an alternative to the normal yelling back and forth that goes on around dinner time).

2. Remote temperature sensing: I’ve cobbled together a basic stamp with a Maxim (Dallas) 1620 thermometer chip, which will be mounted outside of the house. By having the stamp communicate with a siteplayer through the serial port as described above, I’ll be able to add the current outdoor temperature to my home web pages. This capability will be expanded to other forms of monitoring, once I figure out how.

3. Web interface for remote audio preamp: I’m going to attempt to replace the "physical knobs on a box" interface for the remote preamp I referred to earlier in this article with one that utilizes a web interface (I have an Audry internet appliance near where the box currently is). The siteplayer will be located near the serially controlled preamplifier, with a basic stamp in between to handle the protocol conversions. A web site will be loaded into the siteplayer that gives the normal control interface for a preamplifier (volume, bass, treble and the like) that will talk to the preamp through the basic stamp. This project will take a bit of work, but should be possible.

Hopefully, this article has started you thinking about the small end of the hardware spectrum and gives a preview of some of the things that are likely to start emerging on the consumer market in the future.