Web-based AVR Interface

Marc Daniels Scott Hartranft

Introduction

In the vein of today's trends to embed networking cababilities into simple appliances, our project implements a webpage interface for the Atmel AVR microcontroller. One of the original motivations of this project was to develop a low-level network interface for the Atmel device, specifically by controlling an ISA network card (see the eAVR Project) to transmit UDP packets across the Internet. We greatly modified our original plans once we found out about the SitePlayer device:

"World's Smallest Ethernet Web Server"

This board features a Crystal Semiconductors CS8900 Ethernet controller and on-board Flash memory to host a small webpage. Its extremely small footprint makes this device ideal for a embedded systems applications such as ours. It also uses a simple serial interface, which we've connected to the Atmel ATS8535 mcu. The major challenge of this project was to design code that gathers data from our sample peripheral devices (appliances) and formats and outputs to the SitePlayer's webpage.

High level design

Our materials for this project included:

Atmel ATS8535 microcontroller
STK200 evaluation board (spec sheet pdf)
SitePlayer Ethernet Webserver device (spec sheet pdf)
8-digit LCD display for on-site monitoring at the mcu.
Crossover Ethernet connection or other connection for the SitePlayer
Null Modem cable for mcu-SitePlayer serial link
Any parts needed for the attached peripherals

The general scheme of our program's execution is that of a primitive command interpreter. We have a set of commands that will perform I/O on the Atmel's peripherals: a set of LEDs, a temperature sensor and fan (from Lab 6), a photodiode room-light indicator, and an IR security beam. The IR beam can be used to trigger an open door and is currently configured with a debouncing state machine to increment a room-occupation counter.

The following summarizes which commands the Atmel will support:

- status: Returns the status of the SitePlayer web interface.
- greenled[on/off]: Toggles the Green LED on the SitePlayer
- redled[on/off]: Toggles the Green LED on the SitePlayer
- led[X], 0 < X < 6: Toggles the Xth led on the STK eval. board.
- gettemp: Returns the current room temperature, per temperature module.
- lights: Returns the status of the room lights, per photodiode.
- fan[on/off]: Toggles the fan, which cools the temperature module.
- door: Returns the current room-occupancy counter, per IR security beam.

If a command is mistyped, or an input is erroneous, the Atmel will return "badCmd!" to the LCD monitor and a "Syntax Error" output to the webpage.

Program/hardware design

The first major task we faced was sending and receiving data from the 8535 to the SitePlayer. We used the SitePlayer Software manual to understand the technical details of serial transfer to this device. Basically, each I/O operation takes 2-4 bytes: A command byte (like Read or Write with address length specification), an address byte or two (depending on whether we're addressing data in the higher regions of RAM), and the actual byte of data. For example, the printf commands below tell the SitePlayer to set the IP address to 128.84.235.244:

printf("%c",0x93); // Command byte: Write 4 bytes using two-byte addressing printf("%c%c",0xE6,0xFF); // Address byte: Begin writing at 0xFFE6 printf("%c%c%c%c",128,84,235,244); // Data: 128,84,235, and 244 (the IP address)

Now, we just needed to specify memory areas on the SitePlayer for the input command (16 bytes) and output result (32 bytes). Our program used the Timer1 overflow interrupt to poll the region of SitePlayer memory corresponding to the webpage input. So once we receive something other than 0's, we do our command matching and carry on with the specific job. In each command we produce two output strings, one for the webpage (32 characters) and one for the chip-side LCD monitor (8 characters). For the actual serial transfers to and from the SitePlayer, we employ the UART receive interrupt. Also, the details about how to configure intial memory mappings for HTML variable names involve using the proprietary SitePlayer software to compile .spi configuration files, the details of which can be found here.

For two of our peripherals, we used the 8535's on-board ADC. Since we were using a gain of 4 on our temperature module, conversion to the actual temperature was just a simple division by 10 (the ADC discriminates on intervals of 4 mV). Also, we found it necessary and convenient to set up our temperature and Infrared data collection on a polling loop basis. This way, when a gettemp or door command is received, we need only to check a register value, not carry out the entire analog conversion. Also, the IR module has a 1-second debouncer, so if it were used on a door, the beam must be interrupted for over 1 second before the occupancy counter is incremented. Also, we only want to increment this counter once per beam interruption--this is another feature we decided to build into the IR module.

Results of the design

Originally, we had planned on implementing an ethernet board that would have been capable of sending and receiving full UDP packets. Instead, once given the SitePlayer to use as a basis, we were able to implement all of the "telnet-like" functionality, which we had set out to implement.

We did have some minor bugs in the actual display of result of the telnet commands, since we did not implement a true telnet interface. Since the web page simultaneously sends the new command to the input variable and reads the "output" from the output variable in its memory, it is usually displaying the result of the previous command, until the page is refreshed. However, we feel this is a minor bug, as the page will reload itself after 5 seconds anyway. Also, the Atmel often runs so fast that this bug is not always seen.

Our worst problems and most time spent were getting the SitePlayer to recognize the fact that it should talk to a computer. There were many times when, even with an IP programmed into the SitePlayer, the accompanying PC would not talk to it. Also, occasionally when we programmed the Atmel chip the SitePlayer would hang up due to the serial cables being connected. This would cause the need for a hard reset of the SitePlayer, and occasionally, a reprogramming of its IP through the serial port. We had far more problems in the lab than when we actually placed the SitePlayer on a real network, however - we do not have an explanation for that behaviour.

Overall we were pleased with the control we had. Our design was also very modular, so adding further components or replacing existing ones is quite simple. Anything that the atmel can control on its pins can be controlled by our system, but adding another case in the code to look for the telnetted control word. As a result, once we had the first word working, we were able to add most of the rest of our devices in only a few hours.

What you would do differently next time?

For the future, we would have had a real network connection, somewhere exterior to the Phillips lab, which has a very unreliable network and even less reliable computers. Having a stable network connection would have made debugging much easier. Also, we would like to see if it would be possible to use a standard telnet program to connect to the SitePlayer. This would have involved some heavy modification of the SitePlayer however, and may not have been possible.

We also would have liked to implement a simple FTP interface to the SitePlayer/Atmel. There is sufficient RAM on board the development board to allow such a task, but we did not have time to work out the transfers. It would have involved adding another command, and returning the contents of the RAM to a variable on the SitePlayer. There is very limited space for variable on the SitePlayer, only about 760 bytes worth, but we may have been able to find a way to store the files in the traditional web pages section of its memory.

Appendix

Source Code
Schematic
Webpage Code (the actual page that we loaded onto the SitePlayer).