Design and Development of ARM Processor Based Web Server

Design and Development of ARM Processor Based Web Server V.Billy Rakesh Roy 1, Sanket Dessai 1, and S. G.Shiva Prasad Yadav 1 1 M S Ramaiah School of Advanced Studies in Collaboration with Coventry University (UK)/Embedded Design Centre, Bangalore, India Email: {rakesh.voola, sanketdessai0808, shivaspy}@gmail.com Abstract As the World-Wide Web (WWW) continues to evolve, it is clear that its underlying technologies are useful for much more than just browsing the web. Web browsers have become the de facto standard user interface for a variety of applications including embedded real time applications such as Remote Data Acquisition System. This brings in a need for web services being deployed on various embedded processors such as Advanced RISC Machine (ARM) in real time context. The main aim of the project is to develop an embedded web server using ARM9 processor and a Real Time Operating System, µc/os-ii. µc/os-ii is used to monitor all the tasks of the web server. Embedded C language has been used for the software implementation of the embedded web server. The web pages which are required for the web server were developed using HTML. The µc/os-ii was successfully ported on the ARM and the web server application is configured with the operating system (µc/os-ii). Both, the operating system and the web server application are ported on the ARM9. This embedded web server is tested for its working, using a data acquisition web application hosted over a network of PC's. This embedded web server which is developed by using Embedded C language can be beneficial for mission critical applications, remote data acquisition systems, ATM network and more. The developed web server accelerates business performance by automating and orchestrating processes across total enterprises. Enterprise users can collaborate more flexibly and cost-effectively with business and trading partners. Index Terms Embedded Web Server, µc/os-ii, ARM, Web I. INTRODUCTION A web server is a system which hosts a web site and provides services for any requesting clients. The generalpurpose web servers compose of an operating system, the web pages or the application and a huge amount of memory and sometimes a special hardware. Fig 1. Client - Server Architecture 94 Fig 2. Embedded Web Server Architecture Fig 1. shows a typical client-server architecture where, the client accesses the server through the LAN router and the Internet. Whenever, the client wants to access the sever, it sends the request to the server, this request is taken by the router, which is connected to the Internet. The web processes the request made and finally connects to the desired web server, access the requested data and sends the data to the client. Embedded Web Servers: General web servers, which were developed for general-purpose computers such as NT servers or Unix and Linux workstations, typically require megabytes of memory, a fast processor, a preemptive multitasking operating system, and other resources. A web server can be embedded in a device to provide remote access to the device from a web browser. The embedded system can be utilized to serve the embedded web documents, including static and dynamic information about embedded systems, to web browsers. This type of web server is called an Embedded Web Server. An embedded web server is a microcontroller that contains an Internet software suite as well as application code for monitoring and controlling systems. Embedded web servers are integral part of an embedded network and paves way for faster time to market products. Fig 1. Shows the general-purpose web server where, it requires a huge amount of memory, special hardware, software and an operating system. An embedded web server can replace the Fig 1., which is a single hardware with an RTOS and the application. Fig 2. Shows typical embedded web server architecture. The web server is the board that has the application and the RTOS (µc/os-ii).

The operating system manages all the tasks such as sending the HTML pages, connecting to new users etc. The RTOS manages all the required tasks in parallel, and in small amounts of time. Web-based management user interfaces using embedded web servers have many advantages: ubiquity, user-friendliness, low development cost and high maintainability. Embedded web servers have different requirements, such as low resource usage, high reliability, security and portability, for which general web server technologies are unsuitable. There are also design issues such as HTTP and embedded API. II. DESIGN A. Design of the System Flow Fig 3. Shows the basic block diagram of the embedded web server. The necessary requirement analysis is done on the RTOS, web server, TCP/IP and the target board. Based on the requirement analysis, the µc/os-ii is configured, as per the target board. After configuring µc/os-ii, the port for STR9 is generated and targeted to STR9 using Keil uvision3 tool using hyper terminal. The target along with the RTOS is tested, by booting the target with the RTOS. The application is written and is made specific to the RTOS and both the web server and the RTOS are ported on the target. The web server application is tested for it s functioning. B. System Design The Fig 4 gives the overall system design. The main components of the system are Hardware, RTOS, HTML Pages, Transfer of Data. Hardware: The hardware used for embedded web server is ARM9 based board. The board has the html pages saved on it. RTOS: The application runs in the form of tasks. Each user connecting to the server is treated as a task. To manage the users, connections, an operating system is required, that performs the operations in real time. The embedded web server is implemented using µc/os-ii a powerful but small RTOS kernel. It is highly CPU independent and has been ported to numerous microprocessor platforms. HTML Pages: To interact with the clients, the client has to send the data to them. In the embedded web server, web pages are selected as the media of interaction. The web pages are designed using HTML. The designed web pages look as in the Figure 5. Fig 3. Basic Design of the System Fig 4: Overall System Design 95 Fig 5. Designed Web Pages C. Porting µc/os-ii INCLUDES.H: INCLUDES.H is a MASTER include file and is found at the top of all.c files. INCLUDES.H allows every.c file in the project to be written without concerns about which header file will actually be needed. The INCLUDES.H includes header files that are not pertinent to the actual.c file being compiled. OS_CPU.H: OS_CPU.H contains processor and implementation specific #defines constants, macros, and typedefs OS_CPU_A.ASM: A µc/os-ii port requires that need to write four assembly language functions: OSStartHighRdy (), OSCtxSw (), OSIntCtxSw (), OSTickISR (), OSStartHighRdy () function is called by OSStart () to start the highest priority task ready-to-run. OSStartHighRdy() assumes that OSTCBHighRdy points to the task control block of the task with the highest priority OSCtxSw() is executed when an interrupt is encountered. OSCtxSw() is a interrupt service routine. The sequence of events that leads µc/os-ii to vector to OSCtxSw() is as

follows. The current task calls a service provided by µc/os-ii which causes a higher priority task to be ready-to-run. OSIntCtxSw() function is called by OSIntExit() to perform a context switch from an Interrupt Service Routine. OSIntCtxSw() is called from an ISR, it is assumed that all the processor registers are already properly saved onto the interrupted task s stack OSTimeTickHook(). The only function that is actually necessary is OSTaskStkInit(). The other five functions must be declared but there s no need to contain any code inside them. OSTaskStkInit() function is called by OSTaskCreate() and OSTaskCreateExt() to initialize the stack frame of a task D. Compilation and Porting Procedure for µc/os-ii on STR9: All the required files of µc/os-ii are copied on a single folder and the code is compiled using the ARM specific cross compiler. The output of this is the hex file that is to be ported on to the board. The generated hex file is loaded onto the target using the hyper terminal. The following steps are to be performed to load the code on the target. Open hyper terminal. The connection settings of the hyper terminal are as below. Bits per second 57600 Data bits 8 Parity None Stop bits - 1 Flow Control Hardware The null modem cable from the serial port on the host-pc is connected to the target development board The RJ-45 socket on the development board is connected to the host-pc using a cross-over Ethernet cable The power cable is connected to the power socket of the target development board and the other end is connected to the USB socket of the PC. Now, in the terminal window, it can be seen the U-Boot startup messages attempting to tftpboot over the network once power is applied to the target hardware Hit any key to stop tftpboot autoboot, as the environment settings for the target hardware must first be configured E. Booting from on-board Flash and Running the Developed Application on Board: Start the hyper terminal Set the BootOs variable to boot the kernel image from Flash memory 0x40000. Upon a reset the kernel will boot from Flash. ARMcore> BootOs 40000 ARMcore > saveenv To boot the kernel from Flash through the hyper terminal program without resetting the target hardware, enter the following command: ARMcore> Bootm 40000 Successful kernel start-up will return a bootup message in the hyper terminal window showing the complete system configuration information. At the end of these initialization messages the login prompt can be seen The configuration file and the kernel image which is to be ported on the target processor has to be copied from the host pc on to the board using the using a tftp Ethernet connection into RAM ARMcore@root> tftp get ip:filename destination:filename The application which is copied from the host pc is a kernel image which is compiled in such an environment that it supports the target. The kernel image which is the developed application supports the board, can be run on the board my giving the below command ARMcore@root>./webserver-arm All the steps above are to be performed and the target will be loaded with the required OS and the application. F. Embedded Web Server Process Structure: The Embedded web server is a finite state machine (FSM), which processes an HTTP request as a sequence of discrete steps. Figure 6 shows the finite state machine for the embedded web server. Fig 6: Embedded Web Server Process Structure In order to support multiple connections in a single thread environment, multiple finite state machines are run by a scheduling system that uses a lightweight task structure, which consists of a pointer to the function being run, a variable holding the state in the finite state machine, and a flag indicating whether the finite state machine can be run or blocked. The scheduling system allocates an available finite state machine for an accepted connection, checks each finite state machine to see if it is blocked or runable and moves the finite state machine 96

one step if it is runable. Each state in a finite state machine can check for the presence of data that is ready to be processed at the entry point; if none is ready, the finite state machine can block itself until data arrives. When data becomes available at the entry point, the finite state machine can then be unblocked so its handler can perform the task of state, and turn over the result to the next state by changing the state flag and pointer to the handler. II. EXPERIMENTAL SETUP A. Experimental Setup of the Embedded Web Server: The experimental setup of the embedded web server is shown in Fig 7. The target is connected to the ethernet controller of the network, the power to the target is given through USB and the debugger is connected to the USB of the system and the other end to the board. B. Integrating RTOS and Embedded Web Server The main part of the embedded web server is the RTOS handling the web server application. Whenever, a connection is established, a new task is created using Fig 7: Experimental Setup Fig 8: µc/os-ii and Embedded Web Server Tasks Fig 9: Booting the target using µc/os-ii µc/os-ii. And the web server application is executed for that user s application, running in a task. When a new connection is established, a new task is created and the user s application is executed in a separate task as a separate application. This process is continued for all the users connecting to the server. Fig 8 shows the flowchart of the embedded web server and the RTOS, managing the incoming connections. C. Porting the Web Server The Embedded web server application and the RTOS are ready and are to be ported on the target. The porting is done using Keil uvision3 compiler. Now, the code is loaded on the target and the target is configured over the network, to work as an embedded web server. D. Testing the Embedded Web Server Testing: Initially, the target is tested for the working of operating system. This is done by booting the target using the hyper terminal. Fig 9 shows the target booting using RTOS. After the target is successfully booted with µc/os-ii, it is tested over the network using ping command. Fig 10 shows the embedded web server, responding to the ping command made by the client. Now the embedded web server is responding to the clients, request is made to the server, embedded web server, by typing the IP address of the server in the client s browser. The user has to enter 10.1.1.26 IP to access the server. This request is taken by the operating system of the client and given to the LAN controller of the client system. The LAN controller sends the request to the router that processes and checks for the system connected to the network with the particular IP address. If the IP address entered is correct and matches to that of the server, a request is sent to the LAN controller of the server and a session is established and a TCP/IP connection is establishes and the server starts sending the web pages to the client. Fig 11 shows the client entering the IP address of the server and the server send the html page to the requested clients. Fig 12 shows various clients connecting to the server and getting the html page. 97

web server replaces the PC, which is required for remote labs with special hard- and software. Fig 10: Pinging the Embedded Web Server over the network Fig 11: User Entering The IP Address Fig 12: Application Running on Different Systems on Network CONCLUSIONS The embedded web server that has been designed can be used in educational institutions, offices and many other places. For web-based network element management provide an administrator with a simple but enhanced and more powerful user interface without additional hardware. Software contention and architectures can significantly affect web server performance. Poorly designed and configured software architectures might even generate high response times while the physical resources display low utilization. A remote user only requires a common Internet browser to carry out experiments on real hardware. The embedded REFERENCES [1] David Brash, The ARM Architecture Version, ARM White Paper, January 2002 [2] Brian W. Kernigan and Dennis M.Ritchie, The C Programming Language (ANSI), Prentice Hall, second edition, 2001 [3] Tao Lin,Hai Zhao,Jiyong Wang,Guangjie Han and Jindong Wang, An Embedded Web Server for Equipment,School of Information Science & Engineering, Northeastern University, Shenyang, Liaoning, China [4] Yanzheng LI, Shuicai WU, Jia LI and Yanping BAI, The ECG Tele-monitor Based on Embedded Web Server, Biomedical Engineering Center, Beijing University of Technology Beijing, China [5] Hong-Taek Ju, Mi-Joung Choi and James W. Hong, An efficient and lightweight embedded Web server for Web-based network element management, International Journal of Network Management, pp. 261 275, Oct 2000 [6] Nick Witchey, Designing an embedded web server, Applied Computing Technologies, Applied Computing Technologies, April 2000 [7] Kyle Norman, Integrating Web Servers in Embedded Applications, Luminary Micro Applications Engineer, Luminary MicroWild Basin, Suite 350 Austin [8] CACH Petr and FIEDLER Petr, Ethernet interface in application, Department of Control and Instrumentation, Brno University of Technology, Božetěchova, Czech Republic [9] Ian S. Schofield, David A. Naylor, Instrumentation Control Using the Rabbit 2000 Embedded Microcontroller, Astronomical Instrumentation Group, Department of Physics, University of Lethbridge, 4401 University Drive West, Lethbridge, Alberta, T1K 3M4, Canada [10] Andrew S. Tanenbum, Computer Networks, Aderson Winsley Publications, Vol.3, 2004 [11] ST Electronics, STR91xF ARM9 -based microcontroller family Reference Manual, September, 2006 [12] Jean J. Labrosse, MicroC/OS-II The real time kernel, R & D Publications, second edition, 1992 [13] Deitel, Harvey M. and Michael S. Kogan, The Design Of OS/2, Addison-Wesley, second edition, 1992 [14] Mi-Joung Choi, Hong-Taek Ju, Hyun-Jun Cha, Sook- Hyang Kim and J. Won-Ki Hong, An Efficient Embedded Web Server for Web-based [15] Network Element Management, Dept. of Computer Science and Engineering, Pohang Korea [16] Krithi Ramamritham, John A. Stankovic, Scheduling Algorithms and Operating Systems Support for Real-Time Systems, Proceedings of IEEE, vol. 82, No. 1, pp. 55-67, Jan. 1994 [17] http://www.st.com,(august 2007) [18] http://www.arm.com, (December 2007) 98