|
HTTP Daemon on Renesas M16 Board
URL: http://www4.ncsu.edu/~mchiang/project.html Members Goal Overview Approach Current Status Links |
|
Brandon Ellison (bjelliso@ncsu.edu) Mu-huan Chiang (mchiang@ncsu.edu) |
| The goal of this project is to utilize the Renesas M16 board to present data to a user from a Mote device. The Renesas board will convey the data from the Mote in an HTTP format for easy deciphering. This requires integrating all of the required libraries for Ethernet communication, modifying the underlying file system to allow for new Mote data and formatting the data into a readable text. |
Overview:
This project will use several pieces of hardware and software:
1) The Bekeley Mote*
Running a TinyOS routine to gather sensor data*
2) The Renesas M16 board
Running a sensor data gathering routine to interface to the Mote*
Running an HTTP daemon for showing data results
Maintaining a file system for web data
3) The Renesas M16 wireless communications board*
Providing the Zigbee connectivity*
4) The Renesas M16 add on communications board
Providing the Ethernet connectivity
5) A standard PC
Retrieving data (in HTTP format) from the M16 board
| *Note: The M16 does not support a connection to both the Communication board and the Wireless board. This prevents the project from being completely functional. In talking with Professor Mueller, we are allowed to hard code the communication to the Mote such that sensor data is generated on the M16 and the rest of the project proceeds as normal. This removes the Mote and Zigbee from the project. |
|
The first part of the project is to install all of the software and required libraries for the M16.
The next step is creating the project file containing the base functionality with Operating System
along with the communication libraries. This will be validated to make sure it provides the proper
opreation.
Pieces that need developing:
TFAT file system installation and usage
|
|
October 31, 2005 (Brandon and Mu-huan) The development tools and required libraries have been installed. A sample project has been created that has all of the Ethernet functionality including TCP, UDP and the HTTP server. This code has compiled, but we do not have the necessary hardware to test it with. (Another group has the hardware and we have not had access to it at this point.) (Mu-huan) There is a basic file system given as part of the HTTP server example code. This file system does not allow for the addition of deletion of files, which is okay for this project. However it also does not allow for file writing, file growing or file shrinking. These pieces will be modified to add functionality. This is accomplished by creating an array of memory blocks and generating a file pointer structure similar to a FAT file system. This will allow files to be written to generate the web pages needed for this project. The file system is understood and the code to write/update files in memory is being added. (Brandon) At the same time, the data from the "Mote" will be written to a data file. This file format will be fairly basic, but written in a binary mode. This file will be merged (using a formatting routine) with the template.html file to create an index.html file. This file will be used by the http server as in the sample code. The structure of this file is now known and the code to write it is being developed. (Both) Since hardware for this is scarce, we must find a way to test some of these pieces without the actual M16 hardware. This will require creating some C programs that can mimic the data format of the M16 and be run under an environment like Cygwin. This will allow us to test the file system and merging routines without having hardware.
Short status:
Next steps: |
|
November 15, 2005 (Mu-huan) The file system API (Application Programming Interface) has been completed. Also, the file system has been completely coded and tested in a non-H8 system. The code was proven to compile under both a H8 environment and a non-H8 environment. Test code was written to stress the file API in a non-H8 environment and this proved useful in finding several issues that have been resolved. (Brandon) The Mote API has been completed and the "Other" API has been completed. The "Other" API is the group of functions that falls outside of the Mote and File system APIs. The Mote API is mostly a placeholder for future work when both the wireless board and Ethernet board could be attached to the H8 board. This will fall outside the scope of this project, but at least the project is structured correctly. (Both) Once Brandon's work is complete and tested in a manner similar to the file system, we will contact the other team for some time on the H8 board to test out our project. Also the report work needs to begin for the project submission.
Short status:
Next steps:
Links: |
|
November 28 & 30, 2005 (Mu-huan) The file system API (Application Programming Interface) has been updated to support directories, including adding and removing directories as well as being able to move files from one directory to another. These updated API calls have been completely coded and tested in a non-H8 system. The code was proven to compile under both a H8 environment and a non-H8 environment. Test code was updated to stress these new API calls and has been effective in removing all known bugs. (Brandon) The Mote API and the "Other" API are still fixed and the code for these APIs has been completed. New test code has been added to the file system testing code to call out the Mote API and also to call upon the merging function repeatedly to stress that function. This has been debugged in a Cygwin environment and has been proved to work. (Both) As of November 28: The report and presentation work has been completed and we are ready to present our project to the class and instructor. What remains is to get a hold of a Renesas SKP Comm board and test our project on it. (Both) As of November 28: As far as open problems, the main function of the Renesas code has not been tested to make sure it is accurate. This will be addressed when the HW is available. Also, not all functions do buffer overflow and bounds checking. This could be improved upon, but all test cases have been proven to work, even in large iterations. It would take unusual input to present an problem. (Both) As of November 30: We were able to get an M16 + COMMs board in the lab, we installed our code and immediately ran into problems. After a few hours of debug (which involved reconfiguring the tools a bit) we found the problem was in the basic string libaries. The string libraries are expecting 'near' pointers and some of our strings are 'far' (const). Once we rewrote these library functions, the problem resolved itself. The only remaining issue was that some of the FAT indexes are hard-coded in the https daemon, so we re-ordered our file creation to make it line up with this. This saved us from having to modify the daemon code. The project is working correctly on the hardware now. The preliminary debug using CygWin kept our lab time to a minimal.
Short status (Nov 28):
Short status (Nov 30):
Future Work:
Links: |
Links:
Berkeley Mote
Tiny OS
Renesas M16 SKP
Renesas M16 Comm Board
HTTP Protocol
TFAT File System