Introduction
To align with the current trend of incorporating networking capabilities into everyday devices, our project incorporates a webpage interface for the Atmel AVR microcontroller. Initially, one of our main objectives was to develop a low-level network interface for the Atmel device, which involved controlling an ISA network card (as seen in the eAVR Project) to transmit UDP packets over the Internet. However, our plans underwent significant modifications once we discovered the SitePlayer device.
The SitePlayer device we utilized in our project incorporates a Crystal Semiconductors CS8900 Ethernet controller and on-board Flash memory, allowing it to host a compact webpage. Its compact size and footprint make it highly suitable for embedded systems applications, including our own. We established a connection between the SitePlayer device and the Atmel ATS8535 microcontroller unit (MCU) using a simple serial interface. The main challenge we encountered during this project was designing code that collects data from our sample peripheral devices (such as appliances), formats it appropriately, and outputs it to the webpage hosted on the SitePlayer device.
High level design
The materials we used 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 alternative connection for the SitePlayer
– Null Modem cable for the MCU-SitePlayer serial link
– Any additional parts required for the attached peripherals
The general execution scheme of our program is akin to a basic command interpreter. We have implemented a set of commands that facilitate input/output operations on the Atmel microcontroller’s peripherals. These peripherals include a set of LEDs, a temperature sensor and fan (as used in Lab 6), a photodiode for room-light indication, and an IR security beam. The IR beam is configured to trigger the opening of a door and incorporates 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
Our initial significant challenge involved establishing communication between the Atmel ATS8535 and the SitePlayer. To tackle this, we referred to the SitePlayer Software manual, which provided us with the necessary technical insights into serial data transfer to this device. Generally, each input/output (I/O) operation entails transmitting 2 to 4 bytes of data. This includes a command byte (such as Read or Write, along with address length specifications), one or two address bytes (depending on whether the data is addressed in the higher regions of RAM), and the actual data byte.
For instance, the printf commands showcased below demonstrate how we instructed 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)
Next, our focus shifted towards specifying the memory areas on the SitePlayer for the input command (16 bytes) and output result (32 bytes). To achieve this, our program utilized the Timer1 overflow interrupt to periodically poll the designated region of SitePlayer memory associated with the webpage input. Once we detected data other than zeros, we proceeded with command matching and executed the corresponding task. Each command generated two output strings: one for the webpage (32 characters) and one for the on-chip LCD monitor (8 characters). Serial transfers to and from the SitePlayer were accomplished using the UART receive interrupt. Configuring the initial memory mappings for HTML variable names necessitated the use of the proprietary SitePlayer software to compile .spi configuration files, with further details available in the provided documentation.
For two of our peripherals, we utilized the on-board ADC of the ATS8535 microcontroller. Since our temperature module operated with a gain of 4, converting the ADC readings to actual temperature values simply required dividing by 10 (as the ADC distinguished intervals of 4 mV). Additionally, we found it convenient and necessary to set up the temperature and infrared data collection on a polling loop basis. By doing so, when a “gettemp” or “door” command was received, we only needed to check the value of a register, eliminating the need for a complete analog conversion each time. Furthermore, the IR module incorporated a 1-second debouncer, meaning that for the occupancy counter to increment, the beam interruption must last for more than 1 second. Moreover, we designed the IR module to increment the occupancy counter only once per beam interruption, ensuring accurate counting while avoiding multiple increments for a single interruption.
Results of the design
Initially, our plan involved implementing an Ethernet board that could handle full UDP packets for sending and receiving data. However, once we obtained the SitePlayer device as a basis for our project, we were able to successfully incorporate all the intended “telnet-like” functionality that we had set out to achieve.
During the development process, we encountered some minor bugs related to the display of the telnet command results. Since we did not implement a true telnet interface, the webpage would often display the output from the previous command until the page was refreshed. However, we considered this a minor issue as the page automatically reloads itself every 5 seconds. Additionally, due to the fast operation of the Atmel chip, this bug was not always noticeable.
Our major challenges and time-consuming tasks primarily revolved around ensuring proper communication between the SitePlayer and the connected computer. Despite programming an IP address into the SitePlayer, there were instances when the accompanying PC failed to establish communication. Furthermore, occasionally, when programming the Atmel chip, the connection of serial cables would cause the SitePlayer to hang, necessitating a hard reset of the device and, at times, reprogramming its IP address via the serial port. It is worth noting that we encountered more issues in the lab environment compared to when the SitePlayer was deployed on an actual network, without a clear explanation for this discrepancy.
Overall, we were satisfied with the level of control we achieved with our design. The modular nature of our system allowed for easy addition of new components or replacement of existing ones. Any device that the Atmel chip could control through its pins could be integrated into our system by adding a new case in the code to handle the corresponding telnet control word. Consequently, once we had the first device working, we were able to swiftly incorporate most of the remaining devices within a few hours.
What you would do differently next time?
In the future, it would have been advantageous to have a stable network connection outside of the Phillips lab, as the lab’s network and computers were unreliable. Having a reliable network connection would have greatly facilitated the debugging process. Additionally, we were interested in exploring the possibility of using a standard telnet program to connect to the SitePlayer. However, achieving this would have required significant modifications to the SitePlayer, which might not have been feasible.
Another feature we would have liked to implement is a simple FTP interface for the SitePlayer/Atmel system. The development board had sufficient onboard RAM to accommodate this functionality, but we did not have enough time to work out the file transfers. This would have entailed adding a new command and returning the contents of the RAM to a variable on the SitePlayer. Although the SitePlayer has limited space for variables, approximately 760 bytes, we could have potentially found a way to store the files in the traditional web pages section of its memory.
