Web-based AVR Interface
IntroductionIn 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 designOur materials for this project included:
The following summarizes which commands the Atmel will support:
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.
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 18.104.22.168:
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
Results of the designOriginally, 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.
Webpage Code (the actual page that we loaded onto the SitePlayer).