ETHERNET - BASED WIRELESS VITAL SIGNS MONITORING SYSTEM

A SPECIAL PROJECT

Presented to
The Faculty of Electrical/Computer/Electronics and Communications Engineering
College of Engineering
Mindanao State University - Iligan Institute of Technology
Iligan City

In Partial Fulfillment of the Requirements for the Degree

BACHELOR OF SCIENCE IN ELECTRONICS AND
COMMUNICATIONS ENGINEERING
and
BACHELOR OF SCIENCE IN COMPUTER ENGINEERING

KISTER GENESIS M. JIMENEZ

DYL THERESE A. MESINA
ARVIN D. MIRANDA

Engr. Lope Ben C. Porquis

Adviser

March 2009
 ABSTRACT

This special project develops an Ethernet – Based Wireless Vital Signs

Monitoring System that will measure body temperature and will simulate a pulse rate

data through a wireless data acquisition device and then send the data to a web server that

can be accessed via its local network.

The temperature readings are achieved by using a LM35 temperature sensor along

with the analog to digital conversion capability of the PIC16F877A. The data acquisition

device can handle temperature readings ranging from 2 – 150 degrees Celsius though

typical body temperature is only around 36 – 42 degrees Celsius. The data is sent from

the data acquisition device to the web server via Bluetooth using the EGBC – 04

Bluetooth module. The typical wireless range of the Bluetooth module is ten (10) meters

in an area with no obstacles. Using WIZ810MJ network module, the web server can then

be accessed from the local network that it is connected to. The web server can display

data from four different data acquisition devices and will update the data being displayed

every five seconds.

 ACKNOWLEDGEMENT

The researchers would like to thank first and foremost our God Almighty for His

never ending love and presence in our everyday lives. We thank Him for always guiding

us especially during the time when our special project was still under development. We

would never make it this far without Him.

We would also like to thank our ever so loving families namely the Jimenez

family, Mesina family, and the Miranda family, for their overwhelming support and

encouragement. Their hopes and aspirations for our futures served as our inspiration, our

driving force, and our strength during the times when we doubted our own abilities.

To the faculty of the EECE Department, thank you for being such good mentors.

To Engr. Jefrey Pasco for letting us setup our computers and equipment at the DSP lab

and for letting us conduct our hardware test runs there. To Engr. Rogelio Bersano for

accompanying and supervising us during our overnights at the college. To Engr.

Mercedenia Lambino and Engr. Angiline Teatro for being active in evaluating the

progress in our special project. To Engr. Stephen Haim for patiently correcting the

technicality of our manuscripts for the documentation of our project. And of course, to

our Adviser Engr. Lope Ben Porquis, for everything that he has done for us. We

acknowledge his patience with us in correcting our manuscript, his positivity for the

success of our project, him sharing his expertise on embedded systems and in firmware

programming, and his assistance in troubleshooting our hardware. Our project was
 v

mainly put on the right track by his guidance. We thank God for giving us such a

knowledgeable faculty.

Our friends and colleagues also helped in the success of our project. We thank the

“overnighters” for accompanying us during our overnights inside the college and for

readily lending us their advice and some of their tools and equipment even though they

themselves are also busy making their own projects. We would also like to thank the

COE-EC for letting us borrow their water dispenser during our overnights. It has been a

great help for us “overnighters” since clean water is scarce in the college during late

hours in the night. We also extend our heartfelt thanks to our batch mates for their

friendship and support. We thank them for believing in us. Even in their own little way,

they had helped us push through with our project. We will forever be grateful.

Once again, we thank everyone for everything.

We thank God for everything.

THANK YOU VERY MUCH!

The Researchers,

Kister Genesis M. Jimenez aka “KIT”

Dyl Therese A. Mesina aka “DYLAI”

Arvin D. Miranda aka “VINOTS”

 TABLE OF CONTENTS

TITLE PAGE i
ABSTRACT ii
APPROVAL SHEET iii
ACKNOWLEDGEMENT iv
TABLE OF CONTENTS vi
LIST OF TABLES xi
LIST OF FIGURES xii

CHAPTER 1: INTRODUCTION 1
1.1 Background of the Study 1
1.2 Statement of the Problem 2
1.3 Objectives of the Study 2
1.4 Significance of the Study 3
1.5 Scope and Limitations 3
1.6 Definition of Terms 4
1.7 Theoretical Framework 5
1.7.1 Data Acquisition 5
1.7.1.1 Transducers 5
1.7.1.2 Signals 6
1.7.1.2.1 Analog Signals 7
1.7.1.2.1.1 Level 7
1.7.1.2.1.2 Shape 8
1.7.1.2.2 Digital Signals 8
1.7.1.2.2.1 State 9
1.7.1.2.2.2 Rate 9
1.7.2 Vital Signs 9
1.7.2.1 Body Temperature 10
1.7.3 Embedded Systems 10
1.7.4 Microcontroller 11
1.7.5 PIC microcontroller 13
1.7.5.1 PIC16f877A 13
1.7.6 AVR Microcontroller 15
1.7.6.1 Brief History 15
1.7.6.2 Device Architecture 16
1.7.6.2.1 Data RAM 16
1.7.6.2.2 Program Memory (Flash) 16
 vii

1.7.6.2.3 Internal Data Memory 16

1.7.6.2.4 Internal Registers 16
1.7.6.2.5 EEPROM 18
1.7.6.3 ATmega32L 18
1.7.7 AVR Studio 19
1.7.8 MikroC for PIC 19
1.7.9 Networking Principle 20
1.7.9.1 Network Topologies 20
1.7.9.1.1 Bus Topology 21
1.7.9.1.2 Ring Topology 21
1.7.9.1.3 Star Topology 22
1.7.9.1.4 Tree Topology 23
1.7.9.1.5 Mesh Topology 24
1.7.9.2 Ethernet 25
1.7.10 World Wide Web 26
1.7.10.1 Hypertext Markup Language 27
1.7.10.2 AJAX 27
1.7.10.2.1 Java script 28
1.7.10.2.2 Document Object Model 28
1.7.10.3 Hypertext Transfer Protocol 29
1.7.10.3.1 Request message 30
1.7.10.3.2 Request methods 31
1.7.10.3.2.1 Safe methods 32
1.7.10.3.2.2 Idempotent methods and web applications 33
1.7.10.3.3 Status Codes 33
1.7.10.3.3.1 List of HTTP Status Codes 34
1.7.10.3.3.1.1 1xx Informational 35
1.7.10.3.3.1.2 2xx Success 35
1.7.10.3.3.1.3 3xx Redirection 35
1.7.10.3.3.1.4 4xx Client Error 35
1.7.10.3.3.1.5 5xx Server Error 36
1.7.10.2.4 Sample 36
1.7.10.4 Web Browser 37
1.7.10.4.1 History 38
1.7.10.4.2 Current Web browsers 39
1.7.10.4.3 Protocols and standards 39
1.7.11 Bluetooth 41
1.7.11.1 Operation 42
1.7.11.2 Bluetooth Security 44

vii
 viii

CHAPTER 2: REVIEW OF RELATED LITERATURE 46

2.1 Wireless Data Acquisition System 46
2.2 US Patent 6167258 - Programmable Wireless Data Acquisition System 46
2.3 Remote Data Acquisition System and Method 47
2.4 Vital Signs Monitoring System 47
2.5 Lifeguard – A Wearable Vital Signs Monitoring System 48
2.6 JEZ XI: A Wireless Sensor-Remote Controller Device for an
Intelligent, PC-Based, Client-Server MP3 Player System 49
2.7 Wireless Temperature Data Logger Implemented in a Two
Point-To-Single Point Topology Utilizing Zigbee Protocol
Through XBee Radio Frequency Transceiver Modules 50

CHAPTER 3: METHODOLOGY 51
3.1 Planning 52
3.2 Research and Parts Acquisition 52
3.3 System Overview 53
3.4 Hardware Development 53
3.4.1 Schematic Diagram and Board Layout 54
3.4.2 PCB Fabrication 54
3.4.2.1 Layout Film 54
3.4.2.2 Exposure 54
3.4.2.3 Developer 55
3.4.2.4 Etchant 55
3.4.2.5 Cleaning the track surface 55
3.4.2.6 Drilling 56
3.4.3 Components 56
3.4.3.1 Embedded Web Server 56
3.4.3.2 Bluetooth Host Controller 57
3.4.3.3 Bluetooth Slave Controller/Data Acquisition Device 59
3.5 Firmware Development 60
3.5.1 Embedded Web Server Firmware 60
3.5.1.1 Embedded Web Server 62
3.5.1.2 Web Pages/Files 63
3.5.2 Bluetooth Slave Controller and Data Acquisition Firmware 66
3.5.2.1 Analog to Digital Conversion 66
3.5.3 Bluetooth Host Controller Firmware 69
3.5.4 Bluetooth Module Settings 69
3.6 Setup and Testing 70

viii
 ix

CHAPTER 4: RESULTS AND DISCUSSION 72

4.1 Fabrication Results 72
4.1.1 Embedded Web Server 74
4.1.2 Bluetooth Host Controller 76
4.1.3 Bluetooth Slave Controller/Data Acquisition Device 77
4.1.4 Power Supply 78
4.2 Firmware 78
4.2.1 Bluetooth Slave Controller/Data acquisition 79
4.2.2 Bluetooth Host Controller 80
4.2.3 Embedded Web Server 80
4.3 Integration of the Embedded Web Server to the Network 84

CHAPTER 5: CONCLUSION AND RECOMMENDATION 87

5.1 Conclusion 87
5.2 Recommendation 87

BIBLIOGRAPHY 89

APPENDICES 91
Appendix A: SCHEMATIC DIAGRAMS 91
A.1 Schematic Diagram of Embedded Web Server 92
A.2 Schematic Diagram of Bluetooth Host Controller 93
A.3 Schematic Diagram of Bluetooth Slave
Controller/Data Acquisition Device 94
A.4 Schematic Diagram of power supply for Embedded
Web Server and Bluetooth Host Controller 95

Appendix B: SOURCE CODES 96

B.1Embedded Web Server source code 97
B.2 Web Pages/Files as a C include file 109
B.3 Wiznet W5100 Driver v1.4 SPI.h ported source code 125
B.4 ROM file maker source code 127
B.5 Web Pages/Files source code 132
B.6 Bluetooth Host Controller source code 137
B.7 Bluetooth Slave Controller/Data Acquisition Device source code 142

Appendix C: TECHNICAL SPECIFICATIONS/MANUALS 145

C.1 WIZ810MJ Technical specification 146
C.2 W5100 Technical specification 150
C.3 PIC16F877A Technical specification 153

ix
 x

C.4 Atmeg32L Technical specification 159

C.5 EGBC-04 Manual 165
C.6 LM35 Technical specification 171

CURRICULUM VITAE 178

x
 xi

LIST OF TABLES

Table 1.1 Ethernet Topologies 25-26

Table 1.2 Eight HTTP Request Methods 31
Table 4.1 Temperature Reading Comparisons Results 79

xi
 xii

LIST OF FIGURES

Figure 1.1 Phenomena and Existing Transducers 6

Figure 1.2 Primary Characteristics of an Analog Signal 7
Figure 1.3 Primary Characteristics of a Primary Signal 8
Figure 1.4 PIC16F877a pin assignments 14
Figure 1.5 Bus Topology Illustration 21
Figure 1.6 Ring Topology Illustration 22
Figure 1.7 Star Topology Illustration 23
Figure 1.8 Tree Topology Illustration 23
Figure 1.9 Mesh Topology Illustration 24
Figure 3.1 Process Flowchart 51
Figure 3.2 Block Diagram of System 53
Figure 3.3 WIZnet module 56
Figure 3.4 EGBC-04 Bluetooth Module 58
Figure 3.5 Embedded Web Server Block Diagram 61
Figure 3.6 String to Hex Conversion Program 64
Figure 4.1 Wearable Bluetooth Slave Controller / Data Acquisition Device 73

Figure 4.2 Final Hardware Assembly: Bluetooth Host

Controller Together With the Embedded Web Server 73
Figure 4.3 Embedded Web Server 74
Figure 4.4 Result of the Ping to the Embedded Web Server 75
Figure 4.5 Bluetooth Host Controllers 76
Figure 4.6 Bluetooth Slave Controller/Data Acquisition Device 77
Figure 4.7 3.3V Voltage Regulators for the Embedded Web Server and
Bluetooth Host Controller 78
Figure 4.8 PC-Based Web Server Window 80
Figure 4.9 Browser View Showing Normal Temperature 82
Figure 4.10 Browser View Showing High Temperature 82
Figure 4.11 Browser View When No Data Acquisition Device is Connected 83
Figure 4.12 Browser View When the Server is Offline or
the User is Disconnected 83
Figure 4.13 Latency of a Single Client 84
Figure 4.14 Six Connections Opened Simultaneously 85

xii
 CHAPTER 1

INTRODUCTION

1.1 Background of the Study

Data acquisition is simply the gathering of information about a system or process.

Information such as temperature is gathered by sensors that convert the information into

electrical signals. Sometimes only one sensor is needed, such as when recording

temperature. Sometimes hundreds or even thousands of sensors are needed, such as when

monitoring a complex industrial process. The signals from the sensors are transferred to a

data acquisition instrument which conditions, amplifies, measures, scales, processes,

displays and stores the sensor signals.

In the past data acquisition equipment was largely mechanical, using smoked

drums or chart recorders. Later, electrically powered chart recorders and magnetic tape

recorders were used. Today, powerful microprocessors and computers perform data

acquisition faster, more accurately, more flexibly, with more sensors, more complex data

processing, and elaborate presentation of the final information. Nonetheless, data

acquisition technology still continues to evolve and with the swift rise of Wi-Fi and

Bluetooth technologies, wireless data acquisition has become a possibility. It has then

become a trend to use network based data acquisition systems to reduce wiring costs. The

Ethernet network has become the most popular network to accomplish this task. Ethernet
 2

Data Acquisition is becoming smarter and better equipped with more control functions as

they move from yesterday's I/O multiplexers to the smallest remote Ethernet Data

Acquisition modules.

The Internet is the major technology that allows all levels of an organization to be

able to communicate and make the sensor-to-boardroom model a reality. Access can be

realized from any device that utilizes a standard web browser, so connections between

remote manufacturing plants, production planners, plant managers, and the CEO can be

made without having to create a dedicated proprietary network. Since a web page can be

installed in the I/O system as a Web I/O, then not only a sensor-to-boardroom model can

be practiced, but sensor-to-home, and a sensor-to-mobile display can also be realized.

1.2 Statement of the Problem

This special project aims to develop an Ethernet - based wireless vital signs

monitoring system that can be accessed through a web browser.

1.3 Objectives of the Study

This special project aims to do the following:

1. Develop an Ethernet - based wireless data acquisition system capable of

displaying vital signs data like body temperature, and pulse rate readings.

2. Implement a basic web server on a microcontroller unit that will allow the user to

view the monitored vital signs on a web browser.

 3

1.4 Significance of the Study

Using Hypertext transfer protocol (HTTP) for the exchange of data through

Ethernet made the Graphical User Interface (GUI) install – free and platform independent

because it uses a browser as the user interface which is supported by different operating

systems. A web server embedded on a microcontroller unit consumes much less power

than dedicated or desktop web servers, thus decreasing power consumption cost.

Moreover, the wireless feature of the data acquisition device made the data acquisition

mobile and portable. Combining the embedded web server and the wireless data

acquisition device, vital signs monitoring can now be done even without direct

interaction with the subject that is being monitored.

1.5 Scope ad Limitations

The project is bounded within the following statements:

1. The focus of the study is more on the Ethernet - based wireless data acquisition rather

than the accuracy of the monitoring device.

2. Only the body temperature is actually being measured while the pulse rate data is

simulated just to demonstrate the capabilities of Ethernet - based wireless vital signs

monitoring.

3. The maximum operating distance of the wireless data acquisition device is 10 meters

in a place with no obstacles. This is as specified by the datasheet of Bluetooth

module.

4. The speed of transmission of data in the network is dependent on the speed of the

internet/intranet, so latency maybe present.

 4

5. The web server can be simultaneously accessed by four or more clients.

6. The IP address, subnet mask and gateway address of the embedded web is static and

can only be configured at the compile time of the server firmware.

7. The data acquired is displayed in real time but data logging is not supported.

1.6 Definition of Terms

Data Acquisition – means to acquire data. However, in computer terminology, data

acquisition is defined as the process of uniting real world data to produce the data

to be maneuvered by the computer system. The data are in the form of waveforms

or signals. These signals are obtained using different instruments and devices.

Microcontroller Unit (MCU) – a computer on a chip integrated circuit. It is a type of

microprocessor emphasizing self-sufficiency and cost-effectiveness, that contains

all the memory and interfaces needed for a simple application

Web Server – a computer program that accepts HTTP request from web clients through

web browsers and serve them HTTP responses that has optional data components

which are usually web pages like HTML documents linked with objects.

Hypertext Transfer Protocol (HTTP) – a communication protocol on top of

Transmission Control Protocol for the transfer of information on the internet. It is

use in retrieving inter-linked text documents (hypertext) that leads to the

establishment of World Wide Web.

 5

1.7 Theoretical Framework

1.7.1 Data Acquisition

Data acquisition involves gathering signals from measurement sources and

digitizing the signal for storage, analysis, and presentation on a PC. Data acquisition

systems come in many different PC technology forms for great flexibility when choosing

your system. Scientists and engineers can choose from PCI, PXI, PCI Express, PXI

Express, PCMCIA, USB, Wireless and Ethernet data acquisition for test, measurement,

and automation applications. There are five components to be considered when building a

basic data acquisition system:

 Transducers and sensors

 Signals

 Signal conditioning

 Data acquisition hardware

 Driver and application software

1.7.1.1 Transducers

Data acquisition begins with the physical phenomenon to be measured. This

physical phenomenon could be the temperature of a room, the intensity of a light source,

the pressure inside a chamber, the force applied to an object, or many other things. An

effective data acquisition system can measure all of these different phenomena.
 6

A transducer is a device that converts a physical phenomenon into a measurable

electrical signal, such as voltage or current. The ability of a data acquisition system to

measure different phenomena depends on the transducers to convert the physical

phenomena into signals measurable by the data acquisition hardware. Transducers are

synonymous with sensors in data acquisition systems. There are specific transducers for

many different applications, such as measuring temperature, pressure, or fluid flow.

Figure 1.1 shows a short list of some common phenomena and the transducers used to

measure them.

Figure 1.1 Phenomena and existing transducers

1.7.1.2 Signals

The appropriate transducers convert physical phenomena into measurable signals.

However, different signals need to be measured in different ways. For this reason, it is

important to understand the different types of signals and their corresponding attributes.

Signals can be categorized into two groups: analog and digital.

 7

1.7.1.2.1 Analog Signals

An analog signal can be at any value with respect to time. A few examples of

analog signals include voltage, temperature, pressure, sound, and load. The three primary

characteristics of an analog signal include level, shape, and frequency (Figure 1.2).

Figure 1.2 Primary Characteristics of an Analog Signal

1.7.1.2.1.1 Level

Because analog signals can take on any value, the level gives vital information

about the measured analog signal. The intensity of a light source, the temperature in a

room, and the pressure inside a chamber are all examples that demonstrate the importance

of the level of a signal. When measuring the level of a signal, the signal generally does

not change quickly with respect to time. The accuracy of the measurement, however, is

very important. A data acquisition system that yields maximum accuracy should be

chosen to aid in analog level measurements.

 8

1.7.1.2.1.2 Shape

Some signals are named after their specific shape - sine, square, saw tooth, and

triangle. The shape of an analog signal can be as important as the level, because by

measuring the shape of an analog signal, you can further analyze the signal, including

peak values, DC values, and slope. Signals where shape is of interest generally change

rapidly with respect to time, but system accuracy is still important. The analysis of

heartbeats, video signals, sounds, vibrations, and circuit responses are some applications

involving shape measurements.

1.7.1.2.2 Digital Signals

A digital signal cannot take on any value with respect to time. Instead, a digital

signal has two possible levels: high and low. Digital signals generally conform to certain

specifications that define characteristics of the signal. Digital signals are commonly

referred to as transistor-to-transistor logic (TTL). TTL specifications indicate a digital

signal to be low when the level falls within 0 to 0.8 V, and the signal is high between 2 to

5 V. The useful information that can be measured from a digital signal includes the state

and the rate (Figure 1.3).

Figure 1.3 Primary Characteristics of a Primary Signal

 9

1.7.1.2.2.1 State

Digital signals cannot take on any value with respect to time. The state of a digital

signal is essentially the level of the signal - on or off, high or low. Monitoring the state of

a switch - open or closed - is a common application showing the importance of knowing

the state of a digital signal.

1.7.1.2.2.2 Rate

The rate of a digital signal defines how the digital signal changes state with

respect to time. An example of measuring the rate of a digital signal includes determining

how fast a motor shaft spins. Unlike frequency, the rate of a digital signal measures how

often a portion of a signal occurs. A software algorithm is not required to determine the

rate of a signal.

1.7.2 Vital Signs

Vital signs are measurements of the body's most basic functions. The four main

vital signs routinely monitored by medical professionals and healthcare providers include

body temperature, pulse rate, respiration rate (rate of breathing, blood pressure (Blood

pressure is not considered a vital sign, but is often measured along with the vital signs.)

Vital signs are useful in detecting or monitoring medical problems. Vital signs

can be measured in a medical setting, at home, at the site of a medical emergency, or

elsewhere.
 10

1.7.2.1 Body Temperature

Body temperature is a measure of the body's ability to generate and get rid of

heat. The body is very good at keeping its temperature within a narrow, safe range in

spite of large variations in temperatures outside the body.

When you are too hot, the blood vessels in your skin expand (dilate) to carry the

excess heat to your skin's surface. You may begin to sweat, and as the sweat evaporates,

it helps cool your body. When you are too cold, your blood vessels narrow (contract) so

that blood flow to your skin is reduced to conserve body heat. You may start shivering,

which is an involuntary, rapid contraction of the muscles. This extra muscle activity helps

generate more heat. Under normal conditions, this keeps your body temperature within a

narrow, safe range.

1.7.3 Embedded Systems

There are many definitions of embedded system but all of these can be combined

into a single concept. An embedded system is a special-purpose computer system that is

used for a particular task. The special computer system is usually less powerful than

general-purpose systems, although some exceptions do exist where embedded systems

are very powerful and complicated. Usually a low power consumption CPU with a

limited amount of memory is used in embedded systems. Many embedded systems use

very small operating systems; most of these provide very limited operating system

capabilities. However as memory and CPU power is becoming cheap, many modern

operating systems are also being used in embedded systems these days.
 11

Since embedded systems are used for special purpose tasks, there is usually no

need to add new applications to the system once it is built. Therefore programs and

operating systems are usually loaded only once into read-only memory. The read-only

memory is available in many forms these days and includes some type of ROM, flash

chips and flash cards. In case an upgrade is required, a new ROM chip replaces the old

one.

If you look at your surroundings, you will find tiny computers everywhere. They

are present even in places where you rarely notice them. Some of the most common

embedded systems used in everyday life are refrigerators, microwave ovens, TV, VCR,

DVD players, cameras, cars (Antilock brakes, engine control, sun roof, climate control,

automatic transmission and so on), personal digital assistants and printers.

Complicated and more sophisticated embedded systems include routers and switches

where high performance CPUs are used.

1.7.4 Microcontroller

A microcontroller is an integrated chip that is often part of an embedded system.

The microcontroller includes a CPU, RAM, ROM, I/O ports, and timers like a standard

computer, but because they are designed to execute only a single specific task to control a

single system, they are much smaller and simplified so that they can include all the

functions required on a single chip.

A microcontroller differs from a microprocessor, which is a general-purpose chip

that is used to create a multi-function computer or device and requires multiple chips to
 12

handle various tasks. A microcontroller is meant to be more self-contained and

independent, and functions as a tiny, dedicated computer.

The great advantage of microcontrollers, as opposed to using larger

microprocessors, is that the parts-count and design costs of the item being controlled can

be kept to a minimum. They are typically designed using CMOS (complementary metal

oxide semiconductor) technology, an efficient fabrication technique that uses less power

and is more immune to power spikes than other techniques.

There are also multiple architectures used, but the predominant architecture is

CISC (Complex Instruction Set Computer), which allows the microcontroller to contain

multiple control instructions that can be executed with a single macro instruction. Some

use a RISC (Reduced Instruction Set Computer) architecture, which implements fewer

instructions, but delivers greater simplicity and lower power consumption.

Early controllers were typically built from logic components and were usually

quite large. Later, microprocessors were used, and controllers were able to fit onto a

circuit board. Microcontrollers now place all of the needed components onto a single

chip. Because they control a single function, some complex devices contain multiple

microprocessors.

Microcontrollers have become common in many areas, and can be found in home

appliances, computer equipment, and instrumentation. They are often used in

automobiles, and have many industrial uses as well, and have become a central part of

industrial robotics. Because they are usually used to control a single process and execute

simple instructions, microcontrollers do not require significant processing power.

 13

The automotive market has been a major driver of microcontrollers, many of

which have been developed for automotive applications. Because automotive

microcontrollers have to withstand harsh environmental conditions, they must be highly

reliable and durable. Nonetheless, automotive microcontrollers, like their counterparts,

are very inexpensive and are able to deliver powerful features that would otherwise be

impossible, or too costly to implement.

1.7.5 PIC microcontroller

PIC is initially referred to as Programmable Interface Controller but was renamed

to Programmable Intelligent Computer. PICs are popular to developers and hobbyists due

to their low cost, wide availability, large user base, extensive collection of application

notes, availability of low cost or free development tools, and serial programming (and re-

programming with flash memory) capability.

With the arrival of PIC microcontrollers it has now become possible to program

microchips. Unlike in the past when circuits are built around chips, we now build chips

around circuits. The technology of microcontrollers has limitless boundaries and complex

circuits can be made many times smaller through the use of PIC microcontrollers.

Prototyping can be greatly enhanced as it's often much easier to make changes to a PIC

program, than it is to start changing circuit designs and electronic components.

1.7.5.1 PIC16f877A

The PIC16f877A is one of the most popular PIC microcontrollers and it's easy to

see why - it comes in a 40 pin DIP pinout and it has many internal peripherals.
 14

The 40 pins make it easier to use the peripherals as the functions are spread out

over the pins. This makes it easier to decide what external devices to attach without

worrying too much if there enough pins to do the job.

One of the main advantages is that each pin is only shared between two or three

functions so it's easier to decide what the pin function (other devices have up to 5

functions for a pin).

Figure 1.4 PIC16F877a pin assignments

 15

1.7.6 AVR Microcontroller

The AVR is a Modified Harvard architecture 8-bit RISC single chip

microcontroller (µC) which was developed by Atmel in 1996. The AVR was one of the

first microcontroller families to use on-chip flash memory for program storage, as

opposed to One-Time Programmable ROM, EPROM, or EEPROM used by other

microcontrollers at the time.

1.7.6.1 Brief History

It is believed the AVR basic architecture was conceived by two students at the

Norwegian Institute of Technology (NTH) Alf-Egil Bogen and Vegard Wollan.

The original AVR MCU was developed at a local ASIC house in Trondheim,

Norway, where the two founders of Atmel Norway were working as students. It was

known as a μRISC (Micro RISC). When the technology was sold to Atmel, the internal

architecture was further developed by Alf and Vegard at Atmel Norway, a subsidiary of

Atmel founded by the two architects.

Atmel says that the name AVR is not an acronym and does not stand for anything

in particular. The creators of the AVR give no definitive answer as to what the term

"AVR" stands for.

Note that the use of "AVR" in this article generally refers to the 8-bit RISC line of

Atmel AVR Microcontrollers.

Among the first of the AVR line was the AT90S8515, which in a 40-pin DIP

package has the same pinout as an 8051 microcontroller, including the external

multiplexed address and data bus. The polarity of the RESET line was opposite (8051's
 16

having an active-high RESET, while the AVR has an active-low RESET), but other than

that, the pinout was identical.

1.7.6.2 Device Architecture

1.7.6.2.1 Data RAM

Flash, EEPROM, and SRAM are all integrated onto a single chip, removing the

need for external memory. Some devices have an external bus to allow adding additional

data memory or memory-mapped devices.

1.7.6.2.2 Program Memory (Flash)

Program instructions are stored in non-volatile Flash memory. Although they are

8-bit MCUs, each instruction takes one or two 16-bit words.

The size of the program memory is occasionally indicated in the naming of the

device itself (e.g., the ATmega64x line has 64 kB of Flash).

There is no provision for off-chip program memory; all code executed by the

AVR core must reside in the on-chip flash.

1.7.6.2.3 Internal Data Memory

The data address space consists of the register file, I/O registers, and SRAM.

1.7.6.2.4 Internal Registers

The AVRs have 32 single-byte registers and are classified as 8-bit RISC devices.
 17

In most variants of the AVR architecture, the working registers are mapped in as

the first 32 memory addresses (000016-001F16) followed by the 64 I/O registers (002016-

005F16).

Actual SRAM starts after these register sections (address 006016). (Note that the

I/O register space may be larger on some more extensive devices, in which case the

memory mapped I/O registers will occupy a portion of the SRAM address space.)

Even though there are separate addressing schemes and optimized opcodes for

register file and I/O register access, all can still be addressed and manipulated as if they

were in SRAM.

In the XMEGA variant, the working register file is not mapped into the data

address space; as such, it is not possible to treat any of the XMEGA's working registers

as though they were SRAM. Instead, the I/O registers are mapped into the data address

space starting at the very beginning of the address space. Additionally, the amount of data

address space dedicated to I/O registers has grown substantially to 4096 bytes (000016-

0FFF16). As with previous generations, however, the fast I/O manipulation instructions

can only reach the first 64 I/O register locations (the first 32 locations for bitwise

instructions). Following the I/O registers, the XMEGA series sets aside a 4096 byte range

of the data address space which can be used optionally for mapping the internal

EEPROM to the data address space (100016-1FFF16). The actual SRAM is located after

these ranges, starting at 200016.

 18

1.7.6.2.5 EEPROM

Almost all AVR microcontrollers have internal Electrically Erasable

Programmable Read Only Memory (EEPROM) for semi-permanent data storage. Like

Flash memory, EEPROM can maintain its contents when electrical power is removed.

In most variants of the AVR architecture, this internal EEPROM memory is not

mapped into the MCU's addressable memory space. It can only be accessed the same way

an external peripheral device is, using special pointer registers and read/write instructions

which makes EEPROM access much slower than other internal RAM.

However, some devices in the SecureAVR (AT90SC) family use a special

EEPROM mapping to the data or program memory depending on the configuration. The

XMEGA family also allows the EEPROM to be mapped into the data address space.

Since the number of writes to EEPROM is not unlimited — Atmel specifies

100,000 write cycles in their datasheets — a well designed EEPROM write routine

should compare the contents of an EEPROM address with desired contents and only

perform an actual write if contents need to be changed. (http://en.wikipedia.org, p.1-4)

1.7.6.3 ATmega32L

The ATmega32 is a low-power CMOS 8-bit microcontroller based on the AVR

enhanced RISC architecture. By executing powerful instructions in a single clock cycle,

the ATmega32 achieves throughputs approaching 1 MIPS per MHz allowing the system

designer to optimize power consumption versus processing speed. It also has 32 kilobytes

of flash memory for program storage.

 19

1.7.7 AVR Studio

AVR Studio is an Integrated Development Environment (IDE) for writing and

debugging AVR applications in Windows 9x/ME/NT/2000/XP/VISTA environments.

AVR Studio provides a project management tool, source file editor, simulator, and front-

end for C/C++, programming, emulation and on-chip debugging.

1.7.8 MikroC for PIC

MikroC is a powerful, feature rich development tool for MICmicros. It is

designed to provide the programmer with the easiest possible solution for developing

applications for embedded systems, without compromising performance or control.

PIC and C fit well together: PIC is the most popular 8bit chip in the world, used in

a variety of applications, and C, prized for its efficiency, is the natural choice for

developing embedded systems. MikroC provides a successful match featuring highly

advanced IDE, ANSI compliant compiler, broad set of hardware libraries, comprehensive

documentation, and plenty of ready-to-run examples.

MikroC allows you to quickly develop and deploy complex applications:

 Write your C source code using the built-in Code Editor (code and parameter

assistants, syntax highlighting, auto correct, code templates and etc.

 Use the included MikroC libraries to dramatically speed up the development: data

acquisition, memory, displays, conversions, communications, etc

 Monitor your program structure, variables, and functions in the Code Explorer

 Generate commented, human readable assembly, and standard HEX compatible

with all programmers.

 20

 Inspect program flow and debug executable logic with the integrated debugger

 Get detailed reports and graphs: RAM and ROM map, code statistics, assembly

listing, calling tree, and more.

 Plenty of examples were provided for the user to expand, develop, and use as

building bricks for projects.

1.7.9 Networking Principle

1.7.9.1 Network Topologies

In computer networking, topology refers to the layout of connected devices.

Think of a topology as a network's virtual shape or structure. This shape does not

necessarily correspond to the actual physical layout of the devices on the network. For

example, the computers on a home LAN may be arranged in a circle in a family room,

but it would be highly unlikely to find a ring topology there.

Network topologies are categorized into the following basic types:

 bus

 ring

 star

 tree

 mesh

More complex networks can be built as hybrids of two or more of the above basic

topologies.
 21

1.7.9.1.1 Bus Topology

Bus networks (not to be confused with the system bus of a computer) use a

common backbone to connect all devices. A single cable, the backbone, functions as a

shared communication medium that devices attach or tap into with an interface

connector. A device wanting to communicate with another device on the network sends a

broadcast message onto the wire that all other devices see, but only the intended recipient

actually accepts and processes the message.

Ethernet bus topologies are relatively easy to install and don't require much

cabling compared to the alternatives. 10Base-2 ("ThinNet") and 10Base-5 ("ThickNet")

both were popular Ethernet cabling options many years ago for bus topologies. However,

bus networks work best with a limited number of devices. If more than a few dozen

computers are added to a network bus, performance problems will likely result. In

addition, if the backbone cable fails, the entire network effectively becomes unusable.

Figure 1.5 Bus Topology Illustration

1.7.9.1.2 Ring Topology

In a ring network, every device has exactly two neighbors for communication

purposes. All messages travel through a ring in the same direction (either "clockwise" or
 22

"counterclockwise"). A failure in any cable or device breaks the loop and can take down

the entire network.

To implement a ring network, one typically uses FDDI, SONET, or Token Ring

technology. Ring topologies are found in some office buildings or school campuses.

Figure 1.6 Ring Topology Illustration

1.7.9.1.3 Star Topology

Many home networks use the star topology. A star network features a central

connection point called a "hub" that may be a hub, switch or router. Devices typically

connect to the hub with Unshielded Twisted Pair (UTP) Ethernet.

Compared to the bus topology, a star network generally requires more cable, but a

failure in any star network cable will only take down one computer's network access and

not the entire LAN. (If the hub fails, however, the entire network also fails.)
 23

Figure 1.7 Star Topology Illustration

1.7.9.1.4 Tree Topology

Tree topologies integrate multiple star topologies together onto a bus. In its

simplest form, only hub devices connect directly to the tree bus, and each hub functions

as the "root" of a tree of devices. This bus/star hybrid approach supports future

expandability of the network much better than a bus (limited in the number of devices

due to the broadcast traffic it generates) or a star (limited by the number of hub

connection points) alone.

Figure 1.8 Tree Topology Illustration

 24

1.7.9.1.5 Mesh Topology

Mesh topologies involve the concept of routes. Unlike each of the previous

topologies, messages sent on a mesh network can take any of several possible paths from

source to destination. (Recall that even in a ring, although two cable paths exist,

messages can only travel in one direction.) Some WANs, most notably the Internet,

employ mesh routing.

A mesh network in which every device connects to every other is called a full

mesh. As shown in the illustration below, partial mesh networks also exist in which some

devices connect only indirectly to others.

Figure 1.9 Mesh Topology Illustration

 25

1.7.9.2 Ethernet

Developed in the early 1970's, Ethernet has proven to be one of the most simple,

reliable, and long-lived networking protocols ever designed. The high speed and

simplicity of the protocol has resulted in its widespread use.

Although Ethernet works across a variety of layer one media, the three most

popular forms are 10BaseT, 10Base2, and 10BaseF, which use unshielded twisted pair

(UTP), coaxial, and fiber optic cables respectively. UTP is used in a "star" configuration,

in which all nodes connect to a central hub. 10Base2 uses a single coaxial cable to

connect all workstations together in a "bus" configuration, and does not require a hub.

10BaseF uses fiber optics, which, though expensive, can travel long distances (2km) and

through electrically noisy areas.

An interesting difference between coaxial Ethernet and other types is that coax

Ethernet is truly a one-to-many (or, 'point-to-multipoint') connection; fiber and UTP

connections are, from a layer one perspective, one-to-one (or, 'point-to-point')

connections, and require an additional networking device (typically, a repeater, or

Ethernet hub) to connect to multiple other workstations. This is why coax Ethernet does

not require a hub, and Ethernet over other media typically does.

Ethernet Topologies

Pro Con Typical Use

10BaseT *Very reliable- one fault *Relatively short distance *Offices and home

usually doesn't affect entire from hub to workstation networks.

network. (100m).
 26

*Requires a lot of wiring (a

separate link for each

workstation.)

10Base2 *Cheap- no hub required, no *Any break in connectivity *Small or home

wiring except from station to disrupts entire network networks, hub to hub

station. segment. links.

*Well shielded against *Problems can be very

electrical interference. difficult to troubleshoot.

*Can transmit longer distances

(200m).

10BaseF *Long distance networking *Very expensive to install. *Long distance hub-to-

(2000m). hub or switch-to-hub

*Immune to electrical links.

interference.

Table 1.1 Ethernet Topologies

1.7.10 World Wide Web

WWW is part of Internet. It has over the last 10 or so years become the largest

part of the Internet. Before the WWW, information was viewed as pages of text, or

downloadable files. You would go to a particular location and view (or download) a file.

To get to another file, you had to go back to that location again and get it. The WWW

revolutionized the way that people use the Internet. The WWW itself is simply a set of

software that uses hypertext pages and the HTTP protocol to allow users to click

hyperlinks in order to be taken to other Web pages or resources on the Internet.

 27

1.7.10.1 Hypertext Markup Language

One of the main components of the WWW is the language used to make Web

pages. This language is called Hyper Text Markup Language (HTML). HTML pages can

be created in the simplest of text editors. It is basically ordinary text, but text that is

"marked up" with special HTML 'tags" that are used to define structure of the page.

HTML uses hyperlinks to link to other Web pages, or just about anything on the Internet

for that matter. HTML also allows for the inclusion of multimedia elements including

images into Web pages.

1.7.10.2 AJAX

Ajax, or AJAX (Asynchronous JavaScript and XML), is a group of interrelated

web development techniques used to create interactive web applications or rich Internet

applications. With Ajax, web applications can retrieve data from the server

asynchronously in the background without interfering with the display and behavior of

the existing page. The use of Ajax has led to an increase in interactive animation on web

pages. Data is retrieved using the XMLHttpRequest object or through the use of Remote

Scripting in browsers that do not support it. Despite the name, the use of JavaScript and

XML is not actually required, nor do the requests need to be asynchronous. The acronym

AJAX has thus changed to the term Ajax, which does not represent these specific

technologies.
 28

1.7.10.2.1 Java script

JavaScript is a scripting language widely used for client-side web development. It

was the originating dialect of the ECMAScript standard. It is a dynamic, weakly typed,

prototype-based language with first-class functions. JavaScript was influenced by many

languages and was designed to look like Java, but be easier for non-programmers to work

with.

Although best known for its use in websites (as client-side JavaScript),

JavaScript is also used to enable scripting access to objects embedded in other

applications.

JavaScript, despite the name, is essentially unrelated to the Java programming

language, although both have the common C syntax, and JavaScript copies many Java

names and naming conventions. The language's name is the result of a co-marketing deal

between Netscape and Sun, in exchange for Netscape bundling Sun's Java runtime with

their then-dominant browser. The key design principles within JavaScript are inherited

from the Self and Scheme programming languages.

"JavaScript" is a trademark of Sun Microsystems. It was used under license for

technology invented and implemented by Netscape Communications and current entities

such as the Mozilla Foundation.

1.7.10.2.2 Document Object Model

The Document Object Model (DOM) is a platform- and language-independent

standard object model for representing HTML or XML documents as well as an

 29

Application Programming Interface (API) for querying, traversing and manipulating such

documents.

DOM is likely to be best suited for applications where the document must be

accessed repeatedly or out of sequence order. If the application is strictly sequential and

one-pass, the SAX model is likely to be faster and use less memory. In addition, non-

extractive XML parsing models, such as VTD-XML, provide a new memory-efficient

option.

1.7.10.3 Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is an application-level protocol for

distributed, collaborative, hypermedia information systems. Its use for retrieving inter-

linked resources led to the establishment of the World Wide Web.

HTTP is a request/response standard between a client and a server. A client is the

end-user; the server is the web site. The client making a HTTP request—using a web

browser, spider, or other end-user tool—is referred to as the user agent. The responding

server—which stores or creates resources such as HTML files and images—is called the

origin server. In between the user agent and origin server may be several intermediaries,

such as proxies, gateways, and tunnels. HTTP is not constrained to using TCP/IP and its

supporting layers, although this is its most popular application on the Internet. Indeed

HTTP can be "implemented on top of any other protocol on the Internet, or on other

networks. HTTP only presumes a reliable transport; any protocol that provides such

guarantees can be used."

 30

Typically, an HTTP client initiates a request. It establishes a Transmission

Control Protocol (TCP) connection to a particular port on a host (port 80 by default; see

List of TCP and UDP port numbers). An HTTP server listening on that port waits for the

client to send a request message. Upon receiving the request, the server sends back a

status line, such as "HTTP/1.1 200 OK", and a message of its own, the body of which is

perhaps the requested resource, an error message, or some other information.

1.7.10.3.1 Request message

The request message consists of the following:

 Request line, such as GET /images/logo.gif HTTP/1.1, which requests a

resource called /images/logo.gif from server

 Headers, such as Accept-Language: en

 An empty line

 An optional message body

The request line and headers must all end with <CR><LF> (that is, a carriage

return followed by a line feed). The empty line must consist of only <CR><LF> and no

other whitespace. In the HTTP/1.1 protocol, all headers except Host are optional.

A request line containing only the path name is accepted by servers to maintain

compatibility with HTTP clients before the HTTP/1.0 specification.

 31

1.7.10.3.2 Request methods

HTTP defines eight methods (sometimes referred to as "verbs") indicating the

desired action to be performed on the identified resource. What this resource represents,

whether pre-existing data or data that is generated dynamically, depends on the

implementation of the server. Often, the resource corresponds to a file or the output of an

executable residing on the server.

REQUEST DESCRIPTION

METHOD

Asks for the response identical to the one that would correspond to a GET
HEAD
request, but without the response body.

GET Requests a representation of the specified resource.

Submits data to be processed (e.g., from an HTML form) to the identified

POST
resource.

PUT Uploads a representation of the specified resource.

DELETE Deletes the specified resource.

Echoes back the received request, so that a client can see what intermediate
TRACE
servers are adding or changing in the request.

Returns the HTTP methods that the server supports for specified URL. This can

OPTIONS be used to check the functionality of a web server by requesting '*' instead of a

specific resource.

CONNECT Converts the request connection to a transparent TCP/IP tunnel

Table 1.2 Eight HTTP Request Methods

 32

HTTP servers are required to implement at least the GET and HEAD methods and,

whenever possible, also the OPTIONS method.

1.7.10.3.2.1 Safe methods

Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined

as safe, which means they are intended only for information retrieval and should not

change the state of the server. In other words, they should not have side effects, beyond

relatively harmless effects such as logging, caching, the serving of banner advertisements

or incrementing a web counter. Making arbitrary GET requests without regard to the

context of the application's state should therefore be considered safe.

By contrast, methods such as POST, PUT and DELETE are intended for actions

which may cause side effects either on the server, or external side effects such as

financial transactions or transmission of email. Such methods are therefore not usually

used by conforming web robots or web crawlers, which tend to make requests without

regard to context or consequences.

Despite the prescribed safety of GET requests, in practice their handling by the

server is not technically limited in any way, and careless or deliberate programming can

just as easily (or more easily, due to lack of user agent precautions) cause non-trivial

changes on the server. This is discouraged, because it can cause problems for Web

caching, search engines and other automated agents, which can make unintended changes

on the server.
 33

1.7.10.3.2.2 Idempotent methods and web applications

Methods PUT and DELETE are defined to be idempotent, meaning that multiple

identical requests should have the same effect as a single request. Methods GET, HEAD,

OPTIONS and TRACE, being prescribed as safe, should also be idempotent. HTTP is a

stateless protocol.

By contrast, the POST method is not necessarily idempotent, and therefore

sending an identical POST request multiple times may further affect state or cause further

side effects (such as financial transactions). In some cases this may be desirable, but in

other cases this could be due to an accident, such as when a user does not realize that

their action will result in sending another request, or they did not receive adequate

feedback that their first request was successful. While web browsers may show alert

dialog boxes to warn users in some cases where reloading a page may re-submit a POST

request, it is generally up to the web application to handle cases where a POST request

should not be submitted more than once.

Note that whether a method is idempotent is not enforced by the protocol or web

server. It is perfectly possible to write a web application in which (for example) a

database insert or other non-idempotent action is triggered by a GET or other request.

Ignoring this recommendation, however, may result in undesirable consequences if a user

agent assumes that repeating the same request is safe when it isn't.

1.7.10.3.3 Status Codes

In HTTP/1.0 and since, the first line of the HTTP response is called the status line

and includes a numeric status code (such as "404") and a textual reason phrase (such as
 34

"Not Found"). The way the user agent handles the response primarily depends on the

code and secondarily on the response headers. Custom status codes can be used since, if

the user agent encounters a code it does not recognize, it can use the first digit of the code

to determine the general class of the response.

Also, the standard reason phrases are only recommendations and can be replaced

with "local equivalents" at the web developer's discretion. If the status code indicated a

problem, the user agent might display the reason phrase to the user to provide further

information about the nature of the problem. The standard also allows the user agent to

attempt to interpret the reason phrase, though this might be unwise since the standard

explicitly specifies that status codes are machine-readable and reason phrases are human-

readable.

1.7.10.3.3.1 List of HTTP Status Codes

The following is a list of HyperText Transfer Protocol (HTTP) response status

codes and standard associated phrases, intended to give a short textual description of the

status. These status codes are specified by RFC 2616, along with additional codes (RFC

2518, RFC 2817, RFC 2295, RFC 2774, RFC 4918), some from the Distributed

Authoring (WebDAV) extension. Microsoft IIS servers may also use sub-codes, which

are not listed here. Others are unstandardised but commonly used.

The first digit of the status code specifies one of five classes of response. The

phrases used are the standard examples, but any human-readable alternative can be

provided.
 35

1.7.10.3.3.1.1 1xx Informational

Request received, continuing process.

This class of status code indicates a provisional response, consisting only of the

Status-Line and optional headers, and is terminated by an empty line. Since HTTP/1.0 did

not define any 1xx status codes, servers must not send a 1xx response to an HTTP/1.0

client except under experimental conditions.

1.7.10.3.3.1.2 2xx Success

The action was successfully received, understood, and accepted.

This class of status code indicates that the client's request was successfully

received, understood, and accepted.

1.7.10.3.3.1.3 3xx Redirection

The client must take additional action to complete the request.

This class of status code indicates that further action needs to be taken by the user

agent in order to fulfill the request. The action required may be carried out by the user

agent without interaction with the user if and only if the method used in the second

request is GET or HEAD. A user agent should not automatically redirect a request more

than five times, since such redirections usually indicate an infinite loop.

1.7.10.3.3.1.4 4xx Client Error

The request contains bad syntax or cannot be fulfilled.

 36

The 4xx class of status code is intended for cases in which the client seems to

have erred. Except when responding to a HEAD request, the server should include an

entity containing an explanation of the error situation, and whether it is a temporary or

permanent condition. These status codes are applicable to any request method. User

agents should display any included entity to the user. These are typically the most

common error codes encountered while online.

1.7.10.3.3.1.5 5xx Server Error

The server failed to fulfill an apparently valid request.

Response status codes beginning with the digit "5" indicate cases in which the

server is aware that it has encountered an error or is otherwise incapable of performing

the request. Except when responding to a HEAD request, the server should include an

entity containing an explanation of the error situation, and indicate whether it is a

temporary or permanent condition. Likewise, user agents should display any included

entity to the user. These response codes are applicable to any request method.

1.7.10.3.4 Sample

Below is a sample conversation between an HTTP client and an HTTP server

running on www.example.com, port 80.

Client request (followed by a blank line, so that request ends with a double newline,

each in the form of a carriage return followed by a line feed):

 37

Server response (followed by a blank line and text of the requested page):

1.7.10.4 Web Browser

A Web browser is a software application which enables a user to display and

interact with text, images, videos, music, games and other information typically located

on a Web page at a Web site on the World Wide Web or a local area network. Text and

images on a Web page can contain hyperlinks to other Web pages at the same or different

Web site. Web browsers allow a user to quickly and easily access information provided

on many Web pages at many Web sites by traversing these links. Web browsers format

HTML information for display, so the appearance of a Web page may differ between

browsers.

Web browsers are the most-commonly-used type of HTTP user agent. Although

browsers are typically used to access the World Wide Web, they can also be used to

access information provided by Web servers in private networks or content in file

systems.
 38

1.7.10.4.1 History

The history of the Web browser dates back to late 1980s, when a variety of

technologies laid the foundation for the first Web browser, the WorldWideWeb, by Tim

Berners-Lee in 1991. That browser brought together a variety of existing and new

software and hardware technologies.

The introduction of the NCSA Mosaic Web browser in 1993 – one of the first

graphical web browsers – led to an explosion in Web use. Marc Andreessen, the leader of

the Mosaic team at NCSA, soon started his own company, named Netscape, and released

the Mosaic-influenced Netscape Navigator in 1994, which quickly became the world's

most popular browser, accounting for 90% of all Web use at its peak (see usage share of

web browsers).

Microsoft responded with its browser Internet Explorer in 1995 (also heavily

influenced by Mosaic), initiating the industry's first browser war. By bundling Internet

Explorer with Windows, Microsoft was able to leverage its dominance in the operating

system market to take over the Web browser market; Internet Explorer usage share

peaked at over 95% by 2002.

In 1998, Netscape launched what was to become the Mozilla Foundation in an

attempt to produce a competitive browser using the open source software model. That

browser would eventually evolve into Firefox, which developed a respectable following

while still in the beta stage of development; shortly after the release of Firefox 1.0 in late

2004, Firefox (all versions) accounted for 7.4% of browser use.[3] As of February 2009,

Firefox has a 21.77% usage share.

 39

Opera debuted in 1996; although it has never achieved widespread use, having

less than 1% browser usage share as of February 2009,[4] it has a substantial share of the

fast-growing mobile phone Web browser market, being preinstalled on over 40 million

phones. It is also available on several other embedded systems, including the Nintendo

Wii.

Apple's Safari had its first beta release in January 2003; as of February 2009, it

has a dominant share of Apple-based Web browsing, accounting for just over 8% of the

entire browser market.

The most recent major entrant to the browser market is Google's Chrome, first

released in September 2008. As of February 2009, it has a 1.15% usage share.

1.7.10.4.2 Current Web browsers

Some of the Web browsers currently available for personal computers include
[5]
Internet Explorer, Opera, Mozilla Firefox, Safari, Avant Browser, Konqueror, Lynx,

Google Chrome, Maxthon, Flock, Arachne, Epiphany, K-Meleon and AOL Explorer.

1.7.10.4.3 Protocols and standards

Web browsers communicate with Web servers primarily using Hypertext Transfer

Protocol (HTTP) to fetch Web pages. HTTP allows Web browsers to submit information

to Web servers as well as fetch Web pages from them. The most-commonly-used version

of HTTP is HTTP/1.1, which is fully defined in RFC 2616. HTTP/1.1 has its own

required standards that Internet Explorer does not fully support, but most other current-

generation Web browsers do.

 40

Pages are located by means of a URL (Uniform Resource Locator, RFC 1738),

which is treated as an address, beginning with http: for HTTP transmission. Many

browsers also support a variety of other URL types and their corresponding protocols,

such as gopher: for Gopher (a hierarchical hyperlinking protocol), ftp: for File Transfer

Protocol (FTP), rtsp: for Real-time Streaming Protocol (RTSP), and https: for HTTPS

(HTTP Secure, which is HTTP augmented by Secure Sockets Layer or Transport Layer

Security).

The file format for a Web page is usually HTML (HyperText Markup Language)

and is identified in the HTTP protocol using a MIME content type. Most browsers

natively support a variety of formats in addition to HTML, such as the JPEG, PNG and

GIF image formats, and can be extended to support more through the use of plugins. The

combination of HTTP content type and URL protocol specification allows Web-page

designers to embed images, animations, video, sound, and streaming media into a Web

page, or to make them accessible through the Web page.

Early Web browsers supported only a very simple version of HTML. The rapid

development of proprietary Web browsers led to the development of non-standard

dialects of HTML, leading to problems with Web interoperability. Modern Web browsers

support a combination of standards-based and de facto HTML and XHTML, which

should be rendered in the same way by all browsers. No browser fully supports HTML

4.01, XHTML 1.x or CSS 2.1 yet. Many sites are designed using WYSIWYG HTML-

generation programs such as Adobe Dreamweaver or Microsoft FrontPage. Microsoft

FrontPage often generates non-standard HTML by default, hindering the work of the

W3C in promulgating standards, specifically with XHTML and Cascading Style Sheets
 41

(CSS), which are used for page layout. Dreamweaver and other more modern Microsoft

HTML development tools such as Microsoft Expression Web and Microsoft Visual

Studio conform to the W3C standards.

Some of the more popular browsers include additional components to support

Usenet news, Internet Relay Chat (IRC), and e-mail. Protocols supported may include

Network News Transfer Protocol (NNTP), Simple Mail Transfer Protocol (SMTP),

Internet Message Access Protocol (IMAP), and Post Office Protocol (POP). These

browsers are often referred to as "Internet suites" or "application suites" rather than

merely Web browsers.

1.7.11 Bluetooth

Bluetooth is a wireless protocol for exchanging data over short distances from

fixed and mobile devices, creating personal area networks (PANs). It was originally

conceived as a wireless alternative to RS232 data cables. It can connect several devices,

overcoming problems of synchronization.

Bluetooth takes small-area networking to the next level by removing the need for

user intervention and keeping transmission power extremely low to save battery power.

Bluetooth is essentially a networking standard that works at two levels:

 It provides agreement at the physical level -- Bluetooth is a radio-frequency

standard.

 It provides agreement at the protocol level, where products have to agree on when

bits are sent, how many will be sent at a time, and how the parties in a
 42

conversation can be sure that the message received is the same as the message

sent.

1.7.11.1 Operation

Bluetooth networking transmits data via low-power radio waves. It communicates

on a frequency of 2.45 gigahertz (actually between 2.402 GHz and 2.480 GHz, to be

exact). This frequency band has been set aside by international agreement for the use of

industrial, scientific and medical devices (ISM).

A number of devices that you may already use take advantage of this same radio-

frequency band. Baby monitors, garage-door openers and the newest generation of

cordless phones all make use of frequencies in the ISM band. Making sure that Bluetooth

and these other devices don't interfere with one another has been a crucial part of the

design process.

One of the ways Bluetooth devices avoid interfering with other systems is by

sending out very weak signals of about 1 milliwatt. By comparison, the most powerful

cell phones can transmit a signal of 3 watts. The low power limits the range of a

Bluetooth device to about 10 meters (32 feet), cutting the chances of interference between

your computer system and your portable telephone or television. Even with the low

power, Bluetooth doesn't require line of sight between communicating devices. The walls

in your house won't stop a Bluetooth signal, making the standard useful for controlling

several devices in different rooms.

Bluetooth can connect up to eight devices simultaneously. With all of those

devices in the same 10-meter (32-foot) radius, you might think they'd interfere with one
 43

another, but it's unlikely. Bluetooth uses a technique called spread-spectrum frequency

hopping that makes it rare for more than one device to be transmitting on the same

frequency at the same time. In this technique, a device will use 79 individual, randomly

chosen frequencies within a designated range, changing from one to another on a regular

basis. In the case of Bluetooth, the transmitters change frequencies 1,600 times every

second, meaning that more devices can make full use of a limited slice of the radio

spectrum. Since every Bluetooth transmitter uses spread-spectrum transmitting

automatically, it’s unlikely that two transmitters will be on the same frequency at the

same time. This same technique minimizes the risk that portable phones or baby monitors

will disrupt Bluetooth devices, since any interference on a particular frequency will last

only a tiny fraction of a second.

When Bluetooth-capable devices come within range of one another, an electronic

conversation takes place to determine whether they have data to share or whether one

needs to control the other. The user doesn't have to press a button or give a command --

the electronic conversation happens automatically. Once the conversation has occurred,

the devices -- whether they're part of a computer system or a stereo -- form a network.

Bluetooth systems create a personal-area network (PAN), or piconet, that may fill a room

or may encompass no more distance than that between the cell phone on a belt-clip and

the headset on your head. Once a piconet is established, the members randomly hop

frequencies in unison so they stay in touch with one another and avoid other piconets that

may be operating in the same room. Let's check out an example of a Bluetooth-connected

system.
 44

1.7.11.2 Bluetooth Security

In any wireless networking setup, security is a concern. Devices can easily grab

radio waves out of the air, so people who send sensitive information over a wireless

connection need to take precautions to make sure those signals aren't intercepted.

Bluetooth technology is no different -- it's wireless and therefore susceptible to spying

and remote access, just like WiFi is susceptible if the network isn't secure. With

Bluetooth, though, the automatic nature of the connection, which is a huge benefit in

terms of time and effort, is also a benefit to people looking to send you data without your

permission.

Bluetooth offers several security modes, and device manufacturers determine

which mode to include in a Bluetooth-enabled gadget. In almost all cases, Bluetooth

users can establish "trusted devices" that can exchange data without asking permission.

When any other device tries to establish a connection to the user's gadget, the user has to

decide to allow it. Service-level security and device-level security work together to

protect Bluetooth devices from unauthorized data transmission. Security methods include

authorization and identification procedures that limit the use of Bluetooth services to the

registered user and require that users make a conscious decision to open a file or accept a

data transfer. As long as these measures are enabled on the user's phone or other device,

unauthorized access is unlikely. A user can also simply switch his Bluetooth mode to

"non-discoverable" and avoid connecting with other Bluetooth devices entirely. If a user

makes use of the Bluetooth network primarily for synching devices at home, this might

be a good way to avoid any chance of a security breach while in public.

 45

Still, early cell-phone virus writers have taken advantage of Bluetooth's

automated connection process to send out infected files. However, since most cell phones

use a secure Bluetooth connection that requires authorization and authentication before

accepting data from an unknown device, the infected file typically doesn't get very far.

When the virus arrives in the user's cell phone, the user has to agree to open it and then

agree to install it. This has, so far, stopped most cell-phone viruses from doing much

damage. See How Cell-phone Viruses Work to learn more.

Other problems like "bluejacking," "bluebugging" and "Car Whisperer" have

turned up as Bluetooth-specific security issues. Bluejacking involves Bluetooth users

sending a business card (just a text message, really) to other Bluetooth users within a 10-

meter (32-foot) radius. If the user doesn't realize what the message is, he might allow the

contact to be added to his address book, and the contact can send him messages that

might be automatically opened because they're coming from a known contact.

Bluebugging is more of a problem, because it allows hackers to remotely access a user's

phone and use its features, including placing calls and sending text messages, and the

user doesn't realize it's happening. The Car Whisperer is a piece of software that allows

hackers to send audio to and receive audio from a Bluetooth-enabled car stereo. Like a

computer security hole, these vulnerabilities are an inevitable result of technological

innovation, and device manufacturers are releasing firmware upgrades that address new

problems as they arise.

If communications security is a concern of yours, then click here to learn how

phone conferencing security works. To learn more about Bluetooth security issues and

solutions, see Bluetooth.com: Wireless Security.

 CHAPTER 2

REVIEW OF RELATED LITERATURE

This chapter deals with related studies and topics that lead us to this special

project.

2.1 Wireless Data Acquisition System

A wireless data acquisition system comprises a slave wireless unit provided on a

device, a master wireless unit for collecting data about the device by wireless

communicating with the slave wireless unit, and a center for communicating with the

master wireless unit through a line. The master wireless unit includes a control section for

controlling the operation of the master wireless unit, a data acquisition section for

collecting updated data from the outside of the master wireless unit to change the

operation of the control section, and a reprogramming section for rewriting the control

data that specify the operation of the control section based on the updated data.

(Nakagawa, et.al, 2001)

2.2 US Patent 6167258 - Programmable Wireless Data Acquisition System

A programmable wireless data acquisition system, comprising a transmitting

device and a receiving device. The transmitting device is capable of receiving multiple
 47

external inputs and generating and transmitting a radio frequency signal encoded with

data corresponding to the inputs. The transmitting device is variably configurable to

enable it to accept inputs having different characteristics and ranges and to enable it to

provide variable sampling rate, gain and filtering of the inputs. The transmitting device

having a microprocessor such that the microprocessor controls the operation thereof. The

receiving device is capable of receiving the radio frequency signal, demodulating it and

decoding the data. The receiving device has a microprocessor such that the

microprocessor controls the operation thereof. External programming device programs

the transmitting device and the receiving device by wired connection or through radio

frequency signal.

2.3 Remote Data Acquisition System and Method

A data acquisition system and method includes monitoring a cooling system

having a refrigerant compressor, evaporator, and condenser, and employs a number of

sensors to monitor various operating parameters of the system. A database stores

predefined operating parameters for a plurality of cooling systems. The operating

parameters are provided to a computer, which compares the provided operating

parameters of the monitored cooling system with the predefined operating parameters to

provide diagnostic results for the monitored cooling system.

2.4 Vital Signs Monitoring System

A vital signs monitoring system for allowing a user to easily monitor their vital

signs at home with a remote control type device. The vital signs monitoring system
 48

includes a remote control for a television that has a plurality of sensors designed for

monitoring the vital signs of a user. A first transceiver is positioned in the housing such

that the transceiver is operationally coupled to the sensors whereby the first transceiver is

for transmitting vital sign information collected by the sensors. A television has a second

transceiver for receiving the information collected by the sensors, the television has a

processing unit operationally coupled to the second transceiver such that the processing

unit processes information received by the second transceiver. The television is for

displaying the information on a screen of the television. (Taylor, 2002)

2.5 Lifeguard – A Wearable Vital Signs Monitoring System

LifeGuard – a state-of-the-art wearable vital signs monitoring system – has been

developed by the NASA Ames Astrobionics team. This system is capable of logging

physiological data as well as wirelessly transmitting it to a portable base station PC for

display purposes or further processing. It was developed for astronauts, but has many

potential uses in clinical, home-health monitoring, first responder, and military

applications as well. The core component of the system is a small, lightweight, wearable

device called "CPOD" that is worn on the body along with several sensors attached to it.

These sensors measure the following vital signs: ECG (2channels), respiration, activity

(3-axis acceleration), temperature (skin or ambient), heart rate, pulse oximetry SpO2, and

diastolic and systolic blood pressure. The wearable device acquires and logs these

physiological parameters up to 8 hours and can download or stream them in real time to a

base station PC on demand. (lifeguard.stanford.edu).

 49

2.6 JEZ XI: A Wireless Sensor-Remote Controller Device for an Intelligent,

PC-Based, Client-Server MP3 Player System

JEZ XI is a device for sensing a person’s body temperature and skin conductance

which will be sent, via a wireless transmitter, to a remote PC where a wireless receiver is

connected in its serial(COM) port. The remote PC runs a program, called the J-AMP

Commander (also called the JEZ XI Data Receiver), which periodically checks the serial

port for incoming data, processes them, and sends them to the J-AMP MP3 player using

TCP/IP. J-AMP, in turn, employs AI techniques on the received data and produces an

educated guess of the user’s desired hourly MP3 rankings in its play list automatically.

The device also has remote control functionality for the J-AMP MP3 player (i.e. for

PLAY, STOP, NEXT, PREV, PAUSE, VOL+, and VOL- operations). Because of the

TCP/IP feature of the J-AMP and the J-AMP Commander/JEZ XI Data receiver, it is

possible to use two different PCs connected in a network: one to receive the data coming

from the JEZ XI, and the other one to run the J-AMP MP3 player.

JEZ XI uses a PIC18F877A microcontroller unit (MCU) to convert the signals

coming from the skin temperature and skin conductance sensors into digital data. The

reason for choosing this MCU is that, it has built-in analog-to-digital converter and lots

of I/O ports, which makes it very suitable for this project. An ASK RF module is then

used for its wireless transmission and a Nokia 3310 LCD for its display. (Paghasian,

Garde March 2007)

 50

2.7 Wireless Temperature Data Logger Implemented in a Two Point-To-Single

Point Topology Utilizing Zigbee Protocol Through XBee Radio Frequency

Transceiver Modules

This Project is a low-cost temperature data logging system composed of two units

of temperature sensor and a transmitting device (end device) and one receiver

(coordinator) which is connected to the PC via serial port. The LM35DZ in the end

device will gather temperature in its surroundings and input it to the XBee RF module.

The module will do the A/D conversion and send the data wirelessly to the coordinator.

The coordinator will then display and record the data. The test shows that the system has

97%-99% accuracy in it readings having the mercury thermometer as a standard. The

affective reliable distance between the coordinator and the end device is up to 70 meters.

(Balansag, Evangelio, Lowaton March 2008)

 CHAPTER 3

METHODOLOGY

This special project has undergone several steps to be completed. These include

planning, research and parts acquisition, hardware development and fabrication, firmware

development, testing/debugging.

Figure 3.1 Process Flowchart

 52

3.1 Planning

Ideas were developed through analysis of significant applications. After much

deliberation, the researchers chose the vital signs monitoring as an application for the

data acquisition project. Related topics were then examined and the feasibility of such a

system was then weighed considering the different factors that would later be

encountered. The researchers then finalized the basic concept and divided the task of

researching and developing of the different topics involved.

3.2 Research and Parts Acquisition

For the collection of necessary data and information related to the project, the

researchers visited various internet sites and joined different internet forums to acquire

resources and inputs from different individuals who are experts on the system. The

researchers also visited different manufacturer's website to download and see the latest

review of the components used by this project. Internet sites of various electronic parts

vendors were also visited to inquire on the availability and prices of the components to be

used in the project.

Acquisition of materials and hardware components was made mostly through

online internet transactions. The PIC16F877A microcontrollers, ATmega32L, LM35

sensor and Bluetooth module (EGBC-04) were ordered at e-gizmo Philippines. The

Wiznet module on the other hand was lent to us by Mr. Phillip Lim, while the software

used to design and developed the system were freewares and sharewares from various

internet sites. The rest of the parts were purchased in different electronic stores in Iligan

City and Cagayan De Oro City.

 53

3.3 System Overview

The whole system is composed of the embedded web server, Bluetooth host

controller and the data acquisition device with Bluetooth slave. The setup is shown figure

3.2.

Figure 3.2 Block Diagram of System

3.4 Hardware
ardware Development

This section discusses the fabrication of the embedded web server, Bluetooth host

controller, and the Bluetooth slave controller/data acquisition device.

 54

3.4.1 Schematic Diagram and Board Layout

The task of designing the circuit was divided by among the researchers.

Schematic Diagrams were made using OrCAD and Cadsoft Eagle. OrCAD, which is a

suite of tools from Cadence, was used for the design and layout of the printed circuit

boards (PCBs) for the Bluetooth host controller and the data acquisition device, while

EagleCad was used for the circuit board design and the schematic diagrams of the

embedded web server. Refer to appendix A for schematic diagrams.

3.4.2 PCB Fabrication

PCB fabrication is the process of printing a circuit on a photo-sensitive board.

Fabrication is conducted in sequential steps; there is no provision to skip any of the steps,

they have to be followed in the same order and precisely.

3.4.2.1 Layout Film

Films are generated by printing the Layout files on the transparency. The

transparent film will be used to facilitate exposure process that will be further discussed

in this section.

3.4.2.2 Exposure

The exposure of the circuit is the next step. The white protective cover from the

board was peeled off under subdued lighting conditions. To avoid getting unwanted

prints on the PCB, the cover was peeled while holding the edges. The transparent film is

then placed over the coated side of the board. To maintain good contact, a glass plate is
 55

placed over the film. The PCB was then exposed about 15cm under a fluorescent lamp

for 8 minutes.

3.4.2.3 Developer

The developing of the exposed PCB is next. The developing solution that comes

with the pre-sensitized PCB package was used. The board was then immersed in the

solution and agitated by rocking the container until the PCB trace pattern began to

appear. The PCB was then rinsed thoroughly with clean running water when the coating

of all unwanted areas of the PCB was dissolved and the copper surface is exposed. It

must be noted that a new developing solution must be used for every new exposed board.

3.4.2.4 Etchant

Etchant is used to remove the Copper from the board. There are two types of

etchant, Ferric Chloride and Ammonium Persulfate. For this project Ferric Chloride was

used. A safety reminder for this process: Be very careful when handling this solution. It

leaves bad stains and can potentially cause burn marks on the skin and can possibly cause

damage in other ways too.

3.4.2.5 Cleaning the track surface

Apply a small amount of acetone on the pads. Repeat until clear the copper pads

can be seen on the board.

 56

3.4.2.6 Drilling

The board was then drilled with holes using a 1/32" – diameter drill bit. The bit

must be sharp and pointed enough to avoid detachment of the pads from the board during

the drilling process.

3.4.3 Components

3.4.3.1 Embedded Web Server

The following is a list of electronic components used in the embedded web server:

 WIZnet Module

WIZ810MJ is the WIZnet network module that includes W5100 (TCP/IP

hardwired chip, include PHY), MAG-JACK (RJ45 with transformer) with other glue

logics. It can be used as a component and no effort is required to interface the W5100

chip and the MAG-JACK. The WIZ810MJ was chosen so the researchers could develop

their Internet enabling systems rapidly.

Figure 3.3 WIZnet module

 57

 Atmega32 microcontroller communicates with the W5100 chip on the

WIZ810MJ through SPI and was programmed to work as an embedded web

server. Atmega32L was chosen as the microcontroller for the web server because

of its 32 kilobytes flash memory which is suitable for big applications like web

servers. It is available in E-Gizmo Mechatronix Central online store where most

of the other components were bought.

 8MHz Crystal Oscillator clock input source for the Atmega32L.

 (2) 22pF capacitor serves as a loading capacitor which stabilizes oscillation for a

clearer clock signal.

 0.1uF capacitor is a decoupling capacitor that is connected to the input voltage of

ATmega32L.

 10k ohm resistor to pull up the Reset pin of Atmega32L.

 6 pin header interface for ISP (in system programmer) loader.

 (2) 2x11 female header 2.00mm pitch socket for Wiznet module.

3.4.3.2 Bluetooth Host Controller

The following is a list of electronic components used in the Bluetooth Host

Controller:

 PIC16F877A was chosen as the microcontroller for the Bluetooth host controller

because of its UART module that was used to communicate with both the

Bluetooth module and the Atmega32L web server. It has a single UART module

which was enough, since the flow of data is from the Bluetooth module to

PIC16f877A and then to the Atmega32L. The Rx pin of the PIC16f877A was
 58

used in receiving data from the Bluetooth module and the Tx pin was used in

sending data to the Atmega32L web server.

 EGBC-04 (Bluetooth module) simplifies Bluetooth integration by presenting

itself as a simple UART channel. Therefore, it is easy to integrate this to the

project.

Figure 3.4 EGBC-04 Bluetooth Module

 8MHz Crystal Oscillator clock input source for PIC16f877A. The maximum

frequency that can be for 3.3V is given by the formula:

FMAX = (6.0 MHz/V) (VDDAPPMIN – 2.0V) + 4 MHz

= (6.0MHz/V) (3.3-2.0) + 4MH z = 11.8MHz

8MHz was chosen because of its availability.

 (2) 22pF capacitor serves as a loading capacitor which stabilizes oscillation for a

clearer clock signal.

 0.1uF capacitor is a decoupling capacitor that is connected to the input voltage of

PIC16f877A.

 5 pin header interface for ISP (in system programmer) loader.

 59

 10k ohm resistor to pull up the MCLR pin of PIC16f877A.

 1k ohm resistor connected to CTS and RTS pin of MAX3221 if handshaking is

not used.

3.4.3.3 Bluetooth Slave Controller/Data Acquisition Device

The following is a list of electronic components used in the Bluetooth Slave

Controller/Data Acquisition Device:

 EGBC-04 (Bluetooth module) is connected to PIC16f877A through UART

 BA033 voltage regulator provides a regulated 3.3V supply

 LM35 a three pin temperature sensor to be connected to the PORTA-AN0 or

channel 0 ADC pin of the PIC16F877A.

 PIC16f877A controls Bluetooth module and handles the data acquired from the

sensor.

 4MHz Crystal oscillator clock input for the PIC16f877A. Lower frequency

would lower the power consumption but this is the lowest available frequency at

the time of ordering.

 (2) 22pF capacitor serves as a loading capacitor which stabilizes oscillation for a

clearer signal.

 0.1uF capacitor is a decoupling capacitor that is connected to the input voltage of

PIC16f877A.

 5 pin header interface for ISP (in system programmer) loader.

 10k ohm resistor to pull up the MCLR pin of PIC16f877A.

 60

3.5 Firmware Development

3.5.1 Embedded Web Server Firmware

AVR Studio was used in developing the web server firmware. High level C

language was chosen because it is preferable for firmwares that have big and complex

algorithms. Since AVR Studio has only included assembly language compiler in their

integrated development environment, WinAVR package was downloaded and installed to

add the GNU Compiler Collection (GCC) plug-in to AVR studio for the compilation of C

source codes.

The embedded web server firmware is composed of two parts. The main part is

the embedded web server and the other is the embedded web pages that will be stored in

the Flash memory of the Atmega32L microcontroller.

The web server source code was first developed in the Dev-C++ IDE which uses

Minimalist GNU for Windows (MingW) port of GNU Compiler Collection (GCC) as its

compiler and can run the source code as a desktop application (PC-based). It is suitable

for the PC-based web server development because it is almost completely compatible

with the GCC that is used for AVR firmware development. Programming the web server

initially as a PC-based program is necessary because it avoids the difficulty of frequently

reloading the firmware to the hardware for debugging.

The functions that were created for this project were built to be portable, that is,

functions that are platform dependent were separated from the general purpose functions

and were grouped together. A function that uses platform dependent functions and

statements will just call the separated functions. So it will be easier to port the code to

another platform, the grouped platform dependent functions and statements were
 61

enclosed in #include guards which can tell the compiler which part of the code to

compile.

The PC-based web server was slowly ported to an AVR MCU compatible code by

reducing possible RAM usage to match the Atmega32L RAM size. Because of the

compatibility of the compiler for the PC-based web server and the compiler for the

Atmega32L, only the Atmega32L specific include resource files were added. However,

the socket communication provided by the Windows Socket API (WinSock API) was not

compatible with the Wiznet driver V1.4 definition. The main function of the program was

changed to match the Wiznet Socket API socket communication and the winsock API

include file (winsock.h) was removed.

EMBEDDED WEB SERVER

(Atmega32L)

UART TX from UART

Communication Rx SOCKET
PIC API
only
And
HTTP (Web) Server
Wiznet
Web Pages driver
SPI
To
Wizne
t

Figure 3.5 Embedded Web Server Block Diagram

 62

3.5.1.1 Embedded Web Server

The embedded web server or embedded HTTP server is an application layer

protocol that handles HTTP requests from a browser. A corresponding response for the

requests will be sent by the server. It could be a success header along with the requested

file or an error header depending on the result of the request.

Since the W5100 chip implements a hardwire TCP/IP stack layer, the only thing

to do to access the Ethernet is to set or read the right registers in the chip. An interface

driver in C language is provided by Wiznet to handle the task of reading and writing into

the W5100 registers. Communication to the Ethernet was further simplified by the

SOCKET API (Application Programming Interface) also included in the driver package.

However, the interface driver is compatible only to Atmega128 microcontroller so the

driver must be ported first to be able to use it for the Atmega32L. Wiznet also provides

the porting tutorial in their site. The IP address, subnet mask, and gateway address were

preconfigured in the firmware. The IP address was set to 10.10.25.195, the subnet mask

was set to 255.255.248.0 and the gateway was set to 10.10.31.254. This was to enable the

project to work in the Digital Signal Processing Lab local area network.

The Embedded Web Server Algorithm

1. Initialize the Serial Peripheral Interface module of Atmega32L. This is

handled by the Wiznet driver.

2. Initialize the Wiznet driver by setting the IP address, subnet mask,

machine address (MAC address), the gateway address, and the memory

capacity of the Rx and Tx of each port of the W5100 chip.

 63

3. Initialize the UART of Atmega32L for an 8-bit data transmission having 1

stop bit, no parity bit, and a baud rate of 9600 baud.

4. Wait for an incoming request and accept if there is one and then continue

to step 5. If the socket is closed or disconnected, open it and repeat step 4.

If it is waiting for disconnection, disconnect and then repeat step 4.

5. Parse the request

6. Send a response (either an error or the requested file).

7. Disconnect from the requesting client if the transaction is finished then go

back to step 4.

8. Interrupt on every UART receive and check if the format of the data being

received is valid. If it is valid, save it to a global variable for later access.

If it is not valid, reject the data.

3.5.1.2 Web Pages/Files

The web pages and web files for the web server were created using notepad.

These files are the index.htm, the ajax.js, and the sty.css. These files are just in plain text

format but follow the syntax of their respective languages. A vsigns_htm() function that

is referenced when a request to vsigns.htm is made was also created for the dynamic data

page. These will be the files that can be requested by the user. The embedded web server

will only send these files to the requesting user and let the browser interpret the files.

The files will then be converted by a program built by the researchers to a C

compatible include file. Every ASCII character inside each file will be converted into its

8-bit number equivalent. Thus, there in no need for escaping of the special characters.
 64

The command prompt in figure 3.6 shows the success in converting every file to a C type

include file.

Figure 3.6 String to Hex Conversion Program

Each file will have its filename as its variable name but the dot (“.”) before the

file extension will be replaced with an underscore (“_”) because a dot in C represents an

operation for struct field access. These variables will have a data type “prog_uchar”

meaning it is an unsigned char type that will be located in the flash ROM.

The researchers implemented their own ROM file system structure in the web

server firmware to handle the indexing of the web files declared as “prog_uchar”. A file

in this file system structure has a filename, pointer to a html function (for dynamic page

request), pointer to the first character of the file in the flash memory and the size of the

file given by the function sizeof().

The following web files were compiled together with the web server:

1. index.htm - the main and default page. It is the graphical user interface (GUI) of

this project. It requests the ajax.js and sty.css to provide ajax capability and other
 65

functions. A table is presented in this web page displaying the temperature and

pulse rate. Four units are displayed in the page for future upgrades. The data is

updated every 5 seconds by the JavaScript function SetInterval() that will be called

every time the index.htm is loaded.

2. ajax.js – is a JavaScript that defines the functions for AJAX requests and some

other functions that are called in an interval to request the data from the server

without any interaction from the user. Functions for time and date display were also

included to have a feature of comparing the time of the request of data to the time

of arrival of the data. AJAX (Asynchronous JavaScript and XML) is a group of

interrelated web development techniques which aides the webpage to provide

dynamic pages. When AJAX is employed, a browser request can be done without

actually reloading or refreshing the whole page and updates only a small part in the

page. Therefore, the communication time and the size of data that comes from the

server are minimized. Error in the communication with the server, data acquisition

device failure and abnormal data is handled by the script. It is also responsible for

handling and parsing the response of the server and in placing it in their respective

containers in the index.htm.

3. sty.css – is a CSS file that defines the properties of the container class and tags of

the index.htm. This could be incorporated inside index.htm but it is separated so

that the appearance of the index.htm can be changed without editing the index.htm.

Every browser may have different interpretations on some properties in the

cascading style sheet but this will not affect the overall functionality of the

application.
 66

A function in ajax.js requests the html file vsigns.htm. This resource request will

be parsed by the server but will not serve a file; instead, a function is executed that sends

a server formatted string to the browser. The content of the string varies depending on the

vital signs data sent by the Bluetooth host controller. It serves as a dynamic web page of

the web server.

3.5.2 Bluetooth Slave Controller and Data Acquisition Firmware

A PIC16F877A was used as the bluetooth slave controller and a data acquisition

device. It serves as the intermediate between the sensors and the bluetooth module. The

data from the sensors is received and/or converted and is then formatted before it is sent

via the slave bluetooth device. In sending the data, the device will first send its identifier

which is either ‘252’, ‘253’, ‘254’, or ‘255.’ After the identifier is sent, a delay of five

milliseconds is employed. After the delay, the temperature data is then transmitted and

after another five-millisecond delay, the pulse data is then sent.

3.5.2.1 Analog to Digital Conversion

The ADC module of the PIC16F877A was used for the analog to digital

conversion. The 10-bit A/D converter converts analog signals ranging from Vref- up to

Vref+, which in this case is 0V and 3.3V respectively. The result of the conversion is a

10-bit digital value (2^10 or 1024) and is formatted to be right justified. The 2 two most

significant bits are stored in ADRESH while the other 8 bits are stored in ADRESL.
 67

The LM35 temperature sensor outputs an analog voltage that is proportional to the

surrounding temperature with a resolution of 10mV per degree Celsius. The voltage

output range of the LM35 is from 0-1.48 V which corresponds to 2 - 150 degrees Celsius.

Since no signal conditioning was added into the circuit, the maximum A/D

conversion output from the A/D module of the microcontroller is only 459. 459 is 1.48V/

3.3V times 1024 which is approximately only forty five percent (45%) of the total A/D

range. This means that a conversion value of 459 corresponds to a temperature reading of

150 degree Celsius and a conversion value of zero corresponds to 2 degrees Celsius since

the L35 outputs 0mV starting from 2 degrees Celsius and below.

The following steps show the processing of the conversion data as it is translated

into its corresponding temperature value.

1. The output voltage of the LM35 is converted into digital data by the A/D module

of the microcontroller. The output is then multiplied by (100*1.48)/458.8 to get

the number of incremented voltage levels during conversion of the digital data.

0 – 3.3 Volts: voltage range that the A/D module of the microcontroller can

convert into digital data.

3.3V/1024 = 3.22mV which is the incremental voltage level required by the A/D

module for it to increment its conversion level. This is okay since the resolution

of the LM35 is 10mV per degree Celsius which is around 3 incremental voltage

levels.
 68

Example:

An output voltage of 112.7mV from the LM35 will correspond to conversion

increments equal to 112.7mV divided by 3.22mV per conversion increment which

is 35 conversion increments.

2. The number of conversion increments is then added by two (2) to get the

corresponding temperature value. This is because a 0V level in the output of the

LM35 corresponds to 2 degrees Celsius.

Example:

We determined before that a voltage output of 112.7mV from the LM35 results in

35 conversion increments. Thus the temperature of the sampled data is 35 + 2 =

37 degrees Celsius.

After the A/D conversion is done, the results are temporarily stored. The pulse

data is then obtained by random. When both of the data are ready, the transmission then

begins. First, the identifier associated with the data acquisition device is sent. In this case,

the identifier is 252 in decimal or 0xFC in hexadecimal. After a delay of five

milliseconds (5ms), the temperature data is then sent. After another five-millisecond

delay, the pulse data is then sent.

 69

3.5.3 Bluetooth Host Controller Firmware

The Bluetooth host controller that is connected to the embedded web server is a

PIC16F877A. It receives data from the remote bluetooth slaves and after verification,

forwards the data to the web server. The Bluetooth host verifies if the data is from a

Bluetooth slave by checking the identifier. If it receives the correct identifier then it

receives the two remaining data that is sent by the Bluetooth slave which are the

temperature and the pulse data. It then stores the temperature and pulse data in an array

that corresponds to the identifier that was received. The reception of data is interrupt-

based. This was done to ensure the reception of data. Timer0’s interrupt service routine is

employed as a 5 second timer. After 5 seconds, all of the data stored in the array for each

of the acquisition devices is sent to the web server. First a number 2 is sent as a pseudo

flag that initiates the reception of data by the web server. Then the data from the

acquisition devices is then sent, starting from the one with the identifier of ‘252’, then

‘253’, ‘254’ and then finally the one with ‘255’ as the identifier. In each of the

acquisition device data, the temperature data is sent first then the pulse data second.

3.5.4 Bluetooth Module Settings

The two bluetooth modules that were used were EGBC – 04 bluetooth modules

by e – Gizmo Mechatronix Central. The module simplifies bluetooth integration by

presenting itself as a simple UART channel to its host. Sending and receiving data to and

from another Bluetooth device is reduced to a simple task of reading and writing to the

equivalent UART channel. All complex bluetooth tasks involved such as authentication,
 70

encryption, transport, channel hopping, etc, are automatically performed by the EGBC –

04.

The bluetooth module for the data acquisition device was configured as a slave.

The device was named “KARD”. Its UART mode was set to one (1) stop bit and no

parity bit. The baud rate was configured to be 9600 baud. It was set to bind only to the

master module located at the embedded web server so that it will connect only to the

master every time it starts up.

The Bluetooth module for the embedded web server was configured as a master.

The device was named “DARK”. Its UART mode was set to one (1) stop bit and no

parity bit. The baud rate was configured to be 9600 baud.

3.6 Setup and Testing

The data acquisition device is turned on by connecting it to the battery pack. The

embedded web server hardware and the Bluetooth host controller are connected to 3.3V

regulator using jumper wires. The regulator is supplied with 6V from a DC power supply.

The embedded web server is connected to the Ethernet hub/switch using a UTP

cable that is connected to the Ethernet port of the Wiznet module. The IP address, subnet

mask, and gateway address configured in the embedded web server firmware should

match the network settings of the network that it is connected to. Since the firmware does

not support dynamic configuration, the IP address configured in the firmware must not be

a reserved address (reserved by a dynamic host configuration protocol) in the network.

 71

A computer on the same local area network can access the embedded web server.

This is done by entering the IP address of the embedded web server on a web browser in

the computer.
 CHAPTER 4

RESULTS AND DISCUSSION

This chapter discusses the results of the hardware design and construction and the

firmware.

4.1 Fabrication Results

The fabrication of our hardware was one of the crucial parts of our special project.

The three main parts of the hardware are the embedded web server, Bluetooth host

controller, and the Bluetooth slave controller/data acquisition device.

Since all the printed circuit boards for the hardware were pre-sensitized, the

resulting etched PCBs were neat. Pin headers and jumper wires were used to connect the

power supply to the devices. The UART receive of the Atmega32L was connected to the

UART transmit of the PIC16f877A (HOST side) by a single jumper wire. The modules

and microcontroller were not directly soldered to the circuit board and used IC sockets to

avoid damaging the modules and microcontroller from excessive soldering heat.
 73

Figure 4.1 Wearable Bluetooth Slave Controller / Data Acquisition Device

Figure 4.2 Final Hardware Assembly: Bluetooth Host Controller Together With the

Embedded Web Server

 74

Figure 4.3 Embedded Web Server

4.1.1 Embedded Web Server

The embedded web server device was initially tested with a test firmware that

initializes the W5100 chip’s IP address, subnet mask and machine address. The porting

guide of from Wiznet states that once the chip is initialized, it will give a reply when

pinged.

The configured IP address of the test firmware was 192.168.0.1, subnet mask of

255.255.255.0 and a gateway address of 223.223.223.0. The hardware was then

connected to a crossover UTP cable connected to a laptop computer at one end that has

an IP address of 192.168.0.2 and the same subnet mask. The hardware was pinged using

the command ping 192.168.0.1 in the command prompt.

 75

The wiznet link indicators (amber and green LEDs in figure 4.3) lit up and the

reply to the ping was received in the command prompt. The result of the command ping

is shown in figure 4.4.

Figure 4.4 Result of the Ping to the Embedded Web Server

 76

Figure 4.5 Bluetooth Host Controllers

4.1.2 Bluetooth Host Controller

The Bluetooth host controller was supplied with a regulated 3.3V using an

LM317 variable voltage regulator. In testing the EGBC - 04 Bluetooth modules, a

Bluetooth dongle was used. The dongle was connected to a laptop computer and the

device discovery function was turned on. The laptop computer was able to detect and

connect with the Bluetooth module. The whole Bluetooth host controller was then

connected to the web server module to verify its functionality. The Bluetooth host

controller was able to connect to the web server and was able to send the temperature

data and the simulated pulse data.

 77

4.1.3 Bluetooth Slave Controller/Data Acquisition Device

The Bluetooth slave controller/data acquisition device needs a portable 3.3V

supply while the LM35 temperature sensor operates on at least 4V. The researchers

decided to use four 1.5V AA batteries (6V in total) for the supply and placed it in a four-

battery holder pack. The supply was directly connected to the LM35 sensor. The supply

was also regulated to 3.3V using BA033 for the Bluetooth module and PIC16f877A.

This device, together with the battery pack, was put inside a pouch that can be

strapped around the arm near the arm pit.

Figure 4.6 Bluetooth Slave Controller/Data Acquisition Device

 78

4.1.4 Power Supply

A regulated 3.3V supply is necessary for Atmega32L, Wiz810MJ, PIC16f877A

and Bluetooth module to operate. Thus the power supply was made. The regulator is

supplied 6V from a DC adaptor that is connected to a wall outlet.

Figure 4.7 3.3V Voltage Regulators for the Embedded Web Server

and Bluetooth Host Controller

4.2 Firmware

The data flow of the system is from the sensor, then to the PIC16f877A (Slave

side), then to the Bluetooth slave, the Bluetooth host, the PIC16f877A (Host Side), the

Atmega32L, the Wiznet module and then to the web browser of the user.
 79

4.2.1 Bluetooth Slave Controller/Data Acquisition

The firmware for the Bluetooth slave controller and data acquisition device was

debugged using the hyper terminal of MiKroC. The Bluetooth slave was paired to a CD-

R King Bluetooth dongle that is connected to a laptop computer. The data was received in

the specified order in the hyper terminal.

The sensor, together with a room thermometer was placed in different places to

sample temperature. The temperature that was received in the hyper terminal was

compared to the readings from a room thermometer. Table 4.1 shows the comparison of

five samples.

Temperature reading from Temperature reading from

%error
device (°C) the room thermometer (°C)
30 30 0%

31 30 3.33%

37 37 0%

39 39.5 1.2%

36 36.5 1.3%

Table 4.1 Temperature Reading Comparisons Results

The data in table 4.1 shows that the temperature readings of the data acquisition

device are very close to the actual temperature readings of the room thermometer. The

highest error the device is only 3.33% thus giving an acceptable reliability.
 80

4.2.2 Bluetooth Host Controller

The Bluetooth host controller was also tested using the CD-R King Bluetooth

dongle. The input came from the MikroC hyper terminal. The Bluetooth host controller

was connected to the embedded web server in order for the researchers to see the data

sent by the hyper terminal. The Bluetooth host controller was able to receive data from

the data acquisition device and was able to send the data to the web server in the format

that was specified in the firmware code.

4.2.3 Embedded Web Server

The firmware for the embedded web server was first tested using random data

inputs to see if the hypertext transfer protocol code is fully functional. Making the code

portable between Atmega32L and Windows Operating System enabled the researchers to

easily debug the protocol flow. The running window of the PC-based web server is

shown in figure 4.8. The lines of string in the window were printed every time the server

is waiting for request and sending response.

Figure 4.8 PC-Based Web Server Window

 81

Two methods for debugging the web server were used by the researchers. The

first one was to use the C language “printf()” function to watch variables at certain lines

in the program. And the second method was using the Dev-C++ debug functionality and

watched the variables while running the program slowly and line-by-line.

Since it worked, the UART communication with PIC16F877A was included and

the code was transferred to an AVR Studio project. The complete embedded web server

firmware was then loaded to the Atmega32L.

The webpage displays the current date and time. It also shows the time and date of

the current data request and the time and date that on which the latest data arrived or was

received in the browser. The displayed latency is the difference between the time the

browser request was sent and the time the response was received. Up to four data

acquisition device outputs can be displayed in the web browser. A status of the unit is

also displayed whether the data acquisition device is connected or not (ON or OFF).

Server and device communication errors, as well as abnormal vitals signs (temperatures

below 36 and above 37) are displayed in red-colored background.

Figures 4.9-4.12 shows the resulting browser views of the running embedded web

server while being accessed using a Mozilla Firefox browser. Only a single data

acquisition device was built so the data for Vital Signs Units (VS unit) 2,3, and 4 are set

to “N/A” (Not Applicable) by the JavaScript function handling the response of the server

and displayed the status of each VS unit to “OFF”. The temperature data is the only

actual reading because the pulse rate data was just randomly generated in the data

acquisition device as stated in the Scope and Limitations. When the client becomes
 82

disconnected from the server, the date and time of reception display will turn red as well

as the latency box that now displays the message: “No response from server!".

Figure 4.9 Browser View Showing Normal Temperature

Figure 4.10 Browser View Showing High Temperature

 83

Figure 4.11 Browser View When No Data Acquisition Device Is Connected

Figure 4.12 Browser View When the Server is Offline or the User is Disconnected
 84

The web server was also tested using other web browsers such as Opera, Internet

Explorer and Google Chrome as a compatibility test of the web pages. It shows that only

the Internet Explorer browser does not support the red background color for errors. Since

it does not affect the over-all functionality of the web application, this problem was

ignored.

4.3 Integration of the Embedded Web Server to the Network

The default web page (index.htm) of the web server was added with a feature of

displaying the difference of the AJAX request timestamp and server response timestamp

in milliseconds. The researchers use the term latency to for this value.

First, the researchers tested the latency of a single client connected to the web

server over the network in Digital Signal Processing Lab. Figure 4.13 shows a latency of

16 milliseconds encircled in white. This includes the processing time of the firmware,

time spent in transmission through Ethernet and the processing time of the browser. Refer

to Appendix B for the source codes to approximate the running time.

Figure 4.13 Latency of a Single Client

 85

Figure 4.14 Six Connections Opened Simultaneously

The next test was to connect to the server from the computers on the same

network. There is no significant change in the latency of the connection from the two

browsers. So another test was done. This was to open multiple browsers pointing to the

server on one of the connecting computers. Figure 4.14 shows six windows (four Mozilla

Firefox and two Internet Explorer browsers) all connecting simultaneously to the web

server. The encircled parts of the browsers show the latency of each connection to the

server. The latencies displayed from left to right and down were 15, 16, 16, 17, 16 and 16

milliseconds respectively. No significant change in the latency was observed. The

researchers proceeded to test with more simultaneous connections because the result was

more than what was expected. Before, the researchers first assumed that the capacity of
 86

the server was only up to four clients simultaneously connecting to the server because

only four sockets are available in the Wiznet module. However, by setting the interval of

the AJAX request to 5 milliseconds, the interval of the server receiving requests from

clients will not occur at the same time. Therefore, the server can have enough time to

process each request before each browser declares a connection timeout.

 CHAPTER 5

CONCLUSION AND RECOMMENDATION

5.1 Conclusion

This special project was successfully done. The researchers were able to develop a

data acquisition system capable of displaying vital signs data like body temperature.

However, the researchers only simulated the value for pulse rate in the data acquisition

device to show that multiple data can reach the embedded web server from the data

acquisition device.

The researchers were also able to implement a simple web server on a

microcontroller unit that serves the web page displaying the data acquired by the data

acquisition device. The web server was customized for the project requirements. The web

server is able to serve dynamic web pages through the aide of AJAX (Asynchronous

JavaScript and XML). The web server can process and serve up to six simultaneous

connections from a single computer together with another connection from another

computer in the same network.

5.2 Recommendation

The researchers had very good results with the system at present, but there is a lot

of room for improvement. The researchers suggest the following improvements:

 88

1. Add more interfaces in the data acquisition device for additional vital signs

sensors.

2. Increase the number of data acquisition devices and add better multiplexing

capabilities on the host controller.

3. Try other wireless communication methods

4. Move the storage of the web pages from flash memory to an external storage like

SD Cards for easier revisions of the web pages.

5. Add database connectivity or support for data logging so that data can be stored

and accessed later.

6. Add a method for changing the IP address, subnet mask and gateway address for

easy integration on local area networks or an alternative is to implement a

Dynamic Host Configuration Protocol (DHCP) in the hardware.

88
 BIBLIOGRAPHY

Books

Paul, Christopher, et.al. The Linux Development Platform Configuring, Using and
Maintaining a Complete Programming Environment. Upper Saddle River, New
Jersey: Pearson Education, Inc. 2003

Special Projects

Napoleon Garde and Jerome Paghasian, JEZ XI: A Wireless Sensor-Remote Controller
Device For an Intelligent, PC-Based, Client-Server MP3 Player System. College
of Engineering, Mindanao State University – Iligan Institute of Technology,
March 2007

Niño Balansag, Loinel Evangelio, Allenn Lowaton, Wireless Temperature Data Logger
Implemented in a Two Point-To-Single Point Topology Utilizing Zigbee Protocol
Through XBee Radio Frequency Transceiver Modules, College of Engineering,
Mindanao State University – Iligan Institute of Technology, March 2008

Internet

Atmel AVR. 2009. 10p. http://en.wikipedia.org/wiki/Atmel_AVR

AJAX. 2009. 4p. http://en.wikipedia.org/wiki/Ajax_(programming)

ATmega32L. 346p. http://www.atmel.com/dyn/resources/prod_documents/doc2503.pdf

Blacharski, Dan. 2003-2008. What is a Microcontroller? 2p.

http://www.wisegeek.com/what-is-a-microcontroller.htm

Bluetooth. 2009. 3p. http://electronics.howstuffworks.com/bluetooth.htm/printable

Data Acquisition. 2009. 4p.

http://zone.ni.com/devzone/cda/tut/p/id/3536

Document Object Model. 2009. 5p.

http://en.wikipedia.org/wiki/Document_Object_Model

Hypertext Transfer Protocol. 2009. 7p. http://en.wikipedia.org/wiki/HTTP

Java Script. 2009. 14p. http://en.wikipedia.org/wiki/JavaScript

 90

Kayne, R. 2003-2008. What is Bluetooth? 2p. http://www.wisegeek.com/what-is-

bluetooth.htm

LifeGuard – A Wearable Vital Signs Monitoring System.

http://lifeguard.stanford.edu/lifeguard_writeup_medium.pdf

List of HTTP status codes. 2009. 6p.

http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Network Topologies. 2009. 3p.

http://compnetworking.about.com/od/networkdesign/a/topologies.htm

Non-Traumatic Emergencies. 2008. 5p.

http://www.healthsystem.virginia.edu/UVAHealth/adult_nontrauma/vital.cf

PIC Microcontroller. 2009. 19p. http://en.wikipedia.org/wiki/PIC_microcontroller

Popular 16F877A. 2005-2008. 4p. http://www.best-microcontroller-

projects.com/16F877A.html

Pulse Oximeter. 2008. http://en.wikipedia.org/wiki/Pulse_oximeter

Taylor Jr., Stanley A. , et.al.2002. Vital signs monitoring system. 9pp.

http://www.freepatentsonline.com/6419630.html

Vital signs monitoring system. 1991. 19p.

http://www.patentstorm.us/patents/5010890/fulltext.html

W. Chen, et. al. 2005. Development of a Multiple Vital Signs Monitoring System for m-
Healthcare. 2p. http://www.rgi.tut.fi/ijbem/volume7/number1/pdf/090.pdf

What is a thermocouple? 2008. 6p. http://www.tech-faq.com/thermocouple.shtml

What is blood pressure? 2008. 3p. http://www.lifeclinic.com/focus/blood/whatisit.asp

W5100_Porting_Guide.pdf
http://www.wiznet.co.kr/rg4_board/down.php?&kw=we&bd_num=15866&key=0
&mode
=down&bbs_code=en_pds
Appendix A

SCHEMATIC DIAGRAMS

Schematic Diagram of Embedded Web Server

Schematic Diagram of Bluetooth Host Controller

Schematic Diagram of Bluetooth Slave Controller/Data Acquisition Device

Schematic Diagram of power supply for Embedded Web Server and Bluetooth Host
Controller
 92

A.1 Schematic Diagram of Embedded Web Server

 93

A.2 Schematic Diagram of Bluetooth Host Controller

 94

A.3 Schematic Diagram of Bluetooth Slave Controller/Data Acquisition Device

 95

A.4 Schematic Diagram of power supply for Embedded Web Server and Bluetooth
Host Controller providing 3.3 Volts supply.
Appendix B

SOURCE CODES

Embedded Web Server source code

Web Pages/Files as a C include file

Wiznet W5100 Driver v1.4 SPI.h ported source code

ROM file maker source code

Web Pages/Files source code

Bluetooth Host Controller source code

Bluetooth Slave Controller/Data Acquisition Device source code

 97

B.1 Embedded Web Server source code

//Embedded Web Server firmware source code created from DEV-
//C++( version 4.9.9.2) and AVR Studio(version 4.15)

//When this is build and compiled in AVR Studio, this will be compiled
//as the embedded web server
//If compiled in DEV-C++, this will be build and compiled as an
//executable file for windows

#include <stdio.h>
#include <string.h>
#include <stdarg.h>
#include <ctype.h>
#include <stdlib.h>
#define HTTP_PORT 80
#define INBUFSIZE 40
#ifdef AVR
#include <avr/io.h>
#include "W5100/types.h"
#include "W5100/w5100.h"
#include "W5100/socket.h"
#include <avr\pgmspace.h>
#include <avr\eeprom.h>
#include <util\delay.h>
#define BAUD 9600UL
#define MUBBR ((F_CPU/16/BAUD) -1)
#include <avr/interrupt.h>
//hardware/mac address
EEMEM uint8_t mac_addr[6]={ 0x00, 0x0D, 0xF0, 0x3C, 0x3F, 0xAB };
//ip address
EEMEM uint8_t ip_addr[4]={10,10,25,195}; //-->dsp lab
//subnet mask
EEMEM uint8_t netmask[4]={255,255,248,0}; //-->dsp lab
//gateway address
EEMEM uint8_t gate_addr[4]={10,10,31,254};// -->dsp lab
#define prtf(fmt, args...) prtf_P(PSTR(fmt), ##args)
#else
#include <winsock.h>
 98

#include <stdint.h>
#define send(a,b,c) send(a,b,c,0)
#define recv(a,b,c) recv(a,b,c,0)
#define pgm_read_byte_near(p) (*(p))
#define PGM_VOID_P uint8_t*
#define memcpy_P(a,b,c) memcpy(a,b,c)
#define prog_uchar uint8_t
#define prtf(fmt, args...) prtf_P(fmt, ##args)
#endif
#include "pages.inc" //webpages definitions
//success http response header
prog_uchar hdr[]="HTTP/1.0 200 OK\r\nContent-Type: text/html \r\n\r\n";

int num_files;
SOCKET clientSocket,serverSocket;
uint8_t inBuf[INBUFSIZE];//input buffer
uint8_t startRcv=0;//start receiving flag
uint8_t dataRcv[8]={0,0,0,0,0,0,0,0};//initial data
uint8_t data_idx=0;//dataRcv indexer

static uint8_t outBuf[180]; //output buffer

static uint8_t *outBufPtr = outBuf;// pointer to output buffer

//flush output
void net_oflush() {
if (outBufPtr != outBuf){
send(clientSocket, outBuf, outBufPtr-outBuf);
}
outBufPtr = outBuf;
}

//send a block of data from program space

void net_write_P(PGM_VOID_P buf, uint16_t cnt)
{
net_oflush(); // flush buffer to output
while (cnt) {
uint16_t n = cnt;
if (n > sizeof(outBuf)) //if bufsize is less than filesize
 99

n = sizeof(outBuf); //set n=bufsize

memcpy_P(outBuf, buf, n);
send(clientSocket, outBuf, n);
cnt -= n; //reduce the filesize by the amount sent
buf += n; //offset file by n words
}
}
//put a character to output buffer
void net_putc(char c) {
if (outBufPtr == &outBuf[sizeof(outBuf)])
net_oflush();//flush output buffer if not empty
*outBufPtr++ = c;
}
void prtf_P(char *fmt, ...)
{
char numbuf[5];
va_list argp;
va_start(argp, fmt);
char *fmtp = fmt;
char c;
while ((c=pgm_read_byte_near(fmtp++)) != '\0') {
if (c == '%') {
c = pgm_read_byte_near(fmtp++);
char *str;
// possible formats are %s, %d and %e
if (c == 's') {
str = va_arg(argp, char *);
}
else if(c=='d') {
uint16_t n = va_arg(argp, int);
#ifdef AVR
str = utoa(n, numbuf, 10);
#else
sprintf(numbuf, "%d", n);
str = numbuf;
#endif
}
else{
 100

double n = va_arg(argp, double);

sprintf(numbuf, "%e", n);
str = numbuf;
}
while (*str) {
net_putc(*str); ///
str++;
}
}
else net_putc(c); ///!
}
va_end(argp);
}
#ifndef AVR
//random temperature and pulse rate data for testing
void getdata(){
int i;
for(i=0;i<4;i++){
dataRcv[2*i]=(rand()%9) + 35;//temperature
dataRcv[2*i+1]=(rand()%150) + 50; //pulse rate
}

}
#endif
//sends vsigns.htm
void vsigns(){
int i;
net_write_P(hdr,sizeof(hdr)-1);
#ifndef AVR
//if compiling for windows, get random data for testing
getdata();
#endif
for(i=0;i<4;i++){

prtf("%d,%d|",dataRcv[2*i],dataRcv[2*i+1]);//temperature,pulse rate
net_oflush();
}
}
 101

//file system struct

struct fileSys{
char *name;// filename
void (*dynamicFile)();//dynamic file-->pointer to a function
uint8_t *fileAddr; //pointer to the start of the file
uint16_t filesize; // filesize to determine the end of file
}romFS[]={
{"vsigns.htm",vsigns,0,0},
{"ajax.js",0,ajax_js,sizeof(ajax_js)},
{"index.htm",0,index_htm ,sizeof(index_htm)},
{"sty.css",0,sty_css,sizeof(sty_css)}
};
//send an error msg according to error status
//only error 404 and 405 are used
//error 405 method unsupported
//error 404 file not found
void OutputHTTPError(int statuscode)
{
prtf("HTTP/1.0 %d\r\nContent-Type:text/html\r\n\r\n",statuscode);
prtf("<html><body><h2>Error: %d</h2></body></html>",statuscode);
net_oflush();
}
//serve file given a filename
void serveFile(char filename[]){
int i;
for(i=0;i<num_files;i++){
if(strcmp(romFS[i].name,filename)==0){
if(romFS[i].dynamicFile!=NULL)
(romFS[i].dynamicFile)();
else{
net_write_P(hdr,sizeof(hdr)-1);
net_write_P(romFS[i].fileAddr,romFS[i].filesize);
}
return;
}
}
OutputHTTPError(404);//file not in the file system
}
 102

static uint8_t current_msg_size, fragmented_msg_ind;

//recv a network data by character
uint8_t net_getc() {
//if fragment index is >= to current recv size
//recv remaining until n<= INBUFSIZE
if (fragmented_msg_ind >= current_msg_size) {
#ifndef AVR
current_msg_size = recv(clientSocket, inBuf, INBUFSIZE);
#else
for (;;) {
//know the size of recv data
uint16_t n = getSn_RX_RSR(clientSocket);
if (n == 0) {
continue;
}
//fragment the total receive buffer by INBUFSIZE
if (n > INBUFSIZE) n = INBUFSIZE;
current_msg_size = recv(clientSocket, inBuf, n);
inBuf[current_msg_size] = '\0'; // needed ???
break;
}
#endif
//reset fragment index
fragmented_msg_ind = 0;
}
//return only the character indexed by the
//fragment index
return inBuf[fragmented_msg_ind++];
}
//empty input buffer
void flushInput(){
uint8_t nnl = 0;
char c;
while(nnl!=2){
c = net_getc();
if (c == '\n') {
nnl++;
}
 103

else if (c != '\r')
nnl = 0;
}
current_msg_size = fragmented_msg_ind = 0;
}
// http handler function
void httpServe(){
char filename[30],c;
int cnt=0;
filename[0]=0;
//parse http method
if (toupper(net_getc()) != 'G' ||
toupper(net_getc()) != 'E' ||
toupper(net_getc()) != 'T' ||
net_getc() != ' ') {
OutputHTTPError(405); //method is not "GET"
flushInput();//reject the succeeding data
return;
}
//get the file requested
while ((c=net_getc())!=' ' && c != '?') {
if(c!='/'){
filename[cnt++]=tolower(c);
}
}
//in case of empty file request
//send index.htm
//eg. http://192.168.0.2
if(filename[0]==0){
strcpy(filename,"index.htm");
cnt=9;
}
filename[cnt]=0;
serveFile(filename);
flushInput();
}
#ifdef AVR
//if comipling for AVR, tell compiler to compiler the
 104

//ff. functions and main function

//socket status checker

void socketServer(uint8_t sid){
switch ( getSn_SR(sid) ) { // sock status
case SOCK_CLOSED:
if (socket(sid, Sn_MR_TCP, HTTP_PORT, 0x00) == 0 ||
listen(sid) == 0) {
}
break;
case SOCK_LISTEN:
break;
case SOCK_ESTABLISHED:
if ( getSn_RX_RSR(sid) ) { // bytes available
clientSocket = sid;
httpServe();
disconnect(sid);
}
break;
case SOCK_CLOSE_WAIT:
disconnect(sid);
close(sid);
break;
}
}
//initialize w5100 chip
void w5100_init()
{
// reset
DDRB |= 0x08;
PORTB &= ~0x08; // reset line
_delay_ms(4);
PORTB |= 0x08; // reset line
// read back values from eeprom
u_char ip[6];
eeprom_read_block(ip, mac_addr, 6); // mac_addr
setSHAR( ip );
eeprom_read_block(ip, netmask, 4); // netmask
 105

setSUBR( ip );
eeprom_read_block(ip, ip_addr, 4); // ip
setSIPR( ip );
eeprom_read_block(ip, gate_addr, 4);// gateway
setGAR( ip );
sysinit(0x55, 0x55);
}

int main(){
int i=0;
w5100_init();
//usart initialization
UCSRB = (1<<RXCIE)|(1<<RXEN); //only interrupt-based recv is used
UCSRC = (1<<URSEL)|(0<<UMSEL)
|(0<<UPM1)|(0<<UPM0)
|(0<<USBS)|(1<<UCSZ1)|(1<<UCSZ0);
UBRRH = (uint8_t)(MUBBR>>8);
UBRRL = (uint8_t)MUBBR;
DDRD=0x02;
//end of usart initialization
sei();//enable global interrupt
// poll all four sockets
num_files=sizeof(romFS)/sizeof(struct fileSys);
while(1) {
socketServer(0);
i++;
if(i>=4)
i=0;
}
return 0;
}
ISR(USART_RXC_vect){
char ReceivedByte;
ReceivedByte = UDR;
//start receiving only if
//number 2 is received
if(ReceivedByte==2)
startRcv=1;
 106

else if(startRcv==1){
dataRcv[data_idx]=ReceivedByte;
data_idx++;
}
if (data_idx>=8){
data_idx=0;
startRcv=0;
}

}
#else
//else webserver is compiled for the windows
void sockServer(short nPort)
{
// Create a TCP/IP stream socket to "listen" with
serverSocket = socket(AF_INET, // Address family
SOCK_STREAM, // Socket
type
0); // Protocol
if (serverSocket == INVALID_SOCKET)
{
printf("socket()");
return;
}
// Fill in the address structure
SOCKADDR_IN saServer;
saServer.sin_family = AF_INET;

// Let WinSock supply address

saServer.sin_addr.s_addr = INADDR_ANY;
saServer.sin_port = htons(nPort); // Use port from command line

if (bind(serverSocket,(LPSOCKADDR)&saServer,sizeof(struct
sockaddr)) == SOCKET_ERROR) // bind the name to the socket
{
printf("bind()");
closesocket(serverSocket);
return;
 107

}
int nLen;
nLen = sizeof(SOCKADDR);
if (gethostname(inBuf, INBUFSIZE) == SOCKET_ERROR)
{
printf("gethostname()");
closesocket(serverSocket);
return;
}
// Show the server name and port number
printf("\nServer named %s waiting on port %d\n",
inBuf, nPort);
// Set the socket to listen
printf("\nlisten()");
if (listen(serverSocket,10)== SOCKET_ERROR)
{
printf("listen()");
closesocket(serverSocket);
return;
}
// Wait for an incoming request
for(;;){
printf("\nWaiting for browser request...");
clientSocket = accept(serverSocket,NULL,NULL);
if (serverSocket == INVALID_SOCKET){
printf("\nRequest accepted!");
closesocket(serverSocket);
return ;
}
httpServe();
printf("\nResponse sent!");
closesocket(clientSocket);
}
closesocket(serverSocket);
}
int main()
{
WORD wVersionRequested = MAKEWORD(1,1);
 108

WSADATA wsaData;
// Initialize WinSock and check version
WSAStartup(wVersionRequested, &wsaData);
if (wsaData.wVersion != wVersionRequested)
{
return 0;
}
num_files=sizeof(romFS)/sizeof(struct fileSys);
sockServer(80);
WSACleanup();
}
#endif
 109

B.2 Web Pages/Files as a C include file

//pages.inc
//generated by the rom file maker
//the C include conversion of the web files:
//index.htm----index_htm
//sty.css--------sty_css
//ajax.js--------ajax_js

prog_uchar index_htm[]={
0x3C, 0x68, 0x74, 0x6D, 0x6C, 0x3E, 0x0A, 0x3C, 0x68, 0x65, 0x61,
0x64, 0x3E, 0x0A, 0x3C, 0x74, 0x69, 0x74, 0x6C, 0x65, 0x3E, 0x45,
0x42, 0x57, 0x56, 0x53, 0x4D, 0x3C, 0x2F, 0x74, 0x69, 0x74, 0x6C,
0x65, 0x3E, 0x0A, 0x3C, 0x6C, 0x69, 0x6E, 0x6B, 0x20, 0x68, 0x72,
0x65, 0x66, 0x3D, 0x22, 0x73, 0x74, 0x79, 0x2E, 0x63, 0x73, 0x73,
0x22, 0x20, 0x72, 0x65, 0x6C, 0x3D, 0x22, 0x73, 0x74, 0x79, 0x6C,
0x65, 0x73, 0x68, 0x65, 0x65, 0x74, 0x22, 0x20, 0x74, 0x79, 0x70,
0x65, 0x3D, 0x22, 0x74, 0x65, 0x78, 0x74, 0x2F, 0x63, 0x73, 0x73,
0x22, 0x20, 0x2F, 0x3E, 0x0A, 0x3C, 0x73, 0x63, 0x72, 0x69, 0x70,
0x74, 0x20, 0x6C, 0x61, 0x6E, 0x67, 0x75, 0x61, 0x67, 0x65, 0x3D,
0x22, 0x6A, 0x61, 0x76, 0x61, 0x73, 0x63, 0x72, 0x69, 0x70, 0x74,
0x22, 0x20, 0x73, 0x72, 0x63, 0x3D, 0x22, 0x61, 0x6A, 0x61, 0x78,
0x2E, 0x6A, 0x73, 0x22, 0x3E, 0x3C, 0x2F, 0x73, 0x63, 0x72, 0x69,
0x70, 0x74, 0x3E, 0x0A, 0x3C, 0x62, 0x6F, 0x64, 0x79, 0x20, 0x6F,
0x6E, 0x4C, 0x6F, 0x61, 0x64, 0x3D, 0x27, 0x67, 0x65, 0x74, 0x5F,
0x64, 0x61, 0x74, 0x61, 0x28, 0x29, 0x3B, 0x20, 0x73, 0x65, 0x74,
0x49, 0x6E, 0x74, 0x65, 0x72, 0x76, 0x61, 0x6C, 0x28, 0x22, 0x67,
0x65, 0x74, 0x5F, 0x64, 0x61, 0x74, 0x61, 0x28, 0x29, 0x3B, 0x22,
0x2C, 0x20, 0x35, 0x30, 0x30, 0x30, 0x29, 0x3B, 0x20, 0x0A, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
0x20, 0x20, 0x20, 0x73, 0x65, 0x74, 0x49, 0x6E, 0x74, 0x65, 0x72,
0x76, 0x61, 0x6C, 0x28, 0x22, 0x64, 0x69, 0x73, 0x70, 0x6C, 0x61,
0x79, 0x43, 0x75, 0x72, 0x44, 0x61, 0x74, 0x65, 0x54, 0x69, 0x6D,
0x65, 0x28, 0x29, 0x3B, 0x22, 0x2C, 0x20, 0x31, 0x30, 0x30, 0x30,
0x29, 0x3B, 0x27, 0x3E, 0x0A, 0x20, 0x3C, 0x74, 0x61, 0x62, 0x6C,
0x65, 0x20, 0x61, 0x6C, 0x69, 0x67, 0x6E, 0x3D, 0x20, 0x22, 0x63,
 110

0x65, 0x6E, 0x74, 0x65, 0x72, 0x22, 0x20, 0x77, 0x69, 0x64, 0x74,
0x68, 0x3D, 0x22, 0x31, 0x30, 0x30, 0x25, 0x22, 0x20, 0x62, 0x6F,
0x72, 0x64, 0x65, 0x72, 0x3D, 0x22, 0x31, 0x22, 0x20, 0x63, 0x65,
0x6C, 0x6C, 0x73, 0x70, 0x61, 0x63, 0x69, 0x6E, 0x67, 0x3D, 0x22,
0x35, 0x22, 0x20, 0x63, 0x65, 0x6C, 0x6C, 0x70, 0x61, 0x64, 0x64,
0x69, 0x6E, 0x67, 0x3D, 0x22, 0x31, 0x22, 0x3E, 0x0A, 0x20, 0x20,
0x3C, 0x74, 0x72, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74,
0x64, 0x20, 0x63, 0x6F, 0x6C, 0x73, 0x70, 0x61, 0x6E, 0x3D, 0x38,
0x20, 0x61, 0x6C, 0x69, 0x67, 0x6E, 0x3D, 0x20, 0x22, 0x63, 0x65,
0x6E, 0x74, 0x65, 0x72, 0x22, 0x20, 0x63, 0x6C, 0x61, 0x73, 0x73,
0x3D, 0x22, 0x68, 0x65, 0x61, 0x64, 0x65, 0x72, 0x22, 0x20, 0x3E,
0x0A, 0x09, 0x20, 0x20, 0x20, 0x45, 0x74, 0x68, 0x65, 0x72, 0x6E,
0x65, 0x74, 0x2D, 0x42, 0x61, 0x73, 0x65, 0x64, 0x20, 0x57, 0x69,
0x72, 0x65, 0x6C, 0x65, 0x73, 0x73, 0x20, 0x56, 0x69, 0x74, 0x61,
0x6C, 0x20, 0x53, 0x69, 0x67, 0x6E, 0x73, 0x20, 0x4D, 0x6F, 0x6E,
0x69, 0x74, 0x6F, 0x72, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x2F,
0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x3C, 0x2F, 0x74, 0x72, 0x3E,
0x0A, 0x20, 0x20, 0x3C, 0x74, 0x72, 0x3E, 0x0A, 0x20, 0x20, 0x20,
0x20, 0x3C, 0x74, 0x64, 0x20, 0x63, 0x6F, 0x6C, 0x73, 0x70, 0x61,
0x6E, 0x3D, 0x38, 0x20, 0x49, 0x44, 0x3D, 0x22, 0x73, 0x74, 0x61,
0x74, 0x75, 0x73, 0x22, 0x20, 0x63, 0x6C, 0x61, 0x73, 0x73, 0x3D,
0x22, 0x6C, 0x62, 0x6C, 0x22, 0x3E, 0x3C, 0x2F, 0x74, 0x64, 0x3E,
0x0A, 0x20, 0x20, 0x3C, 0x2F, 0x74, 0x72, 0x3E, 0x0A, 0x20, 0x20,
0x3C, 0x74, 0x72, 0x3E, 0x0A, 0x20, 0x20, 0x3C, 0x74, 0x72, 0x3E,
0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x63, 0x6F,
0x6C, 0x73, 0x70, 0x61, 0x6E, 0x3D, 0x32, 0x20, 0x61, 0x6C, 0x69,
0x67, 0x6E, 0x3D, 0x20, 0x22, 0x63, 0x65, 0x6E, 0x74, 0x65, 0x72,
0x22, 0x20, 0x63, 0x6C, 0x61, 0x73, 0x73, 0x3D, 0x22, 0x44, 0x41,
0x44, 0x75, 0x6E, 0x69, 0x74, 0x22, 0x20, 0x3E, 0x0A, 0x09, 0x20,
0x20, 0x20, 0x20, 0x56, 0x53, 0x20, 0x55, 0x4E, 0x49, 0x54, 0x20,
0x31, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x2F, 0x74, 0x64, 0x3E,
0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x63, 0x6F,
0x6C, 0x73, 0x70, 0x61, 0x6E, 0x3D, 0x32, 0x20, 0x20, 0x61, 0x6C,
0x69, 0x67, 0x6E, 0x3D, 0x20, 0x22, 0x63, 0x65, 0x6E, 0x74, 0x65,
0x72, 0x22, 0x20, 0x63, 0x6C, 0x61, 0x73, 0x73, 0x3D, 0x22, 0x44,
0x41, 0x44, 0x75, 0x6E, 0x69, 0x74, 0x22, 0x20, 0x3E, 0x0A, 0x09,
0x20, 0x20, 0x20, 0x20, 0x56, 0x53, 0x20, 0x55, 0x4E, 0x49, 0x54,
0x20, 0x32, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x2F, 0x74, 0x64,
 111

0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x63,
0x6F, 0x6C, 0x73, 0x70, 0x61, 0x6E, 0x3D, 0x32, 0x20, 0x20, 0x61,
0x6C, 0x69, 0x67, 0x6E, 0x3D, 0x20, 0x22, 0x63, 0x65, 0x6E, 0x74,
0x65, 0x72, 0x22, 0x20, 0x63, 0x6C, 0x61, 0x73, 0x73, 0x3D, 0x22,
0x44, 0x41, 0x44, 0x75, 0x6E, 0x69, 0x74, 0x22, 0x20, 0x3E, 0x0A,
0x20, 0x20, 0x20, 0x20, 0x09, 0x56, 0x53, 0x20, 0x55, 0x4E, 0x49,
0x54, 0x20, 0x33, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x2F, 0x74,
0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20,
0x63, 0x6F, 0x6C, 0x73, 0x70, 0x61, 0x6E, 0x3D, 0x32, 0x20, 0x20,
0x61, 0x6C, 0x69, 0x67, 0x6E, 0x3D, 0x20, 0x22, 0x63, 0x65, 0x6E,
0x74, 0x65, 0x72, 0x22, 0x20, 0x63, 0x6C, 0x61, 0x73, 0x73, 0x3D,
0x22, 0x44, 0x41, 0x44, 0x75, 0x6E, 0x69, 0x74, 0x22, 0x20, 0x3E,
0x0A, 0x09, 0x20, 0x20, 0x20, 0x20, 0x56, 0x53, 0x20, 0x55, 0x4E,
0x49, 0x54, 0x20, 0x34, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x2F,
0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x3C, 0x2F, 0x74, 0x72, 0x3E,
0x0A, 0x20, 0x20, 0x3C, 0x74, 0x72, 0x20, 0x63, 0x6C, 0x61, 0x73,
0x73, 0x3D, 0x22, 0x6C, 0x62, 0x6C, 0x22, 0x3E, 0x0A, 0x20, 0x20,
0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x77, 0x69, 0x64, 0x74, 0x68,
0x3D, 0x22, 0x32, 0x30, 0x25, 0x22, 0x20, 0x3E, 0x54, 0x65, 0x6D,
0x70, 0x65, 0x72, 0x61, 0x74, 0x75, 0x72, 0x65, 0x28, 0x64, 0x65,
0x67, 0x2E, 0x43, 0x29, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20,
0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x77, 0x69, 0x64, 0x74,
0x68, 0x3D, 0x22, 0x35, 0x25, 0x22, 0x20, 0x69, 0x64, 0x3D, 0x22,
0x74, 0x65, 0x6D, 0x70, 0x31, 0x22, 0x3E, 0x3C, 0x2F, 0x74, 0x64,
0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x77,
0x69, 0x64, 0x74, 0x68, 0x3D, 0x22, 0x32, 0x30, 0x25, 0x22, 0x20,
0x3E, 0x54, 0x65, 0x6D, 0x70, 0x65, 0x72, 0x61, 0x74, 0x75, 0x72,
0x65, 0x28, 0x64, 0x65, 0x67, 0x2E, 0x43, 0x29, 0x3A, 0x3C, 0x2F,
0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64,
0x20, 0x77, 0x69, 0x64, 0x74, 0x68, 0x3D, 0x22, 0x35, 0x25, 0x22,
0x20, 0x69, 0x64, 0x3D, 0x22, 0x74, 0x65, 0x6D, 0x70, 0x32, 0x22,
0x3E, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20,
0x3C, 0x74, 0x64, 0x20, 0x77, 0x69, 0x64, 0x74, 0x68, 0x3D, 0x22,
0x32, 0x30, 0x25, 0x22, 0x20, 0x3E, 0x54, 0x65, 0x6D, 0x70, 0x65,
0x72, 0x61, 0x74, 0x75, 0x72, 0x65, 0x28, 0x64, 0x65, 0x67, 0x2E,
0x43, 0x29, 0x3A, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20,
0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x77, 0x69, 0x64, 0x74, 0x68,
0x3D, 0x22, 0x35, 0x25, 0x22, 0x20, 0x69, 0x64, 0x3D, 0x22, 0x74,
 112

0x65, 0x6D, 0x70, 0x33, 0x22, 0x3E, 0x3C, 0x2F, 0x74, 0x64, 0x3E,
0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x77, 0x69,
0x64, 0x74, 0x68, 0x3D, 0x22, 0x32, 0x30, 0x25, 0x22, 0x20, 0x3E,
0x54, 0x65, 0x6D, 0x70, 0x65, 0x72, 0x61, 0x74, 0x75, 0x72, 0x65,
0x28, 0x64, 0x65, 0x67, 0x2E, 0x43, 0x29, 0x3A, 0x3C, 0x2F, 0x74,
0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20,
0x77, 0x69, 0x64, 0x74, 0x68, 0x3D, 0x22, 0x35, 0x25, 0x22, 0x20,
0x69, 0x64, 0x3D, 0x22, 0x74, 0x65, 0x6D, 0x70, 0x34, 0x22, 0x3E,
0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x3C, 0x2F, 0x74,
0x72, 0x3E, 0x0A, 0x20, 0x20, 0x3C, 0x74, 0x72, 0x20, 0x63, 0x6C,
0x61, 0x73, 0x73, 0x3D, 0x22, 0x6C, 0x62, 0x6C, 0x22, 0x3E, 0x0A,
0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x3E, 0x50, 0x75,
0x6C, 0x73, 0x65, 0x20, 0x52, 0x61, 0x74, 0x65, 0x28, 0x42, 0x50,
0x4D, 0x29, 0x3A, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20,
0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x69, 0x64, 0x3D, 0x22, 0x70,
0x75, 0x6C, 0x73, 0x65, 0x31, 0x22, 0x3E, 0x3C, 0x2F, 0x74, 0x64,
0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x3E,
0x50, 0x75, 0x6C, 0x73, 0x65, 0x20, 0x52, 0x61, 0x74, 0x65, 0x28,
0x42, 0x50, 0x4D, 0x29, 0x3A, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A,
0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x69, 0x64, 0x3D,
0x22, 0x70, 0x75, 0x6C, 0x73, 0x65, 0x32, 0x22, 0x3E, 0x3C, 0x2F,
0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64,
0x20, 0x3E, 0x50, 0x75, 0x6C, 0x73, 0x65, 0x20, 0x52, 0x61, 0x74,
0x65, 0x28, 0x42, 0x50, 0x4D, 0x29, 0x3A, 0x3C, 0x2F, 0x74, 0x64,
0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x69,
0x64, 0x3D, 0x22, 0x70, 0x75, 0x6C, 0x73, 0x65, 0x33, 0x22, 0x3E,
0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C,
0x74, 0x64, 0x20, 0x3E, 0x50, 0x75, 0x6C, 0x73, 0x65, 0x20, 0x52,
0x61, 0x74, 0x65, 0x28, 0x42, 0x50, 0x4D, 0x29, 0x3A, 0x3C, 0x2F,
0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64,
0x20, 0x69, 0x64, 0x3D, 0x22, 0x70, 0x75, 0x6C, 0x73, 0x65, 0x34,
0x22, 0x3E, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x3C,
0x2F, 0x74, 0x72, 0x3E, 0x0A, 0x20, 0x20, 0x3C, 0x74, 0x72, 0x20,
0x63, 0x6C, 0x61, 0x73, 0x73, 0x3D, 0x22, 0x6C, 0x62, 0x6C, 0x22,
0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x3E,
0x55, 0x6E, 0x69, 0x74, 0x20, 0x53, 0x74, 0x61, 0x74, 0x75, 0x73,
0x3A, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20,
0x3C, 0x74, 0x64, 0x20, 0x69, 0x64, 0x3D, 0x22, 0x73, 0x74, 0x61,
 113

0x74, 0x31, 0x22, 0x3E, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20,
0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x3E, 0x55, 0x6E, 0x69,
0x74, 0x20, 0x53, 0x74, 0x61, 0x74, 0x75, 0x73, 0x3A, 0x3C, 0x2F,
0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64,
0x20, 0x69, 0x64, 0x3D, 0x22, 0x73, 0x74, 0x61, 0x74, 0x32, 0x22,
0x3E, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20,
0x3C, 0x74, 0x64, 0x20, 0x3E, 0x55, 0x6E, 0x69, 0x74, 0x20, 0x53,
0x74, 0x61, 0x74, 0x75, 0x73, 0x3A, 0x3C, 0x2F, 0x74, 0x64, 0x3E,
0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x69, 0x64,
0x3D, 0x22, 0x73, 0x74, 0x61, 0x74, 0x33, 0x22, 0x3E, 0x3C, 0x2F,
0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64,
0x20, 0x3E, 0x55, 0x6E, 0x69, 0x74, 0x20, 0x53, 0x74, 0x61, 0x74,
0x75, 0x73, 0x3A, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20,
0x20, 0x20, 0x3C, 0x74, 0x64, 0x20, 0x69, 0x64, 0x3D, 0x22, 0x73,
0x74, 0x61, 0x74, 0x34, 0x22, 0x3E, 0x3C, 0x2F, 0x74, 0x64, 0x3E,
0x0A, 0x20, 0x20, 0x3C, 0x2F, 0x74, 0x72, 0x3E, 0x0A, 0x20, 0x20,
0x3C, 0x74, 0x72, 0x20, 0x63, 0x6C, 0x61, 0x73, 0x73, 0x3D, 0x22,
0x6C, 0x62, 0x6C, 0x22, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C,
0x74, 0x64, 0x20, 0x63, 0x6F, 0x6C, 0x73, 0x70, 0x61, 0x6E, 0x3D,
0x38, 0x20, 0x69, 0x64, 0x3D, 0x22, 0x72, 0x65, 0x63, 0x65, 0x69,
0x76, 0x65, 0x44, 0x61, 0x74, 0x65, 0x22, 0x3E, 0x26, 0x6E, 0x62,
0x73, 0x70, 0x3B, 0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20,
0x3C, 0x2F, 0x74, 0x72, 0x3E, 0x0A, 0x20, 0x20, 0x3C, 0x74, 0x72,
0x20, 0x63, 0x6C, 0x61, 0x73, 0x73, 0x3D, 0x22, 0x6C, 0x62, 0x6C,
0x22, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C, 0x74, 0x64, 0x20,
0x63, 0x6F, 0x6C, 0x73, 0x70, 0x61, 0x6E, 0x3D, 0x36, 0x20, 0x69,
0x64, 0x3D, 0x22, 0x72, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x44,
0x61, 0x74, 0x65, 0x22, 0x3E, 0x26, 0x6E, 0x62, 0x73, 0x70, 0x3B,
0x3C, 0x2F, 0x74, 0x64, 0x3E, 0x0A, 0x09, 0x3C, 0x74, 0x64, 0x20,
0x63, 0x6F, 0x6C, 0x73, 0x70, 0x61, 0x6E, 0x3D, 0x32, 0x20, 0x69,
0x64, 0x3D, 0x22, 0x6C, 0x61, 0x74, 0x65, 0x6E, 0x63, 0x79, 0x22,
0x3E, 0x26, 0x6E, 0x62, 0x73, 0x70, 0x3B, 0x3C, 0x2F, 0x74, 0x64,
0x3E, 0x0A, 0x20, 0x20, 0x3C, 0x2F, 0x74, 0x72, 0x3E, 0x0A, 0x20,
0x20, 0x3C, 0x74, 0x72, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x3C,
0x74, 0x64, 0x20, 0x63, 0x6C, 0x61, 0x73, 0x73, 0x3D, 0x27, 0x66,
0x6F, 0x6F, 0x74, 0x65, 0x72, 0x27, 0x20, 0x63, 0x6F, 0x6C, 0x73,
0x70, 0x61, 0x6E, 0x3D, 0x38, 0x3E, 0x3C, 0x70, 0x3E, 0x54, 0x68,
0x65, 0x20, 0x64, 0x61, 0x74, 0x61, 0x20, 0x6F, 0x6E, 0x20, 0x74,
 114

0x68, 0x69, 0x73, 0x20, 0x77, 0x65, 0x62, 0x20, 0x61, 0x70, 0x70,
0x6C, 0x69, 0x63, 0x61, 0x74, 0x69, 0x6F, 0x6E, 0x20, 0x69, 0x73,
0x20, 0x66, 0x72, 0x6F, 0x6D, 0x20, 0x74, 0x68, 0x65, 0x20, 0x0A,
0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x64, 0x61, 0x74, 0x61,
0x20, 0x61, 0x63, 0x71, 0x75, 0x69, 0x73, 0x69, 0x74, 0x69, 0x6F,
0x6E, 0x20, 0x64, 0x65, 0x76, 0x69, 0x63, 0x65, 0x2C, 0x20, 0x70,
0x72, 0x6F, 0x63, 0x65, 0x73, 0x73, 0x65, 0x64, 0x20, 0x61, 0x6E,
0x64, 0x20, 0x66, 0x6F, 0x72, 0x6D, 0x61, 0x74, 0x74, 0x65, 0x64,
0x20, 0x62, 0x79, 0x20, 0x74, 0x68, 0x65, 0x20, 0x62, 0x6C, 0x75,
0x65, 0x74, 0x6F, 0x6F, 0x74, 0x68, 0x20, 0x68, 0x6F, 0x73, 0x74,
0x20, 0x20, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x4D,
0x43, 0x55, 0x20, 0x28, 0x50, 0x49, 0x43, 0x31, 0x36, 0x66, 0x38,
0x37, 0x37, 0x41, 0x29, 0x20, 0x61, 0x6E, 0x64, 0x20, 0x74, 0x68,
0x65, 0x6E, 0x20, 0x69, 0x6E, 0x73, 0x65, 0x72, 0x74, 0x65, 0x64,
0x20, 0x69, 0x6E, 0x20, 0x61, 0x6E, 0x20, 0x65, 0x6D, 0x62, 0x65,
0x64, 0x64, 0x65, 0x64, 0x20, 0x64, 0x79, 0x6E, 0x61, 0x6D, 0x69,
0x63, 0x20, 0x77, 0x65, 0x62, 0x70, 0x61, 0x67, 0x65, 0x20, 0x69,
0x6E, 0x20, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x74,
0x68, 0x65, 0x20, 0x20, 0x4D, 0x43, 0x55, 0x2D, 0x62, 0x61, 0x73,
0x65, 0x64, 0x20, 0x28, 0x41, 0x54, 0x4D, 0x45, 0x47, 0x41, 0x33,
0x32, 0x4C, 0x29, 0x20, 0x77, 0x65, 0x62, 0x73, 0x65, 0x72, 0x76,
0x65, 0x72, 0x2E, 0x20, 0x3C, 0x2F, 0x70, 0x3E, 0x0A, 0x20, 0x20,
0x20, 0x20, 0x20, 0x20, 0x3C, 0x70, 0x3E, 0x4B, 0x69, 0x73, 0x74,
0x65, 0x72, 0x20, 0x47, 0x65, 0x6E, 0x65, 0x73, 0x69, 0x73, 0x20,
0x20, 0x4A, 0x69, 0x6D, 0x65, 0x6E, 0x65, 0x7A, 0x20, 0x28, 0x41,
0x54, 0x4D, 0x45, 0x47, 0x41, 0x33, 0x32, 0x4C, 0x20, 0x66, 0x69,
0x72, 0x6D, 0x77, 0x61, 0x72, 0x65, 0x20, 0x66, 0x6F, 0x72, 0x20,
0x65, 0x6D, 0x62, 0x65, 0x64, 0x64, 0x65, 0x64, 0x20, 0x77, 0x65,
0x62, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x61, 0x6E, 0x64,
0x20, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x77,
0x65, 0x62, 0x70, 0x61, 0x67, 0x65, 0x73, 0x29, 0x3C, 0x62, 0x72,
0x2F, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
0x41, 0x72, 0x76, 0x69, 0x6E, 0x20, 0x44, 0x69, 0x61, 0x6F, 0x20,
0x4D, 0x69, 0x72, 0x61, 0x6E, 0x64, 0x61, 0x20, 0x28, 0x50, 0x49,
0x43, 0x31, 0x36, 0x66, 0x38, 0x37, 0x37, 0x41, 0x20, 0x66, 0x69,
0x72, 0x6D, 0x77, 0x61, 0x72, 0x65, 0x20, 0x66, 0x6F, 0x72, 0x20,
0x62, 0x6C, 0x75, 0x65, 0x74, 0x6F, 0x6F, 0x74, 0x68, 0x20, 0x63,
0x6F, 0x6D, 0x6D, 0x75, 0x6E, 0x69, 0x63, 0x61, 0x74, 0x69, 0x6F,
 115

0x6E, 0x20, 0x61, 0x6E, 0x64, 0x20, 0x0A, 0x20, 0x20, 0x20, 0x20,
0x20, 0x20, 0x20, 0x20, 0x64, 0x61, 0x74, 0x61, 0x20, 0x61, 0x63,
0x71, 0x75, 0x69, 0x73, 0x69, 0x74, 0x69, 0x6F, 0x6E, 0x29, 0x3C,
0x62, 0x72, 0x2F, 0x3E, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
0x20, 0x20, 0x44, 0x79, 0x6C, 0x20, 0x54, 0x68, 0x65, 0x72, 0x65,
0x73, 0x65, 0x20, 0x4D, 0x65, 0x73, 0x69, 0x6E, 0x61, 0x20, 0x28,
0x68, 0x61, 0x72, 0x64, 0x77, 0x61, 0x72, 0x65, 0x20, 0x66, 0x6F,
0x72, 0x20, 0x65, 0x6D, 0x62, 0x65, 0x64, 0x64, 0x65, 0x64, 0x20,
0x77, 0x65, 0x62, 0x2C, 0x20, 0x62, 0x6C, 0x75, 0x65, 0x74, 0x6F,
0x6F, 0x74, 0x68, 0x20, 0x63, 0x6F, 0x6D, 0x6D, 0x75, 0x6E, 0x69,
0x63, 0x61, 0x74, 0x69, 0x6F, 0x6E, 0x20, 0x61, 0x6E, 0x64, 0x20,
0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x64, 0x61,
0x74, 0x61, 0x20, 0x61, 0x63, 0x71, 0x75, 0x69, 0x73, 0x69, 0x74,
0x69, 0x6F, 0x6E, 0x29, 0x20, 0x3C, 0x2F, 0x70, 0x3E, 0x3C, 0x2F,
0x74, 0x64, 0x3E, 0x0A, 0x20, 0x20, 0x3C, 0x2F, 0x74, 0x72, 0x3E,
0x0A, 0x3C, 0x2F, 0x74, 0x61, 0x62, 0x6C, 0x65, 0x3E, 0x0A, 0x3C,
0x2F, 0x62, 0x6F, 0x64, 0x79, 0x3E, 0x0A, 0x3C, 0x2F, 0x68, 0x74,
0x6D, 0x6C, 0x3E, 0x0A
};
prog_uchar ajax_js[]={
0x66, 0x75, 0x6E, 0x63, 0x74, 0x69, 0x6F, 0x6E, 0x20, 0x69, 0x6E,
0x69, 0x74, 0x41, 0x6A, 0x61, 0x78, 0x28, 0x29, 0x7B, 0x0A, 0x20,
0x76, 0x61, 0x72, 0x20, 0x78, 0x6D, 0x6C, 0x48, 0x74, 0x74, 0x70,
0x3D, 0x6E, 0x75, 0x6C, 0x6C, 0x3B, 0x0A, 0x20, 0x74, 0x72, 0x79,
0x7B, 0x20, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x78, 0x6D, 0x6C, 0x48,
0x74, 0x74, 0x70, 0x3D, 0x6E, 0x65, 0x77, 0x20, 0x58, 0x4D, 0x4C,
0x48, 0x74, 0x74, 0x70, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74,
0x28, 0x29, 0x3B, 0x0A, 0x20, 0x7D, 0x63, 0x61, 0x74, 0x63, 0x68,
0x20, 0x28, 0x65, 0x29, 0x7B, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x74,
0x72, 0x79, 0x20, 0x7B, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
0x20, 0x20, 0x78, 0x6D, 0x6C, 0x48, 0x74, 0x74, 0x70, 0x3D, 0x6E,
0x65, 0x77, 0x20, 0x41, 0x63, 0x74, 0x69, 0x76, 0x65, 0x58, 0x4F,
0x62, 0x6A, 0x65, 0x63, 0x74, 0x28, 0x22, 0x4D, 0x73, 0x78, 0x6D,
0x6C, 0x32, 0x2E, 0x58, 0x4D, 0x4C, 0x48, 0x54, 0x54, 0x50, 0x22,
0x29, 0x3B, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x7D, 0x63, 0x61, 0x74,
0x63, 0x68, 0x20, 0x28, 0x65, 0x29, 0x7B, 0x20, 0x0A, 0x20, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x78, 0x6D, 0x6C, 0x48, 0x74,
0x74, 0x70, 0x3D, 0x6E, 0x65, 0x77, 0x20, 0x41, 0x63, 0x74, 0x69,
 116

0x76, 0x65, 0x58, 0x4F, 0x62, 0x6A, 0x65, 0x63, 0x74, 0x28, 0x22,
0x4D, 0x69, 0x63, 0x72, 0x6F, 0x73, 0x6F, 0x66, 0x74, 0x2E, 0x58,
0x4D, 0x4C, 0x48, 0x54, 0x54, 0x50, 0x22, 0x29, 0x3B, 0x20, 0x7D,
0x0A, 0x20, 0x20, 0x20, 0x7D, 0x0A, 0x20, 0x72, 0x65, 0x74, 0x75,
0x72, 0x6E, 0x20, 0x78, 0x6D, 0x6C, 0x48, 0x74, 0x74, 0x70, 0x3B,
0x0A, 0x7D, 0x0A, 0x20, 0x76, 0x61, 0x72, 0x20, 0x72, 0x65, 0x63,
0x76, 0x44, 0x61, 0x74, 0x65, 0x3B, 0x0A, 0x20, 0x66, 0x75, 0x6E,
0x63, 0x74, 0x69, 0x6F, 0x6E, 0x20, 0x67, 0x65, 0x74, 0x5F, 0x64,
0x61, 0x74, 0x61, 0x28, 0x29, 0x7B, 0x0A, 0x20, 0x76, 0x61, 0x72,
0x20, 0x73, 0x69, 0x6D, 0x70, 0x6C, 0x65, 0x61, 0x6A, 0x61, 0x78,
0x20, 0x3D, 0x20, 0x6E, 0x65, 0x77, 0x20, 0x69, 0x6E, 0x69, 0x74,
0x41, 0x6A, 0x61, 0x78, 0x28, 0x29, 0x3B, 0x0A, 0x20, 0x76, 0x61,
0x72, 0x20, 0x74, 0x65, 0x6D, 0x70, 0x20, 0x3D, 0x20, 0x6E, 0x65,
0x77, 0x20, 0x41, 0x72, 0x72, 0x61, 0x79, 0x28, 0x64, 0x6F, 0x63,
0x75, 0x6D, 0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C,
0x65, 0x6D, 0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22,
0x74, 0x65, 0x6D, 0x70, 0x31, 0x22, 0x29, 0x2C, 0x64, 0x6F, 0x63,
0x75, 0x6D, 0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C,
0x65, 0x6D, 0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22,
0x74, 0x65, 0x6D, 0x70, 0x32, 0x22, 0x29, 0x2C, 0x64, 0x6F, 0x63,
0x75, 0x6D, 0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C,
0x65, 0x6D, 0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22,
0x74, 0x65, 0x6D, 0x70, 0x33, 0x22, 0x29, 0x2C, 0x64, 0x6F, 0x63,
0x75, 0x6D, 0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C,
0x65, 0x6D, 0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22,
0x74, 0x65, 0x6D, 0x70, 0x34, 0x22, 0x29, 0x29, 0x3B, 0x0A, 0x20,
0x76, 0x61, 0x72, 0x20, 0x70, 0x75, 0x6C, 0x73, 0x65, 0x20, 0x3D,
0x20, 0x6E, 0x65, 0x77, 0x20, 0x41, 0x72, 0x72, 0x61, 0x79, 0x28,
0x64, 0x6F, 0x63, 0x75, 0x6D, 0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65,
0x74, 0x45, 0x6C, 0x65, 0x6D, 0x65, 0x6E, 0x74, 0x42, 0x79, 0x49,
0x64, 0x28, 0x22, 0x70, 0x75, 0x6C, 0x73, 0x65, 0x31, 0x22, 0x29,
0x2C, 0x64, 0x6F, 0x63, 0x75, 0x6D, 0x65, 0x6E, 0x74, 0x2E, 0x67,
0x65, 0x74, 0x45, 0x6C, 0x65, 0x6D, 0x65, 0x6E, 0x74, 0x42, 0x79,
0x49, 0x64, 0x28, 0x22, 0x70, 0x75, 0x6C, 0x73, 0x65, 0x32, 0x22,
0x29, 0x2C, 0x64, 0x6F, 0x63, 0x75, 0x6D, 0x65, 0x6E, 0x74, 0x2E,
0x67, 0x65, 0x74, 0x45, 0x6C, 0x65, 0x6D, 0x65, 0x6E, 0x74, 0x42,
0x79, 0x49, 0x64, 0x28, 0x22, 0x70, 0x75, 0x6C, 0x73, 0x65, 0x33,
0x22, 0x29, 0x2C, 0x64, 0x6F, 0x63, 0x75, 0x6D, 0x65, 0x6E, 0x74,
 117

0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C, 0x65, 0x6D, 0x65, 0x6E, 0x74,
0x42, 0x79, 0x49, 0x64, 0x28, 0x22, 0x70, 0x75, 0x6C, 0x73, 0x65,
0x34, 0x22, 0x29, 0x29, 0x3B, 0x0A, 0x20, 0x76, 0x61, 0x72, 0x20,
0x73, 0x74, 0x61, 0x74, 0x20, 0x3D, 0x20, 0x6E, 0x65, 0x77, 0x20,
0x41, 0x72, 0x72, 0x61, 0x79, 0x28, 0x64, 0x6F, 0x63, 0x75, 0x6D,
0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C, 0x65, 0x6D,
0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22, 0x73, 0x74,
0x61, 0x74, 0x31, 0x22, 0x29, 0x2C, 0x64, 0x6F, 0x63, 0x75, 0x6D,
0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C, 0x65, 0x6D,
0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22, 0x73, 0x74,
0x61, 0x74, 0x32, 0x22, 0x29, 0x2C, 0x64, 0x6F, 0x63, 0x75, 0x6D,
0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C, 0x65, 0x6D,
0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22, 0x73, 0x74,
0x61, 0x74, 0x33, 0x22, 0x29, 0x2C, 0x64, 0x6F, 0x63, 0x75, 0x6D,
0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C, 0x65, 0x6D,
0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22, 0x73, 0x74,
0x61, 0x74, 0x34, 0x22, 0x29, 0x29, 0x3B, 0x0A, 0x20, 0x76, 0x61,
0x72, 0x20, 0x76, 0x73, 0x69, 0x67, 0x6E, 0x73, 0x3D, 0x20, 0x6E,
0x65, 0x77, 0x20, 0x41, 0x72, 0x72, 0x61, 0x79, 0x28, 0x29, 0x3B,
0x0A, 0x20, 0x76, 0x61, 0x72, 0x20, 0x72, 0x65, 0x71, 0x44, 0x61,
0x74, 0x65, 0x3D, 0x6E, 0x65, 0x77, 0x20, 0x44, 0x61, 0x74, 0x65,
0x28, 0x29, 0x3B, 0x0A, 0x20, 0x64, 0x6F, 0x63, 0x75, 0x6D, 0x65,
0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C, 0x65, 0x6D, 0x65,
0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22, 0x72, 0x65, 0x71,
0x75, 0x65, 0x73, 0x74, 0x44, 0x61, 0x74, 0x65, 0x22, 0x29, 0x2E,
0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D, 0x4C, 0x3D, 0x22,
0x44, 0x61, 0x74, 0x61, 0x20, 0x72, 0x65, 0x71, 0x75, 0x65, 0x73,
0x74, 0x65, 0x64, 0x20, 0x6F, 0x6E, 0x3A, 0x20, 0x22, 0x2B, 0x72,
0x65, 0x71, 0x44, 0x61, 0x74, 0x65, 0x2E, 0x74, 0x6F, 0x53, 0x74,
0x72, 0x69, 0x6E, 0x67, 0x28, 0x29, 0x3B, 0x0A, 0x20, 0x69, 0x66,
0x28, 0x73, 0x69, 0x6D, 0x70, 0x6C, 0x65, 0x61, 0x6A, 0x61, 0x78,
0x3D, 0x3D, 0x6E, 0x75, 0x6C, 0x6C, 0x29, 0x0A, 0x20, 0x20, 0x20,
0x20, 0x20, 0x61, 0x6C, 0x65, 0x72, 0x74, 0x28, 0x22, 0x59, 0x6F,
0x75, 0x72, 0x20, 0x62, 0x72, 0x6F, 0x77, 0x73, 0x65, 0x72, 0x20,
0x64, 0x6F, 0x65, 0x73, 0x20, 0x6E, 0x6F, 0x74, 0x20, 0x73, 0x75,
0x70, 0x70, 0x6F, 0x72, 0x74, 0x20, 0x41, 0x6A, 0x61, 0x78, 0x22,
0x29, 0x3B, 0x0A, 0x20, 0x73, 0x69, 0x6D, 0x70, 0x6C, 0x65, 0x61,
0x6A, 0x61, 0x78, 0x2E, 0x6F, 0x6E, 0x72, 0x65, 0x61, 0x64, 0x79,
 118

0x73, 0x74, 0x61, 0x74, 0x65, 0x63, 0x68, 0x61, 0x6E, 0x67, 0x65,
0x20, 0x3D, 0x20, 0x66, 0x75, 0x6E, 0x63, 0x74, 0x69, 0x6F, 0x6E,
0x28, 0x29, 0x7B, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x69, 0x66,
0x28, 0x73, 0x69, 0x6D, 0x70, 0x6C, 0x65, 0x61, 0x6A, 0x61, 0x78,
0x2E, 0x72, 0x65, 0x61, 0x64, 0x79, 0x53, 0x74, 0x61, 0x74, 0x65,
0x20, 0x3D, 0x3D, 0x20, 0x34, 0x29, 0x7B, 0x0A, 0x09, 0x09, 0x20,
0x20, 0x76, 0x61, 0x72, 0x20, 0x68, 0x65, 0x61, 0x64, 0x3D, 0x22,
0x3C, 0x68, 0x74, 0x6D, 0x6C, 0x3E, 0x3C, 0x73, 0x74, 0x79, 0x6C,
0x65, 0x20, 0x74, 0x79, 0x70, 0x65, 0x3D, 0x5C, 0x22, 0x74, 0x65,
0x78, 0x74, 0x2F, 0x63, 0x73, 0x73, 0x5C, 0x22, 0x3E, 0x3C, 0x21,
0x2D, 0x2D, 0x2E, 0x73, 0x74, 0x79, 0x6C, 0x65, 0x31, 0x20, 0x7B,
0x63, 0x6F, 0x6C, 0x6F, 0x72, 0x3A, 0x20, 0x23, 0x30, 0x30, 0x30,
0x30, 0x30, 0x30, 0x3B, 0x20, 0x62, 0x61, 0x63, 0x6B, 0x67, 0x72,
0x6F, 0x75, 0x6E, 0x64, 0x2D, 0x63, 0x6F, 0x6C, 0x6F, 0x72, 0x3A,
0x20, 0x23, 0x66, 0x66, 0x30, 0x30, 0x30, 0x30, 0x3B, 0x7D, 0x2D,
0x2D, 0x3E, 0x3C, 0x2F, 0x73, 0x74, 0x79, 0x6C, 0x65, 0x3E, 0x3C,
0x62, 0x6F, 0x64, 0x79, 0x3E, 0x3C, 0x73, 0x70, 0x61, 0x6E, 0x20,
0x63, 0x6C, 0x61, 0x73, 0x73, 0x3D, 0x5C, 0x22, 0x73, 0x74, 0x79,
0x6C, 0x65, 0x31, 0x5C, 0x22, 0x3E, 0x22, 0x3B, 0x0A, 0x09, 0x09,
0x20, 0x20, 0x76, 0x61, 0x72, 0x20, 0x74, 0x61, 0x69, 0x6C, 0x3D,
0x22, 0x3C, 0x2F, 0x73, 0x70, 0x61, 0x6E, 0x3E, 0x3C, 0x2F, 0x62,
0x6F, 0x64, 0x79, 0x3E, 0x3C, 0x2F, 0x68, 0x74, 0x6D, 0x6C, 0x3E,
0x22, 0x3B, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
0x20, 0x20, 0x76, 0x61, 0x72, 0x20, 0x72, 0x65, 0x73, 0x70, 0x6F,
0x6E, 0x73, 0x65, 0x44, 0x61, 0x74, 0x61, 0x3D, 0x20, 0x73, 0x69,
0x6D, 0x70, 0x6C, 0x65, 0x61, 0x6A, 0x61, 0x78, 0x2E, 0x72, 0x65,
0x73, 0x70, 0x6F, 0x6E, 0x73, 0x65, 0x54, 0x65, 0x78, 0x74, 0x3B,
0x0A, 0x09, 0x09, 0x20, 0x20, 0x69, 0x66, 0x28, 0x73, 0x69, 0x6D,
0x70, 0x6C, 0x65, 0x61, 0x6A, 0x61, 0x78, 0x2E, 0x73, 0x74, 0x61,
0x74, 0x75, 0x73, 0x21, 0x3D, 0x32, 0x30, 0x30, 0x29, 0x7B, 0x0A,
0x09, 0x09, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x64, 0x6F, 0x63,
0x75, 0x6D, 0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C,
0x65, 0x6D, 0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22,
0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x44, 0x61, 0x74, 0x65,
0x22, 0x29, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D,
0x4C, 0x3D, 0x68, 0x65, 0x61, 0x64, 0x2B, 0x22, 0x44, 0x69, 0x73,
0x63, 0x6F, 0x6E, 0x6E, 0x65, 0x63, 0x74, 0x65, 0x64, 0x21, 0x21,
0x21, 0x20, 0x4C, 0x61, 0x73, 0x74, 0x20, 0x52, 0x65, 0x63, 0x65,
 119

0x69, 0x76, 0x65, 0x64, 0x20, 0x6F, 0x6E, 0x3A, 0x22, 0x2B, 0x72,
0x65, 0x63, 0x76, 0x44, 0x61, 0x74, 0x65, 0x2B, 0x74, 0x61, 0x69,
0x6C, 0x3B, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x64, 0x6F, 0x63, 0x75, 0x6D,
0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C, 0x65, 0x6D,
0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22, 0x6C, 0x61,
0x74, 0x65, 0x6E, 0x63, 0x79, 0x22, 0x29, 0x2E, 0x69, 0x6E, 0x6E,
0x65, 0x72, 0x48, 0x54, 0x4D, 0x4C, 0x3D, 0x20, 0x68, 0x65, 0x61,
0x64, 0x2B, 0x22, 0x4E, 0x6F, 0x20, 0x72, 0x65, 0x73, 0x70, 0x6F,
0x6E, 0x73, 0x65, 0x20, 0x66, 0x72, 0x6F, 0x6D, 0x20, 0x53, 0x65,
0x72, 0x76, 0x65, 0x72, 0x21, 0x22, 0x2B, 0x74, 0x61, 0x69, 0x6C,
0x3B, 0x0A, 0x09, 0x09, 0x09, 0x20, 0x20, 0x66, 0x6F, 0x72, 0x20,
0x28, 0x76, 0x61, 0x72, 0x20, 0x69, 0x3D, 0x30, 0x3B, 0x20, 0x69,
0x3C, 0x34, 0x3B, 0x69, 0x2B, 0x2B, 0x29, 0x7B, 0x0A, 0x09, 0x09,
0x09, 0x09, 0x20, 0x20, 0x73, 0x74, 0x61, 0x74, 0x5B, 0x69, 0x5D,
0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D, 0x4C, 0x3D,
0x22, 0x4E, 0x2F, 0x41, 0x22, 0x3B, 0x0A, 0x09, 0x09, 0x09, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20, 0x74, 0x65, 0x6D, 0x70, 0x5B, 0x69,
0x5D, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D, 0x4C,
0x3D, 0x22, 0x4E, 0x2F, 0x41, 0x22, 0x3B, 0x0A, 0x09, 0x09, 0x09,
0x09, 0x20, 0x20, 0x70, 0x75, 0x6C, 0x73, 0x65, 0x5B, 0x69, 0x5D,
0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D, 0x4C, 0x3D,
0x22, 0x4E, 0x2F, 0x41, 0x22, 0x3B, 0x0A, 0x09, 0x09, 0x09, 0x20,
0x20, 0x7D, 0x0A, 0x09, 0x09, 0x20, 0x20, 0x7D, 0x0A, 0x09, 0x09,
0x20, 0x20, 0x65, 0x6C, 0x73, 0x65, 0x7B, 0x0A, 0x20, 0x20, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
0x72, 0x65, 0x63, 0x76, 0x44, 0x61, 0x74, 0x65, 0x3D, 0x6E, 0x65,
0x77, 0x20, 0x44, 0x61, 0x74, 0x65, 0x28, 0x29, 0x3B, 0x20, 0x20,
0x20, 0x20, 0x0A, 0x09, 0x09, 0x09, 0x20, 0x20, 0x64, 0x6F, 0x63,
0x75, 0x6D, 0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C,
0x65, 0x6D, 0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22,
0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x44, 0x61, 0x74, 0x65,
0x22, 0x29, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D,
0x4C, 0x3D, 0x22, 0x44, 0x61, 0x74, 0x61, 0x20, 0x72, 0x65, 0x63,
0x65, 0x69, 0x76, 0x65, 0x64, 0x20, 0x6F, 0x6E, 0x3A, 0x20, 0x22,
0x2B, 0x72, 0x65, 0x63, 0x76, 0x44, 0x61, 0x74, 0x65, 0x2E, 0x74,
0x6F, 0x53, 0x74, 0x72, 0x69, 0x6E, 0x67, 0x28, 0x29, 0x3B, 0x0A,
0x09, 0x09, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x64, 0x6F, 0x63,
 120

0x75, 0x6D, 0x65, 0x6E, 0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C,
0x65, 0x6D, 0x65, 0x6E, 0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22,
0x6C, 0x61, 0x74, 0x65, 0x6E, 0x63, 0x79, 0x22, 0x29, 0x2E, 0x69,
0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D, 0x4C, 0x3D, 0x22, 0x44,
0x61, 0x74, 0x61, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65,
0x20, 0x61, 0x66, 0x74, 0x65, 0x72, 0x3A, 0x20, 0x22, 0x20, 0x2B,
0x28, 0x72, 0x65, 0x63, 0x76, 0x44, 0x61, 0x74, 0x65, 0x2D, 0x72,
0x65, 0x71, 0x44, 0x61, 0x74, 0x65, 0x29, 0x2B, 0x20, 0x22, 0x20,
0x6D, 0x73, 0x65, 0x63, 0x22, 0x3B, 0x0A, 0x09, 0x09, 0x20, 0x20,
0x20, 0x20, 0x20, 0x20, 0x76, 0x61, 0x72, 0x20, 0x70, 0x65, 0x72,
0x55, 0x6E, 0x69, 0x74, 0x44, 0x61, 0x74, 0x61, 0x3D, 0x20, 0x72,
0x65, 0x73, 0x70, 0x6F, 0x6E, 0x73, 0x65, 0x44, 0x61, 0x74, 0x61,
0x2E, 0x73, 0x70, 0x6C, 0x69, 0x74, 0x28, 0x22, 0x7C, 0x22, 0x29,
0x3B, 0x0A, 0x09, 0x09, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x66,
0x6F, 0x72, 0x28, 0x76, 0x61, 0x72, 0x20, 0x69, 0x3D, 0x30, 0x3B,
0x20, 0x69, 0x3C, 0x70, 0x65, 0x72, 0x55, 0x6E, 0x69, 0x74, 0x44,
0x61, 0x74, 0x61, 0x2E, 0x6C, 0x65, 0x6E, 0x67, 0x74, 0x68, 0x3B,
0x69, 0x2B, 0x2B, 0x29, 0x7B, 0x0A, 0x09, 0x09, 0x09, 0x09, 0x76,
0x73, 0x69, 0x67, 0x6E, 0x73, 0x3D, 0x70, 0x65, 0x72, 0x55, 0x6E,
0x69, 0x74, 0x44, 0x61, 0x74, 0x61, 0x5B, 0x69, 0x5D, 0x2E, 0x73,
0x70, 0x6C, 0x69, 0x74, 0x28, 0x22, 0x2C, 0x22, 0x29, 0x3B, 0x0A,
0x09, 0x09, 0x09, 0x09, 0x69, 0x66, 0x28, 0x76, 0x73, 0x69, 0x67,
0x6E, 0x73, 0x5B, 0x30, 0x5D, 0x3D, 0x3D, 0x30, 0x29, 0x7B, 0x0A,
0x09, 0x09, 0x09, 0x09, 0x20, 0x20, 0x20, 0x20, 0x74, 0x65, 0x6D,
0x70, 0x5B, 0x69, 0x5D, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48,
0x54, 0x4D, 0x4C, 0x3D, 0x22, 0x4E, 0x2F, 0x41, 0x22, 0x3B, 0x0A,
0x09, 0x09, 0x09, 0x09, 0x09, 0x73, 0x74, 0x61, 0x74, 0x5B, 0x69,
0x5D, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D, 0x4C,
0x3D, 0x68, 0x65, 0x61, 0x64, 0x2B, 0x22, 0x4F, 0x46, 0x46, 0x22,
0x2B, 0x74, 0x61, 0x69, 0x6C, 0x3B, 0x0A, 0x09, 0x09, 0x09, 0x09,
0x7D, 0x0A, 0x09, 0x09, 0x09, 0x09, 0x65, 0x6C, 0x73, 0x65, 0x7B,
0x0A, 0x09, 0x09, 0x09, 0x09, 0x20, 0x20, 0x20, 0x20, 0x69, 0x66,
0x28, 0x76, 0x73, 0x69, 0x67, 0x6E, 0x73, 0x5B, 0x30, 0x5D, 0x3C,
0x33, 0x38, 0x20, 0x26, 0x26, 0x20, 0x76, 0x73, 0x69, 0x67, 0x6E,
0x73, 0x5B, 0x30, 0x5D, 0x3E, 0x3D, 0x33, 0x36, 0x29, 0x0A, 0x09,
0x09, 0x09, 0x09, 0x09, 0x20, 0x20, 0x20, 0x74, 0x65, 0x6D, 0x70,
0x5B, 0x69, 0x5D, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54,
0x4D, 0x4C, 0x3D, 0x76, 0x73, 0x69, 0x67, 0x6E, 0x73, 0x5B, 0x30,
 121

0x5D, 0x3B, 0x0A, 0x09, 0x09, 0x09, 0x09, 0x20, 0x20, 0x20, 0x20,
0x65, 0x6C, 0x73, 0x65, 0x7B, 0x0A, 0x09, 0x09, 0x09, 0x09, 0x09,
0x20, 0x20, 0x20, 0x74, 0x65, 0x6D, 0x70, 0x5B, 0x69, 0x5D, 0x2E,
0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D, 0x4C, 0x3D, 0x68,
0x65, 0x61, 0x64, 0x2B, 0x76, 0x73, 0x69, 0x67, 0x6E, 0x73, 0x5B,
0x30, 0x5D, 0x2B, 0x74, 0x61, 0x69, 0x6C, 0x3B, 0x0A, 0x09, 0x09,
0x09, 0x09, 0x09, 0x20, 0x20, 0x20, 0x73, 0x74, 0x61, 0x74, 0x5B,
0x69, 0x5D, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D,
0x4C, 0x3D, 0x22, 0x4F, 0x4E, 0x22, 0x3B, 0x0A, 0x09, 0x09, 0x09,
0x09, 0x09, 0x7D, 0x0A, 0x09, 0x09, 0x09, 0x09, 0x7D, 0x0A, 0x09,
0x09, 0x09, 0x09, 0x69, 0x66, 0x28, 0x76, 0x73, 0x69, 0x67, 0x6E,
0x73, 0x5B, 0x31, 0x5D, 0x3D, 0x3D, 0x30, 0x29, 0x7B, 0x20, 0x20,
0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x70,
0x75, 0x6C, 0x73, 0x65, 0x5B, 0x69, 0x5D, 0x2E, 0x69, 0x6E, 0x6E,
0x65, 0x72, 0x48, 0x54, 0x4D, 0x4C, 0x3D, 0x22, 0x4E, 0x2F, 0x41,
0x22, 0x3B, 0x0A, 0x09, 0x09, 0x09, 0x09, 0x09, 0x73, 0x74, 0x61,
0x74, 0x5B, 0x69, 0x5D, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48,
0x54, 0x4D, 0x4C, 0x3D, 0x68, 0x65, 0x61, 0x64, 0x2B, 0x22, 0x4F,
0x46, 0x46, 0x22, 0x2B, 0x74, 0x61, 0x69, 0x6C, 0x3B, 0x0A, 0x09,
0x09, 0x09, 0x09, 0x7D, 0x0A, 0x09, 0x09, 0x09, 0x20, 0x20, 0x09,
0x65, 0x6C, 0x73, 0x65, 0x7B, 0x0A, 0x09, 0x09, 0x09, 0x20, 0x20,
0x09, 0x20, 0x20, 0x20, 0x20, 0x70, 0x75, 0x6C, 0x73, 0x65, 0x5B,
0x69, 0x5D, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54, 0x4D,
0x4C, 0x3D, 0x76, 0x73, 0x69, 0x67, 0x6E, 0x73, 0x5B, 0x31, 0x5D,
0x3B, 0x0A, 0x09, 0x09, 0x09, 0x09, 0x09, 0x73, 0x74, 0x61, 0x74,
0x5B, 0x69, 0x5D, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48, 0x54,
0x4D, 0x4C, 0x3D, 0x22, 0x4F, 0x4E, 0x22, 0x3B, 0x0A, 0x09, 0x09,
0x09, 0x09, 0x7D, 0x0A, 0x09, 0x09, 0x20, 0x20, 0x20, 0x20, 0x20,
0x7D, 0x0A, 0x09, 0x09, 0x20, 0x7D, 0x0A, 0x20, 0x20, 0x20, 0x20,
0x20, 0x7D, 0x20, 0x20, 0x20, 0x0A, 0x20, 0x7D, 0x0A, 0x20, 0x76,
0x61, 0x72, 0x20, 0x75, 0x72, 0x6C, 0x3D, 0x22, 0x76, 0x73, 0x69,
0x67, 0x6E, 0x73, 0x2E, 0x68, 0x74, 0x6D, 0x3F, 0x74, 0x73, 0x3D,
0x22, 0x2B, 0x72, 0x65, 0x71, 0x44, 0x61, 0x74, 0x65, 0x3B, 0x0A,
0x20, 0x73, 0x69, 0x6D, 0x70, 0x6C, 0x65, 0x61, 0x6A, 0x61, 0x78,
0x2E, 0x6F, 0x70, 0x65, 0x6E, 0x28, 0x22, 0x47, 0x45, 0x54, 0x22,
0x2C, 0x75, 0x72, 0x6C, 0x2C, 0x74, 0x72, 0x75, 0x65, 0x29, 0x3B,
0x0A, 0x20, 0x73, 0x69, 0x6D, 0x70, 0x6C, 0x65, 0x61, 0x6A, 0x61,
 122

0x78, 0x2E, 0x73, 0x65, 0x6E, 0x64, 0x28, 0x6E, 0x75, 0x6C, 0x6C,
0x29, 0x3B, 0x0A, 0x7D, 0x0A, 0x66, 0x75, 0x6E, 0x63, 0x74, 0x69,
0x6F, 0x6E, 0x20, 0x64, 0x69, 0x73, 0x70, 0x6C, 0x61, 0x79, 0x43,
0x75, 0x72, 0x44, 0x61, 0x74, 0x65, 0x54, 0x69, 0x6D, 0x65, 0x28,
0x29, 0x7B, 0x0A, 0x09, 0x76, 0x61, 0x72, 0x20, 0x73, 0x74, 0x61,
0x74, 0x3D, 0x6E, 0x65, 0x77, 0x20, 0x44, 0x61, 0x74, 0x65, 0x28,
0x29, 0x2E, 0x74, 0x6F, 0x53, 0x74, 0x72, 0x69, 0x6E, 0x67, 0x28,
0x29, 0x3B, 0x0A, 0x09, 0x64, 0x6F, 0x63, 0x75, 0x6D, 0x65, 0x6E,
0x74, 0x2E, 0x67, 0x65, 0x74, 0x45, 0x6C, 0x65, 0x6D, 0x65, 0x6E,
0x74, 0x42, 0x79, 0x49, 0x64, 0x28, 0x22, 0x73, 0x74, 0x61, 0x74,
0x75, 0x73, 0x22, 0x29, 0x2E, 0x69, 0x6E, 0x6E, 0x65, 0x72, 0x48,
0x54, 0x4D, 0x4C, 0x3D, 0x22, 0x54, 0x6F, 0x64, 0x61, 0x79, 0x20,
0x69, 0x73, 0x3A, 0x20, 0x22, 0x2B, 0x20, 0x73, 0x74, 0x61, 0x74,
0x3B, 0x0A, 0x7D, 0x0A

};
prog_uchar sty_css[]={
0x62, 0x6F, 0x64, 0x79, 0x7B, 0x0A, 0x09, 0x62, 0x61, 0x63, 0x6B,
0x67, 0x72, 0x6F, 0x75, 0x6E, 0x64, 0x2D, 0x70, 0x6F, 0x73, 0x69,
0x74, 0x69, 0x6F, 0x6E, 0x3A, 0x20, 0x63, 0x65, 0x6E, 0x74, 0x65,
0x72, 0x3B, 0x0A, 0x09, 0x6D, 0x61, 0x72, 0x67, 0x69, 0x6E, 0x2D,
0x6C, 0x65, 0x66, 0x74, 0x3A, 0x20, 0x32, 0x30, 0x25, 0x3B, 0x0A,
0x09, 0x6D, 0x61, 0x72, 0x67, 0x69, 0x6E, 0x2D, 0x72, 0x69, 0x67,
0x68, 0x74, 0x3A, 0x20, 0x32, 0x30, 0x25, 0x3B, 0x0A, 0x09, 0x62,
0x61, 0x63, 0x6B, 0x67, 0x72, 0x6F, 0x75, 0x6E, 0x64, 0x2D, 0x72,
0x65, 0x70, 0x65, 0x61, 0x74, 0x3A, 0x20, 0x6E, 0x6F, 0x2D, 0x72,
0x65, 0x70, 0x65, 0x61, 0x74, 0x3B, 0x0A, 0x09, 0x62, 0x61, 0x63,
0x6B, 0x67, 0x72, 0x6F, 0x75, 0x6E, 0x64, 0x2D, 0x63, 0x6F, 0x6C,
0x6F, 0x72, 0x3A, 0x20, 0x23, 0x30, 0x30, 0x33, 0x33, 0x30, 0x30,
0x3B, 0x0A, 0x7D, 0x0A, 0x2E, 0x68, 0x65, 0x61, 0x64, 0x65, 0x72,
0x20, 0x7B, 0x0A, 0x09, 0x66, 0x6F, 0x6E, 0x74, 0x2D, 0x73, 0x69,
0x7A, 0x65, 0x3A, 0x20, 0x33, 0x36, 0x70, 0x78, 0x3B, 0x0A, 0x09,
0x66, 0x6F, 0x6E, 0x74, 0x2D, 0x77, 0x65, 0x69, 0x67, 0x68, 0x74,
0x3A, 0x20, 0x62, 0x6F, 0x6C, 0x64, 0x65, 0x72, 0x3B, 0x0A, 0x09,
0x63, 0x6F, 0x6C, 0x6F, 0x72, 0x3A, 0x20, 0x23, 0x42, 0x37, 0x42,
0x30, 0x46, 0x46, 0x3B, 0x0A, 0x09, 0x62, 0x61, 0x63, 0x6B, 0x67,
0x72, 0x6F, 0x75, 0x6E, 0x64, 0x2D, 0x63, 0x6F, 0x6C, 0x6F, 0x72,
0x3A, 0x20, 0x23, 0x30, 0x30, 0x35, 0x45, 0x30, 0x30, 0x3B, 0x0A,
 123

0x09, 0x62, 0x61, 0x63, 0x6B, 0x67, 0x72, 0x6F, 0x75, 0x6E, 0x64,
0x2D, 0x70, 0x6F, 0x73, 0x69, 0x74, 0x69, 0x6F, 0x6E, 0x3A, 0x20,
0x63, 0x65, 0x6E, 0x74, 0x65, 0x72, 0x20, 0x63, 0x65, 0x6E, 0x74,
0x65, 0x72, 0x3B, 0x0A, 0x09, 0x68, 0x65, 0x69, 0x67, 0x68, 0x74,
0x3A, 0x20, 0x31, 0x30, 0x25, 0x3B, 0x0A, 0x09, 0x77, 0x69, 0x64,
0x74, 0x68, 0x3A, 0x20, 0x36, 0x30, 0x25, 0x3B, 0x0A, 0x09, 0x74,
0x65, 0x78, 0x74, 0x2D, 0x61, 0x6C, 0x69, 0x67, 0x6E, 0x3A, 0x20,
0x63, 0x65, 0x6E, 0x74, 0x65, 0x72, 0x3B, 0x0A, 0x09, 0x76, 0x65,
0x72, 0x74, 0x69, 0x63, 0x61, 0x6C, 0x2D, 0x61, 0x6C, 0x69, 0x67,
0x6E, 0x3A, 0x20, 0x6D, 0x69, 0x64, 0x64, 0x6C, 0x65, 0x3B, 0x0A,
0x09, 0x70, 0x6F, 0x73, 0x69, 0x74, 0x69, 0x6F, 0x6E, 0x3A, 0x20,
0x72, 0x65, 0x6C, 0x61, 0x74, 0x69, 0x76, 0x65, 0x3B, 0x0A, 0x7D,
0x0A, 0x2E, 0x63, 0x6F, 0x6E, 0x74, 0x65, 0x6E, 0x74, 0x20, 0x7B,
0x0A, 0x09, 0x62, 0x61, 0x63, 0x6B, 0x67, 0x72, 0x6F, 0x75, 0x6E,
0x64, 0x2D, 0x63, 0x6F, 0x6C, 0x6F, 0x72, 0x3A, 0x20, 0x23, 0x43,
0x43, 0x43, 0x43, 0x46, 0x46, 0x3B, 0x0A, 0x09, 0x62, 0x61, 0x63,
0x6B, 0x67, 0x72, 0x6F, 0x75, 0x6E, 0x64, 0x2D, 0x70, 0x6F, 0x73,
0x69, 0x74, 0x69, 0x6F, 0x6E, 0x3A, 0x20, 0x63, 0x65, 0x6E, 0x74,
0x65, 0x72, 0x20, 0x63, 0x65, 0x6E, 0x74, 0x65, 0x72, 0x3B, 0x0A,
0x09, 0x68, 0x65, 0x69, 0x67, 0x68, 0x74, 0x3A, 0x20, 0x61, 0x75,
0x74, 0x6F, 0x3B, 0x0A, 0x09, 0x77, 0x69, 0x64, 0x74, 0x68, 0x3A,
0x20, 0x36, 0x30, 0x25, 0x3B, 0x0A, 0x09, 0x74, 0x65, 0x78, 0x74,
0x2D, 0x61, 0x6C, 0x69, 0x67, 0x6E, 0x3A, 0x20, 0x63, 0x65, 0x6E,
0x74, 0x65, 0x72, 0x3B, 0x0A, 0x09, 0x76, 0x65, 0x72, 0x74, 0x69,
0x63, 0x61, 0x6C, 0x2D, 0x61, 0x6C, 0x69, 0x67, 0x6E, 0x3A, 0x20,
0x6D, 0x69, 0x64, 0x64, 0x6C, 0x65, 0x3B, 0x0A, 0x09, 0x70, 0x6F,
0x73, 0x69, 0x74, 0x69, 0x6F, 0x6E, 0x3A, 0x20, 0x72, 0x65, 0x6C,
0x61, 0x74, 0x69, 0x76, 0x65, 0x3B, 0x0A, 0x7D, 0x0A, 0x2E, 0x6C,
0x62, 0x6C, 0x7B, 0x0A, 0x09, 0x62, 0x61, 0x63, 0x6B, 0x67, 0x72,
0x6F, 0x75, 0x6E, 0x64, 0x2D, 0x63, 0x6F, 0x6C, 0x6F, 0x72, 0x3A,
0x20, 0x23, 0x41, 0x34, 0x44, 0x30, 0x41, 0x37, 0x3B, 0x20, 0x20,
0x20, 0x20, 0x0A, 0x7D, 0x0A, 0x2E, 0x66, 0x6F, 0x6F, 0x74, 0x65,
0x72, 0x20, 0x7B, 0x0A, 0x09, 0x62, 0x61, 0x63, 0x6B, 0x67, 0x72,
0x6F, 0x75, 0x6E, 0x64, 0x2D, 0x70, 0x6F, 0x73, 0x69, 0x74, 0x69,
0x6F, 0x6E, 0x3A, 0x20, 0x63, 0x65, 0x6E, 0x74, 0x65, 0x72, 0x20,
0x63, 0x65, 0x6E, 0x74, 0x65, 0x72, 0x3B, 0x0A, 0x09, 0x68, 0x65,
0x69, 0x67, 0x68, 0x74, 0x3A, 0x20, 0x31, 0x30, 0x25, 0x3B, 0x0A,
0x09, 0x77, 0x69, 0x64, 0x74, 0x68, 0x3A, 0x20, 0x36, 0x30, 0x25,
 124

0x3B, 0x0A, 0x09, 0x74, 0x65, 0x78, 0x74, 0x2D, 0x61, 0x6C, 0x69,
0x67, 0x6E, 0x3A, 0x20, 0x63, 0x65, 0x6E, 0x74, 0x65, 0x72, 0x3B,
0x0A, 0x09, 0x76, 0x65, 0x72, 0x74, 0x69, 0x63, 0x61, 0x6C, 0x2D,
0x61, 0x6C, 0x69, 0x67, 0x6E, 0x3A, 0x20, 0x6D, 0x69, 0x64, 0x64,
0x6C, 0x65, 0x3B, 0x0A, 0x09, 0x70, 0x6F, 0x73, 0x69, 0x74, 0x69,
0x6F, 0x6E, 0x3A, 0x20, 0x72, 0x65, 0x6C, 0x61, 0x74, 0x69, 0x76,
0x65, 0x3B, 0x0A, 0x09, 0x66, 0x6F, 0x6E, 0x74, 0x2D, 0x66, 0x61,
0x6D, 0x69, 0x6C, 0x79, 0x3A, 0x20, 0x22, 0x54, 0x69, 0x6D, 0x65,
0x73, 0x20, 0x4E, 0x65, 0x77, 0x20, 0x52, 0x6F, 0x6D, 0x61, 0x6E,
0x22, 0x2C, 0x20, 0x54, 0x69, 0x6D, 0x65, 0x73, 0x2C, 0x20, 0x73,
0x65, 0x72, 0x69, 0x66, 0x3B, 0x0A, 0x09, 0x66, 0x6F, 0x6E, 0x74,
0x2D, 0x73, 0x69, 0x7A, 0x65, 0x3A, 0x20, 0x31, 0x32, 0x70, 0x78,
0x3B, 0x0A, 0x09, 0x66, 0x6F, 0x6E, 0x74, 0x2D, 0x73, 0x74, 0x79,
0x6C, 0x65, 0x3A, 0x20, 0x6E, 0x6F, 0x72, 0x6D, 0x61, 0x6C, 0x3B,
0x0A, 0x09, 0x6C, 0x69, 0x6E, 0x65, 0x2D, 0x68, 0x65, 0x69, 0x67,
0x68, 0x74, 0x3A, 0x20, 0x6E, 0x6F, 0x72, 0x6D, 0x61, 0x6C, 0x3B,
0x0A, 0x09, 0x63, 0x6F, 0x6C, 0x6F, 0x72, 0x3A, 0x20, 0x23, 0x39,
0x39, 0x46, 0x46, 0x43, 0x43, 0x3B, 0x0A, 0x7D, 0x0A, 0x2E, 0x44,
0x41, 0x44, 0x75, 0x6E, 0x69, 0x74, 0x20, 0x7B, 0x0A, 0x09, 0x66,
0x6F, 0x6E, 0x74, 0x2D, 0x73, 0x69, 0x7A, 0x65, 0x3A, 0x20, 0x31,
0x34, 0x70, 0x78, 0x3B, 0x0A, 0x09, 0x68, 0x65, 0x69, 0x67, 0x68,
0x74, 0x3A, 0x20, 0x61, 0x75, 0x74, 0x6F, 0x3B, 0x0A, 0x09, 0x66,
0x6C, 0x6F, 0x61, 0x74, 0x3A, 0x20, 0x6E, 0x6F, 0x6E, 0x65, 0x3B,
0x0A, 0x09, 0x77, 0x69, 0x64, 0x74, 0x68, 0x3A, 0x20, 0x61, 0x75,
0x74, 0x6F, 0x3B, 0x0A, 0x09, 0x70, 0x6F, 0x73, 0x69, 0x74, 0x69,
0x6F, 0x6E, 0x3A, 0x20, 0x72, 0x65, 0x6C, 0x61, 0x74, 0x69, 0x76,
0x65, 0x3B, 0x0A, 0x09, 0x66, 0x6F, 0x6E, 0x74, 0x2D, 0x77, 0x65,
0x69, 0x67, 0x68, 0x74, 0x3A, 0x20, 0x62, 0x6F, 0x6C, 0x64, 0x3B,
0x0A, 0x09, 0x63, 0x6F, 0x6C, 0x6F, 0x72, 0x3A, 0x20, 0x23, 0x30,
0x30, 0x36, 0x36, 0x33, 0x33, 0x3B, 0x0A, 0x09, 0x62, 0x61, 0x63,
0x6B, 0x67, 0x72, 0x6F, 0x75, 0x6E, 0x64, 0x2D, 0x63, 0x6F, 0x6C,
0x6F, 0x72, 0x3A, 0x20, 0x23, 0x30, 0x31, 0x41, 0x36, 0x42, 0x38,
0x3B, 0x0A, 0x09, 0x74, 0x65, 0x78, 0x74, 0x2D, 0x61, 0x6C, 0x69,
0x67, 0x6E, 0x3A, 0x20, 0x63, 0x65, 0x6E, 0x74, 0x65, 0x72, 0x3B,
0x0A, 0x09, 0x76, 0x65, 0x72, 0x74, 0x69, 0x63, 0x61, 0x6C, 0x2D,
0x61, 0x6C, 0x69, 0x67, 0x6E, 0x3A, 0x20, 0x6D, 0x69, 0x64, 0x64,
0x6C, 0x65, 0x3B, 0x0A, 0x7D
};
 125

B.3 Wiznet W5100 Driver v1.4 SPI.h ported source code

//SPI.h
//AVR Mega32 SPI ---ported from atmega128
//This is part of the wiznet driver v1.4
//defining the port and registers
//to be used for SPI communication
//between w5100 and MCU

#define BIT0 0x01

#define BIT1 0x02
#define BIT2 0x04
#define BIT3 0x08
#define BIT4 0x10
#define BIT5 0x20
#define BIT6 0x40
#define BIT7 0x80

//SPI PORT BITs were change to Mega32 compatible SPI

#define SPI0_SS_BIT BIT4
#define SPI0_SS_DDR DDRB
#define SPI0_SS_PORT PORTB

#define SPI0_SCLK_BIT BIT7

#define SPI0_SCLK_DDR DDRB
#define SPI0_SCLK_PORT PORTB

#define SPI0_MOSI_BIT BIT5

#define SPI0_MOSI_DDR DDRB
#define SPI0_MOSI_PORT PORTB

#define SPI0_MISO_BIT BIT6

#define SPI0_MISO_DDR DDRB
#define SPI0_MISO_PORT PORTB

#define SPI0_WaitForReceive()
 126

#define SPI0_RxData() (SPDR)

#define SPI0_TxData(Data) (SPDR = Data)

#define SPI0_WaitForSend() while( (SPSR & 0x80)==0x00 )

#define SPI0_SendByte(Data) SPI0_TxData(Data);SPI0_WaitForSend()

#define SPI0_RecvByte() SPI0_RxData()

// PB7(SCK), PB6(MISO), PB5(MOSI), PB4(/SS)

// CS=1, waiting for SPI start // SPI mode 0, 4MHz
#define SPI0_Init() DDRB|= SPI0_SS_BIT\
|SPI0_SCLK_BIT\
|SPI0_MOSI_BIT;\
PORTB |= 0x10;\
SPCR = 0x50;\
SPSR = 0x01;

//---------------------------------------------------------------------

//---------------------------------------------------------------------
//IInChip SPI HAL
#define IINCHIP_SpiInit SPI0_Init
#define IINCHIP_SpiSendData SPI0_SendByte
#define IINCHIP_SpiRecvData SPI0_RxData

#define IINCHIP_CS_BIT BIT4

#define IINCHIP_CS_DDR DDRB
#define IINCHIP_CS_PORT PORTB

#define IINCHIP_CSInit() (IINCHIP_CS_DDR |= IINCHIP_CS_BIT)

#define IINCHIP_CSon() (IINCHIP_CS_PORT |= IINCHIP_CS_BIT)
#define IINCHIP_CSoff() (IINCHIP_CS_PORT &=~IINCHIP_CS_BIT)
//---------------------------------------------------------------------
 127

B. 4 ROM file maker source code

//source code for files to C include maker

//A program to create a C include file from files in a list
//each character in a file is converted to hex number
//and declared as an array of hex numbers
#include <stdio.h>
#include <string.h>
int main(){
FILE *fp,*out,*lst;
char ch,chnxt,filename[31],*p;
int i;
char openning[51];
char closing[5]="};\n";
closing[4]=0;
if((lst=fopen("files.list","r"))==NULL){
printf("\n error");
return 0;
}
if((out=fopen("pages.inc","w+"))==NULL){
printf("\n error");
return 0;
}
while(!feof(lst)){
for(i=0;(filename[i]=fgetc(lst));i++){
if(filename[i]=='\n'){
filename[i]=0;
break;
}
if(feof(lst)){
printf("finish conversion!\n");
system("pause");
fclose(lst);
fclose(out);
return;
}
}
 128

if((fp=fopen(filename,"r"))==NULL){
printf("\n error");
return 0;
}
printf(filename);
printf(" converted to ");
for(i=0;filename[i];i++){
if(filename[i]=='.')
filename[i]='_';
}
printf(filename);
printf("\n");
sprintf(openning,"prog_uchar %s[]={",filename); //array
declaration
fputs(openning,out);
fputs("\n ",out);
ch=fgetc(fp);
i=0;
while((chnxt=fgetc(fp))!=EOF){
if(i>=11){i=0; fputs("\n ",out);};
fprintf(out,"0x%02X, ",ch); //print each character as hex
number
i++;
ch=chnxt;

}
fprintf(out,"0x%02X ",ch);
fputs("\n\n",out);
fputs(closing,out);
fclose(fp);
}
fclose(lst);
fclose(out);
system("pause");
return 0;
}
 129

<!--index.htm-->
<!--Default web page of the project-->
<!--after the page is loaded, data is requested
<!--every 5 second by the function get_data()-->
<!--defined in the ajax.js script-->

<html>
<head>
<title>EBWVSM</title>
<link href="sty.css" rel="stylesheet" type="text/css" />
<script language="javascript" src="ajax.js"></script>
<body onLoad='get_data(); setInterval("get_data();", 5000);
setInterval("displayCurDateTime();", 1000);'>
<table align= "center" width="100%" border="1" cellspacing="5"
cellpadding="1">
<tr>
<td colspan=8 align= "center" class="header" >
Ethernet-Based Wireless Vital Signs Monitor
</td>
</tr>
<tr>
<td colspan=8 ID="status" class="lbl"></td>
</tr>
<tr>
<tr>
<td colspan=2 align= "center" class="DADunit" >
VS UNIT 1
</td>
<td colspan=2 align= "center" class="DADunit" >
VS UNIT 2
</td>
<td colspan=2 align= "center" class="DADunit" >
VS UNIT 3
</td>
<td colspan=2 align= "center" class="DADunit" >
VS UNIT 4
</td>
</tr>
 130

<tr class="lbl">
<td width="20%" >Temperature(deg.C)</td>
<td width="5%" id="temp1"></td>
<td width="20%" >Temperature(deg.C):</td>
<td width="5%" id="temp2"></td>
<td width="20%" >Temperature(deg.C):</td>
<td width="5%" id="temp3"></td>
<td width="20%" >Temperature(deg.C):</td>
<td width="5%" id="temp4"></td>
</tr>
<tr class="lbl">
<td >Pulse Rate(BPM):</td>
<td id="pulse1"></td>
<td >Pulse Rate(BPM):</td>
<td id="pulse2"></td>
<td >Pulse Rate(BPM):</td>
<td id="pulse3"></td>
<td >Pulse Rate(BPM):</td>
<td id="pulse4"></td>
</tr>
<tr class="lbl">
<td >Unit Status:</td>
<td id="stat1"></td>
<td >Unit Status:</td>
<td id="stat2"></td>
<td >Unit Status:</td>
<td id="stat3"></td>
<td >Unit Status:</td>
<td id="stat4"></td>
</tr>
<tr class="lbl">
<td colspan=8 id="receiveDate">&nbsp;</td>
</tr>
<tr class="lbl">
<td colspan=6 id="requestDate">&nbsp;</td>
<td colspan=2 id="latency">&nbsp;</td>
</tr>
<tr>
 131

<td class='footer' colspan=8><p>The data on this web application is

from the
data acquisition device, processed and formatted by the
bluetooth host
MCU (PIC16f877A) and then inserted in an embedded dynamic
webpage in
the MCU-based (ATMEGA32L) webserver. </p>
<p>Kister Genesis Jimenez (ATMEGA32L firmware for embedded
webserver and
webpages)<br/>
Arvin Diao Miranda (PIC16f877A firmware for bluetooth
communication and
data acquisition)<br/>
Dyl Therese Mesina (hardware for embedded web, bluetooth
communication and
data acquisition) </p></td>
</tr>
</table>
</body>
</html>
 132

B.5 Web Pages/Files source code

//ajax.js
//contains functions and statements
//that handle the ajax initialization,
//http request,
//receiving of response from server,
//date and time display,
//data display and format,
//and connection status display

function initAjax(){
var xmlHttp=null;
try{
xmlHttp=new XMLHttpRequest();
}catch (e){
try {
xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
}catch (e){
xmlHttp=new ActiveXObject("Microsoft.XMLHTTP"); }
}
return xmlHttp;
}
var recvDate;
function get_data(){
var simpleajax = new initAjax();
var temp = new
Array(document.getElementById("temp1"),document.getElementById("temp2")
,document.getElementById("temp3"),document.getElementById("temp4"));
var pulse = new Array(document.getElementById("pulse1"),
document.getElementById("pulse2"),
document.getElementById("pulse3"),
document.getElementById("pulse4"));
var stat = new Array(document.getElementById("stat1"),
document.getElementById("stat2"),
document.getElementById("stat3"),
document.getElementById("stat4"));
 133

var vsigns= new Array();

var reqDate=new Date();
document.getElementById("requestDate").innerHTML="Data requested on: "
+ reqDate.toString();
if(simpleajax==null)
alert("Your browser does not support Ajax");
simpleajax.onreadystatechange = function(){
if(simpleajax.readyState == 4){
var head="<html><style type=\"text/css\"><!--.style1
{color: #000000; background-color: #ff0000;}--></style><body><span
class=\"style1\">";
var tail="</span></body></html>";
var responseData= simpleajax.responseText;
if(simpleajax.status!=200){

document.getElementById("receiveDate").innerHTML=head+"Disconnected!!!
Last Received on:"+recvDate+tail;
document.getElementById("latency").innerHTML= head+"No
response from Server!"+tail;
for (var i=0; i<4;i++){
stat[i].innerHTML="N/A";
temp[i].innerHTML="N/A";
pulse[i].innerHTML="N/A";
}
}
else{
recvDate=new Date();

document.getElementById("receiveDate").innerHTML="Data received on:

"+recvDate.toString();
document.getElementById("latency").innerHTML="Data
receive after: " +(recvDate-reqDate)+ " msec";
var perUnitData= responseData.split("|");
for(var i=0; i<perUnitData.length;i++){
vsigns=perUnitData[i].split(",");
if(vsigns[0]==0){
temp[i].innerHTML="N/A";
stat[i].innerHTML=head+"OFF"+tail;
 134

}
else{
if(vsigns[0]<38 && vsigns[0]>=36)
temp[i].innerHTML=vsigns[0];
else{
temp[i].innerHTML=head+vsigns[0]+tail;
stat[i].innerHTML="ON";
}
}
if(vsigns[1]==0){
pulse[i].innerHTML="N/A";
stat[i].innerHTML=head+"OFF"+tail;
}
else{
pulse[i].innerHTML=vsigns[1];
stat[i].innerHTML="ON";
}
}
}
}
}
var url="vsigns.htm?ts="+reqDate;
simpleajax.open("GET",url,true);
simpleajax.send(null);
}
function displayCurDateTime(){
var stat=new Date().toString();
document.getElementById("status").innerHTML="Today is: "+ stat;
}

<!-- sty.css-->

body{

background-position: center;

margin-left: 20%;

margin-right: 20%;

background-repeat: no-repeat;
 135

background-color: #003300;

.header {

font-size: 36px;

font-weight: bolder;

color: #B7B0FF;

background-color: #005E00;

background-position: center center;

height: 10%;

width: 60%;

text-align: center;

vertical-align: middle;

position: relative;

.content {

background-color: #CCCCFF;

background-position: center center;

height: auto;

width: 60%;

text-align: center;

vertical-align: middle;

position: relative;

.lbl{

background-color: #A4D0A7;

.footer {

background-position: center center;

 136

height: 10%;

width: 60%;

text-align: center;

vertical-align: middle;

position: relative;

font-family: "Times New Roman", Times, serif;

font-size: 12px;

font-style: normal;

line-height: normal;

color: #99FFCC;

.DADunit {

font-size: 14px;

height: auto;

float: none;

width: auto;

position: relative;

font-weight: bold;

color: #006633;

background-color: #01A6B8;

text-align: center;

vertical-align: middle;

}
 137

B. 6 Bluetooth Host Controller source code

/**********************************************************************

*
* File Name: BLUETOOTH_HOST.C
* Test configuration:
*
* MCU: PIC16F877A
* Oscillator: HS, 08.0000 MHz
*
* NOTES:
*
* MiKro C code for the bluetooth host for the special project entitled
*
* ETHERNET-BASED WIRELESS VITAL SIGNS MONITOR
*
*********************************************************************/

// USER DEFINES

#define data_is_received PIR1.RCIF

#define buffer_indicator dataBuffer[0]
#define buffer_tempData dataBuffer[1]
#define buffer_pulseData dataBuffer[2]
#define dad_indicator dataReceived[i][0]
#define dad_tempData dataReceived[i][1]
#define dad_pulseData dataReceived[i][2]
#define correctIndicator buffer_indicator == 252 \
|| buffer_indicator == 253 \
|| buffer_indicator == 254 \
|| buffer_indicator == 255

// CONSTANT VARIABLES

const int maxCount = 3906;

//maximum count value for 'scaler' for a 1 second count
//formula: maxCount = (clk soource) / (256*4*2)
//in this case maxCount = (8MHz) / (256*4*2) = 3906

// GLOBAL VARIABLES

char dataBuffer[3] = {0,0,0}; //buffer variable

char dataReceived[4][3] = {{252,0,0},{253,0,0},{254,0,0},{255,0,0}};
char timeOutFlag[4] = {0,0,0,0}; //data time out flags

unsigned short seconds = 0; //counts the time elapsed in seconds

 138

unsigned short count = 0; //counts the number of bytes received

int scaler = 0; //counts the number of 'TMR0' overflows

// FUNCTION PROTOTYES

void identify_and_buffer(void); //identify_and_buffer function prototype

void update_time(void); //update_time function prototype
void transmit_data(void); //transmit_data function prototype

/**********************************************************************
* MAIN FUNCTION DEFINITION
**********************************************************************/

void main()
{

TRISB = 0x00; // configure PORTB as output

PORTB.F1 = 1; // set RB1
TXSTA = 0x24; // TXEN(TXSTA[5]) = 1 and BRGH(TXSTA[2]) = 1
RCSTA = 0x90; // SPEN(RCSTA[7]) = 1 and CREN(RCSTA[4]) =1
SPBRG = 0x33; // baud rate set to 9600 with FOsc = 8MHz
// Baud Rate = FOSC/(16 (X + 1))
// where SPBRG = X;
INTCON = 0xE0; // GIE(INTCON[7]) = 1, PEIE(INTCON[6]) = 1
// and TMR0IE(INTCON[7]) = 1
PIE1 = 0x20; // RCIF(PIE1[5]) = 1
// enable receive complete interrupt
OPTION_REG = 0x00; // TOCS(INTCON[5]) = 0; TMR0 is set in
// timer mode

while(1){}; // forever loop

/**********************************************************************
* INTERRUPT SERVICE ROUTINE FUNCTION DEFINITION
**********************************************************************/

void interrupt()
{

if(data_is_received) //if data is being received

{
identify_and_buffer();
}

if(INTCON.TMR0IF) //if TMR0 overflows

 139

{
update_time(); //update tme and transmit
}

/**********************************************************************
* IDENTIFY AND BUFFER FUNCTION DEFINITION
**********************************************************************/

void identify_and_buffer()
{

unsigned short i = 0;

if(count == 0) //if 1st byte is received

{
buffer_indicator = RCREG;

if(correctIndicator) //if indicator is correct

count = count + 1; //increment count

else if(count == 1 || count == 2) //if 2nd or 3rd byte is received

{
dataBuffer[count] = RCREG; //place data in buffer
count = count + 1; //increment count
}

if(count == 3) //all the data has been received

{

for(i = 0; i < 4; i++)

{
if(buffer_indicator == dad_indicator)
//if data being buffered is vital signs data
{
timeOutFlag[i] = 0; //reset time out flags
dad_tempData = buffer_tempData;
dad_pulseData = buffer_pulseData;
//tranfer buffered data
break;
}
}
 140

count = 0; //reset count

/*********************************************************************
* UPDATE TIME FUNCTION DEFINITION
**********************************************************************/

void update_time()
{

scaler = scaler + 1; //increment TMR0 overflow count

if(scaler > maxCount) //if 1 second has elapsed

{

seconds = seconds + 1; //increment 'seconds' count

scaler = 0; //reset TMR0 overflow count

if (seconds == 5) //if 5 seconds has elapsed

{

transmit_data(); //transmit data

seconds = 0; //reset seconds count

}
}

INTCON.TMR0IF = 0; //clear T0IF(INTCON[2])

TMR0 = 0x00; //clear TMR0

/**********************************************************************
* TRANSMIT DATA FUNCTION DEFINITION
*********************************************************************/

void transmit_data()
{

unsigned short i = 0;

TXREG = 2; //transmit '2'

for(i = 0; i < 4; i++)
 141

timeOutFlag[i]++; //increment time out flags

if(timeOutFlag[i] >= 3) //data transfer has timed out

{
delay_ms(5);
TXREG = 0 ; //reset temp data
delay_ms(5);
TXREG = 0 ; //reset pulse data
}
else //transmit temp and pulse data
{
delay_ms(5);
TXREG = dad_tempData ;
delay_ms(5);
TXREG = dad_pulseData ;
}

}
 142

B.7 Bluetooth Slave Controller/Data Acquisition Device source code

/**********************************************************************
*
* File Name: DATA_ACQUISITION_DEVICE.C
* Test configuration:
*
* MCU: PIC16F887A
* Oscillator: XT, 04.0000 MHz
*
* NOTES:
*
* MiKro C code for the data acquisition device for the special project entitled
*
* ETHERNET-BASED WIRELESS VITAL SIGNS MONITOR
*
**********************************************************************/

//USER DEFINES

#define done 0
#define start 1
#define conversion PIR1.ADIF
#define Not_Done !PIR1.ADIF
#define ADC_Start ADCON0.GO
#define convert_ADC_to_temp ((adcResult * 148.00)/ 458.80) + 2

//CONSTANT VARIABLES

const char dadIdentifier = 252;

//GLOBAL VARIBLES

unsigned adcResult = 0;
char pulseData = 0;
char tempData = 0;

// FUNCTION PROTOTYPES

void adc_start(void);
 143

/**********************************************************************
* MAIN FUNCTION DEFINITION
**********************************************************************/

void main()
{
TRISA = 0x01; // set RA0 as input
TXSTA = 0x24; // TXEN(TXSTA[5]) = 1 and BRGH(TXSTA[2]) = 1
RCSTA = 0x90; // SPEN(RCSTA[7]) = 1 and CREN(RCSTA[4]) =1
SPBRG = 0x19; // baud rate set to 9600 with FOsc = 4MHz
INTCON = 0x60; // enable interrupts
PIE1 = 0x71; // enable receive complete interrupt
ADCON0 = 0x81; // FOsc/32 and A/D module is powered on
ADCON1 = 0x8E; // Right justfied, Vref+ = Vdd, Vref- = Vss
TRISB = 0x00; // configure PORTB as output
PORTB.F1 = 1; // set RB1

while(1)
{

adc_start(); // start A/D conversion

pulseData = (rand() % 50) + 50; // randomize pulse data with range from 50
- 100

TXREG = dadIdentifier; // transmit device identifier

delay_ms(5);
TXREG = tempData; // transmit temp data
delay_ms(5);
TXREG = pulseData; // transmit pulse data
delay_ms(5);

};

/********************************************************************** *
*A/D Conversion Routine
**********************************************************************/

void adc_start()
{

delay_ms(5000); // delay for 5 seconds

ADC_Start = start; // start conversion
while(Not_Done){};// wait while conversion is not yet finished
 144

adcResult = (ADRESH << 8) | ADRESL;// get result

tempData = convert_ADC_to_temp; // convert to temperature data
conversion = done; // clear ADIF flag

}
Appendix C

TECHNICAL SPECIFICATIONS/MANUALS

WIZ810MJ Technical specification

W5100 Technical specification

PIC16F877A Technical specification

Atmeg32L Technical specification

EGBC-04 Manual

LM35 Technical specification

 CURRICULUM VITAE

Name: Arvin D. Miranda

Address: Pala-o, Iligan City
Date of Birth: August 3, 1987
Place of Birth: Linamon, Lanao del Norte
Gender: Male
Citizenship: Filipino
Religion: Roman Catholic
Civil Status: Single
Contact Number: (+63) 927-666-0446
Email Address: arvin.miranda@yahoo.com

EMPLOYMENT HISTORY:
On-the-job Training: Lexmark
k Research and Development Corporation (LRDC)
Cebu Business Park, Cebu City, Cebu
March 24 – June 24 2008

EDUCATIONAL ATTAINMENT:
Elementary: Sgt. Miguel P. Canoy Memorial Central School,, Buru-un,
Buru Iligan City
Secondary: Mindanao State University – Iligan Institute
itute of Technology, Integrated
Developmental School, Tibanga, Iligan City
Tertiary: Mindanao State University – Iligan Institute of Technology, Bachelor of
Science in Electronics and Communications Engineering,
Engineering Andres
Bonifacio Avenue, Tibanga, Iligan City

ORGANIZATIONS
2004 – 2009 Junior Institute of Electronics and Communications Engineers of the
Philippines - Northern Mindanao Sector (JIECEP - NMS)
2000 – 2009 Mindanao State University – Iligan Institute of Technology
Kataastaasang Samahan ng mga Mag-aaral
aaral (KASAMA)
 179

CURRICULUM VITAE

Name: Kister Genesis M. Jimenez

Address: Aloran, Misamis Occidental
Date of Birth: May 16, 1987
Place of Birth: Cebu City, Cebu
Gender: Male
Citizenship: Filipino
Religion: Roman Catholic
Civil Status: Single
Contact Number: (+63) 929-892-6812
Email Address: engkan2kit@gmail.com

EMPLOYMENT HISTORY:
On-the-job Training: Cebu Mitsumi Incorporated
Sabang, Danao City, Cebu
April 14 – May 31 2008

EDUCATIONAL ATTAINMENT:
Elementary: Lobogon Elementary School, Aloran, Misamis Occidental
Secondary: Aloran Trade High School (ATHS), Aloran, Misamis Occidental
Tertiary: Mindanao State University – Iligan Institute of Technology, Bachelor of
Science in Computer Engineering, Andres Bonifacio Avenue, Tibanga,
Iligan City

ORGANIZATIONS
2004 – 2009 Mindanao State University – Iligan Institute of Technology
Department of Science and Technology Scholar’s Association (MIDSA)
2004 – 2009 Mindanao State University – Iligan Institute of Technology
Kataastaasang Samahan ng mga Mag-aaral (KASAMA)
 180

CURRICULUM VITAE

Name: Dyl Therese A. Mesina

Address: Celdran Village, Iligan City
Date of Birth: June 3, 1987
Place of Birth: Tibanga, Iligan City
Gender: Female
Citizenship: Filipino
Religion: Roman Catholic
Civil Status: Single
Contact Number: (+63) 905-429-6199
Email Address: dylmsn@yahoo.com

EMPLOYMENT HISTORY:
On-the-job Training: GLOBAL Steel Incorporated
Suarez, Iligan City
April - May 2008

EDUCATIONAL ATTAINMENT:
Elementary: St. Michael’s College, Tibanga, Iligan City
Secondary: Mindanao State University – Iligan Institute
itute of Technology, Integrated
Developmental School, Tibanga, Iligan City
Tertiary: Mindanao State University – Iligan Institute of Technology, Bachelor of
Science in Electronics and Communications Engineering,
Engineering Andres
Bonifacio Avenue, Tibanga, Iligan City

ORGANIZATIONS
2004 – 2009 Junior Institute of Electronics and Communications Engineers of the
Philippines - Northern Mindanao Sector (JIECEP - NMS)
2000 – 2009 Mindanao State University – Iligan Institute of Technology
Kataastaasang Samahan ng mga Mag-aaral
aaral (KASAMA)