0

ABSTRACT
Powerful microcontrollers are used as parts of most home and office appliances of today.
Integrating web servers to these intelligent devices will aid in controlling them over the
Internet and also in creating effective user interfaces in the form of web pages. Assigning
multiple functionalities to a single button on an appliance help manufacturers economize user
interfaces, but, this can easily create confusion for the users. Since the cost of web-based
interfaces is considerably low, they can be used to provide the infrastructure for the design of
simple and more user-friendly interfaces for household appliances. Also, a web page based
interface is much easier to change, when needed, as compared to a hardware interface.
This paper presents a novel approach to control devices with embedded web servers
over the Internet and to form device networks such that their components can make use of
one anothers services and functions while improving the user interfaces. The main benets
of this approach include its lightweight design, automatic conguration, and utilization of
widely available and tested network protocols of TCP/IP and HTTP. The validity of the
approach has been veried through a prototype system working with real appliances.

This is a continuation of the article An AVR microcontroller based Ethernet device. The
hardware is still the same (ENC28J60 + atmega88). The software is now updated to provide
also a web-server. That is: instead of using a command line application and send UDP
packets to the Ethernet device we can just point our web browser to it and even better: we add
only the web server and all the UDP based functionality is still there. Now can use the code is
written in C and there is even a lot of space left on the at mega 88 microcontroller.









1

CHAPTER-1
INTRODUCTION
Many home and office appliances such as televisions, VCRs, telephones, watches,
ovens,toasters, dish-washers and thermostats produced over the last decade are equipped with
complex features. This has become possible by the computer industrys ability to t more
transistors into a smaller area of silicon which increases the computational capabilities of
devices while decreasing the cost and the power consumption. Nowadays, most of the home
and office devices contain embedded microcontrollers. One of the most important reasons for
embedding computers to everyday appliances is that they make the appliance easy to use
while giving them new features that enhance their values (Borriello and Want, 2000). As of
today, these embedded computers cost a few dollars and are as capable as desktop computers
of 1980s.
Such devices can support an embedded operating system with a TCP/IP stack, interface to a
10/100 Mbps network and can be used as web servers. The Internet has been mostly used to
connect personal computers so far, but shortly all kinds of appliances with embedded
computers will exchange information over the Internet. A massive number of
microcontrollers are available in todays devices which can be linked to the Internet. If these
intelligent appliances could be connected to the Internet at low cost, the way we control and
manage their functions would change entirely.
As the abilities of appliances increase, the complexity of controlling these devices increases
as well. The need for informative user interfaces is suppressed by the higher cost of
implementation. Therefore, complex appliances are not an option considering an environment
with thousands of embedded systems. We clearly should come up with a compact solution.
Web pages can be used as user interfaces where each appliance has the ability to serve its
user interface as a web page over the Internet. These pages can contain not only text but also
pictures, hypertexts, photographs, video and audio as in usual web pages. By the advent of
the user interfaces based on web pages, all devices requiring user interaction can be
controlled and managed from one device which includes a web browser, such as a personal
digital assistant, cell phone, etc. Also, use of web page based, button and display free designs
reduce the cost of production while making the systems more user-friendly. Remote control
via the Internet is not a new feature and used in home automation system.
However, providing a mechanism for interaction between devices in this environment is quite
challenging. For example, an alarm clock can interact with the heating system according to
2

the alarm time and can send instructions to the heating system to start warming the house
before the residents wake up.We designed application architecture, and, built and
demonstrated a prototype system that can integrate web servers to everyday appliances with
embedded microcontrollers to control and manage them via web pages using regular web
browsers.
The system allows forming device networks such that their components can easily make use
of each others services and functions.

1.1 CHEMISTRY BEHIND EMBEDDED SYSTEM
1. Real-Time Models
2. Periodic/ Aperiodic Tasks
3. Communication with outer world
4. Resource Sharing among them
5. Low Power Design
6. Self-sustained
7. Cost efficient


Fig. 1Data flow diagram

3

1.2 PROCESS OF DATA FLOW
It enables users to control various aspects of their home appliances form a remote location
through the use of the internet. It hence makes for a powerful & versatile system which
expands the mobility of users by granting them total control over their home without the need
of physical presence.
The project layout is explained below along with the components required to build a system:
1) A graphical user interface will be designed as a part of the web based application.
2) The user will access this interface and control the home appliances.
3) The data from this application will be passed on to the local server, that is, the home PC.
4) The PC will pass on the signals to the microcontroller.
5) The microcontroller will be programmed in an appropriate way to understand this signal
and thus convert it to an electrical signal and transmitted to the switch controlling the home
appliance. The end result will be a simple action like: switching on a light.
We believe that an attractive alternative to the existing techniques is a web servers based
system, where each appliance runs an embedded web server serving the pages needed for its
own user interface. This approach is considerably simpler than the existing systems while
keeping most of their functionalities.
















4

CHAPTER- 2
REVIEW OF LITERATURE
The literature related to the research topic has been reviewed for last twenty years in order to
find out work carried out by various researchers. There are many systems for remote
monitoring and control designed as commercial products or experimental research platforms.
It is noticed that most of the research carried out belongs to the following categories.
1. Internet based Monitoring using Servers, GPRS modems, etc. with different
approaches.
2. GSM-SMS protocols using GSM module individually or in combination with Internet
Technologies.
3. Monitoring using Wireless Sensor Networks.
4. Wireless Monitoring using Bluetooth, Wi-Fi, Zig bee and RF.
5. Applications have varied widely like Home Automation, Security Systems, Bio-
medical applications, Agriculture, Environment, Reservoir, Bridge health monitoring,
etc.
2.1 Source of Project Idea:
When dedicated servers exist, capable of serving thousands of complicated web pages. Why
bother building a web server on an Atmel 16 megahertz microcontroller?
We each saw a different vision as to how this web server might serve a useful purpose.
In more of a traditional microcontroller approach, we saw the project as being useful as an
interface to control household appliances or systems. In other words, by using Internet
protocols, a home owner could interface with his household systems and control the lights,
security system, or certain smart appliances. While our project would require more
development to serve this purpose, we have certainly laid the groundwork for such a system.
We saw the project as potentially serving another purpose. Since the final server was just
around $40 while a standard server is in the tens of thousands of dollars, we saw the web
server as a potential playing field flattener for developing countries.
The last decade and a half has seen an increase in the number of developing countries
desiring to obtain an internet presence as soon as possible. They know that an internet
presence is more important than their industrial capabilities. However, the cost of a
professional grade server makes it out of their reach. With the Mega16, they would have the
ability to serve up web pages for the small price of $40 for the parts and whatever a
connection to the Internet costs.
5

2.2 Internet Based Monitoring:
Internet monitoring is one of the common approaches for remote monitoring. Many
researchers have worked in field of Internet based remote monitoring.
(Saito et al., 2000) developed home gateway system for interconnecting home network
consisting of IEEE 1394 AV network and X10 power line home automation network with
Internet. This provided remote access functions from Internet for digital AV appliances like
Digital Video Camera, Digital VCR connected to IEEE 1394 network and home appliances
like TV, desk lamp, electric fan connected to X10 controller.(Al-Ali and Al-Rousan)
developed Java based home automation system via World Wide Web. The home appliances
were controlled from ports of embedded system board connected to PC based server at
home.(Alkar and Buhur, 2005) implemented Internet based wireless flexible solution where
home appliances are connected to slave node.
The software of the system is based on the combination of AVRstudio, Eagle 0.5 Server
Pages, and JavaBeans, and dynamic DNS service (DDNS) client. Password protection is used
to block the unauthorized user from accessing to the server.
The current operational parameters of the system are measured by microcontroller and
displayed on LCD. Using web camera focused on LCD, these parameters are monitored
online by client PC. To accomplish Internet connectivity, a web server is built to take
requests from remote clients.
The clients can send requests to the home appliances. The home appliances can send their
statuses to be displayed for the remote client through the server. A web page is constructed as
an interactive interface where commands can be submitted by the client to change and also
monitor the status of the devices. A speech recognition program is written to control the
house by means of human voice. Dynamic Time Warping (DTW) algorithm is used for
speech recognition.
In depth:
1. Primarily looking at the existing status of research in remote monitoring, major impetus is
only for development of system applications in industrial automation, home automation,
health care systems and defence.
2. With explosive growth of cellular networks in India and sharp reduction in cost of handsets
and call charges with coverage of >70% of area, cell phones offer unique opportunity for
remote control even in rural area.
6

3. The research work presented in this thesis is aimed to remotely monitor the system using
cell phone by designing and implementing embedded system.
4. It is aimed to provide facility to use even any obsolete mobile model having simple
messaging and calling function to make remote system affordable to all categories of users.
5. The major aspect of the research had been to work out strategies to keep operational cost of
the system minimum to emphasize its utility to automate simple systems with remote.

2.3 OVERVEIW OF EMBEDDED SYSTEM:
An embedded system is a computer system designed to do one or a few dedicated and/or
specific functions often with real-time computing constraints. It is embedded as part of a
complete device often including hardware and mechanical parts. By contrast, a general-
purpose computer, such as a personal computer (PC), is designed to be flexible and to meet a
wide range of end-user needs. Embedded systems control many devices in common use
today.

Figure 2: Embedded system

Embedded systems are controlled by one or more main processing cores that are typically
either microcontrollers or digital signal processors (DSP). The key characteristic, however, is
being dedicated to handle a particular task, which may require very powerful processors. For
example, air traffic control systems may usefully be viewed as embedded, even though they
involve mainframe computers and dedicated regional and national networks between airports
and radar sites (Each radar probably includes one or more embedded systems of its own).

7

Since the embedded system is dedicated to specific tasks, design engineers can optimize it to
reduce the size and cost of the product and increase the reliability and performance. Some
embedded systems are mass-produced, benefiting from economies of scale.
Physically, embedded systems range from portable devices such as digital watches and MP3
players, to large stationary installations like traffic lights, factory controllers or the systems
controlling nuclear power plants. Complexity varies from low, with a single microcontroller
chip, to very high with multiple units, peripherals and networks mounted inside a large
chassis or enclosure.
In general, "embedded system" is not a strictly definable term, as most systems have some
element of extensibility or programmability. For example, handheld computers share some
elements with embedded systems such as the operating systems and microprocessors which
power them, but they allow different applications to be loaded and peripherals to be
connected. Moreover, even systems which do not expose programmability as a primary
feature generally need to support software updates. On a continuum from "general purpose"
to "embedded", large application systems will have subcomponents at most points even if the
system as a whole is "designed to perform one or a few dedicated functions", and is thus
appropriate to call "embedded".

2.3 Application of Embedded Electronics:
1. Automotive
2. Robotics
3. Consumer Electronics
4. Communication Systems
5. Control System


Figure 3: Industrial equipment
8

2.4 BASICS OF NETWORK MODEL:

The Open Systems Interconnection model (OSI model) was a product of the Open Systems
Interconnection effort at the International Organization for Standardization. It is a way of
sub-dividing a communications system into smaller parts called layers. Similar
communication functions are grouped into logical layers. A layer provides services to its
upper layer while receiving services from the layer below. On each layer, an instance
provides service to the instances at the layer above and requests service from the layer below.
The concept of a 7 layer model was provided by the work of Charles Bachman, Honeywell
Information Services. Various aspects of OSI design evolved from experiences with the
ARPANET, the fledgling Internet, NPLNET, EIN, CYCLADES network and the work in
IFIP WG6.1. The new design was documented in ISO 7498 and its various addenda. In this
model, a networking system was divided into layers. Within each layer, one or more entities
implement its functionality. Each entity interacted directly only with the layer immediately
beneath it, and provided facilities for use by the layer above it.
Protocols enabled an entity in one host to interact with a corresponding entity at the same
layer in another host. Service definitions abstractly described the functionality provided to an
(N)-layer by an (N-1) layer, where N was one of the seven layers of protocols operating in the
local host.

Table 1: OSI MODEL
9

a) Layer 1: Physical Layer
The Physical Layer defines electrical and physical specifications for devices. In particular, it
defines the relationship between a device and a transmission medium, such as a copper or
optical cable. This includes the layout of pins, voltages, cable specifications, hubs, repeaters,
network adapters, host bus adapters (HBA used in storage area networks) and more.
The major functions and services performed by the Physical Layer are:
1. Establishment and termination of a connection to a communications medium.
2. Participation in the process whereby the communication resources are effectively
shared among multiple users. For example, contention resolution and flow control.
3. Modulation, or conversion between the representation of digital data in user
equipment and the corresponding signals transmitted over a communications channel.

These are signals operating over the physical cabling (such as copper and optical fibre) or
over a link. Parallel buses operate in this layer, although it must be remembered that the logical
SCSI protocol is a Transport Layer protocol that runs over this bus. Various Physical Layer
Ethernet standards are also in this layer; Ethernet incorporates both this layer and the Data
Link Layer. The same applies to other local-area networks, such as token ring, FDDI, ITU-
TG.hn and IEEE 802.11, as well as personal area networks such as Bluetooth and IEEE
802.15.4.
b) Layer 2: Data Link Layer
The Data Link Layer provides the functional and procedural means to transfer data between
network entities and to detect and possibly correct errors that may occur in the Physical
Layer. Originally, this layer was intended for point-to-point and point-to-multipoint media,
characteristic of wide area media in the telephone system. Local area network architecture,
which included broadcast-capable multi-access media, was developed independently of the
ISO work in IEEE Project 802. IEEE work assumed sub layering and management functions
not required for WAN use. In modern practice, only error detection, not flow control using
sliding window, is present in data link protocols such as Point-to-Point Protocol (PPP), and,
on local area networks, the IEEE 802.2 LLC layer is not used for most protocols on the
10

Ethernet, and on other local area networks, its flow control and acknowledgment mechanisms
are rarely used. Sliding window flow control and acknowledgment is used at the Transport
Layer by protocols such as TCP, but is still used in niches where X.25 offers performance
advantages.
The ITU-TG.hn standard, which provides high-speed local area networking over existing
wires (power lines, phone lines and coaxial cables), includes a complete Data Link Layer
which provides both error correction and flow control by means of a repeat Sliding.
c) Layer 3: Network Layer
The Network Layer provides the functional and procedural means of transferring variable
length data sequences from a source host on one network to a destination host on a different
network, while maintaining the quality of service requested by the Transport Layer (in
contrast to the data link layer which connects hosts within the same network). The Network
Layer performs network routing functions, and might also perform fragmentation and
reassembly, and report delivery errors. Routers operate at this layer sending data throughout
the extended network and making the Internet possible. This is a logical addressing scheme
values are chosen by the network engineer. The addressing scheme is not hierarchical.Careful
analysis of the Network Layer indicated that the Network Layer could have at least three sub
layers:
1. Sub network Access - that considers protocols that deal with the interface to networks,
such as X.25;
2. Sub network Dependent Convergence - when it is necessary to bring the level of a
transit network up to the level of networks on either side;
3. Sub network Independent Convergence - which handles transfer across multiple
networks?
The best example of this latter case is CLNP, or IPv7 ISO 8473. It manages the
connectionless transfer of data one hop at a time, from end system to ingress router, router to
router, and from egress router to destination end system. It is not responsible for reliable
delivery to a next hop, but only for the detection of erroneous packets so they may be
discarded. In this scheme, IPv4 and IPv6 would have to be classed with X.25 as subnet access
protocols because they carry interface addresses rather than node addresses.
11

d) Layer 4: Transport Layer
The Transport Layer provides transparent transfer of data between end users, providing
reliable data transfer services to the upper layers. The Transport Layer controls the reliability
of a given link through flow control, segmentation/dsegmentation, and error control. Some
protocols are state and connection oriented. This means that the Transport Layer can keep
track of the segments and retransmit those that fail. The Transport layer also provides the
acknowledgement of the successful data transmission and sends the next data if no errors
occurred.
Although not developed under the OSI Reference Model and not strictly conforming to the
OSI definition of the Transport Layer, typical examples of Layer 4 are the Transmission
Control Protocol (TCP) and User Datagram Protocol (UDP).

Table 2: OSI Protocol

Fig OSI Model with Protocols
12

CHAPTER-3
BRIEF METHODOLOGY
3.1 WEB SERVER HARDWARE:
The hardware is exactly the same as described in the previous article An AVR
microcontroller based Ethernet device:
Figure 4: Circuit diagram .

3.2 Hardware Design:
Our goal was to design AVR microcontroller based web server having all the basic
requirements of a Network server. For this we designed a general purpose microcontroller
board having provision to base any DIP-40 based MCU like Mega16, Mega32 or Mega 644
so that we can have a provision to load minimal embedded TCP/IP stack having 12kb size.

13


Figure 5: Schematic of General Purpose Atmega32 board

3.3 Board Layout:-


Figure 6: Board Layout Used for PCB Development
3.3.1 Features of this board are:-
1. AVR architecture based Atmega16 from Atmel.
2. On board regulated Power supply.
3. On Board provision for Character LCDs based on HD44780 Decoder
4. An extra drill to suffix any minor attachments like LEDs or switches.
5. Having option to provide DC supply using 2.5 mm DC jack or wires.
14

3.4 ENC28j60 based Ethernet Module:-
Ethernet is a local area technology, which is used for reliable and efficient transfer and access
of information across the devices connected to the network. Once a device is attached to the
network, it will have the ability to communicate with any other attached device. This allows
the network to expand to accommodate new devices without requiring any modification to
those devices already on the network.
Ethernet controller Enc28J60 from Microchip forms the building block for our
Ethernet Interface add-on Board. Its an SPI based add-on chip which has Ethernet PHY and
MAC to equip any embedded controller with SPI interface with network capability.
The Ethernet Interface Board can be connected to the AVR Board (which will be the
heart of that particular device) and by using SPI pins of the Ethernet controller (ENC28J60)
the Ethernet Interface Board communicates with the AVR Board.
This Ethernet Interface can through this interface our controller can communicate
with other devices connected on the network including PCs. Any development board using a
controller with SPI (Serial Peripheral Interface) interface can be interconnected with Ethernet
Interface Board.

3.4.1 PIN DIAGRAM:
Figure 7: Pin Diagram

15

3.4.2 Description:-
Ethernet Interface board contains the Ethernet Controller ENC28J60 be used to develop
different applications like embedded web server, Ethernet based Data acquisition system,
internet controlled robot etc.

3.4.3 Ethernet Buffer:
It is the memory area inside ENC28J60 and it contains transmit and receive memory used by
the Ethernet controller in a single memory space, means receive and transmit share the same
buffer (memory). The sizes of the memory areas are programmable by the host controller
using the SPI interface. It is of 8-Kbyte transmit/receive packet dual port SRAM. The
Ethernet buffer memory can only be accessed via the read buffer memory and write buffer
memory SPI commands.
In ENC28J60 Network Interface(Link) Layer is present, that means Physical layer +
MAC layer (comes inside Link layer), with this we can achieve physical connection and link
detection for application layer protocols like FTP, HTTP etc. TCP/IP stack should be ported
to the embedded device.

a) Ethernet Controller Features:-
1. IEEE 802.3 compatible Ethernet controller
2. Integrated MAC and 10BASE-T PHY
3. Receiver and collision squelch circuit
4. Supports one 10BASE-T port with automatic polarity detection and correction
5. Supports Full and Half-Duplex modes
6. Programmable automatic retransmit on collision
7. Programmable padding and CRC generation
8. Programmable automatic rejection of erroneous packets
9. SPI Interface with speeds up to 10 Mb/s

b) Operational Feature:
1. Two programmable LED outputs for LINK, TX, RX, collision and full/half-duplex
status
2. Seven interrupt sources with two interrupt pins
3. 25MHz clock
16

4. Clock out pin with programmable pre-scalar
5. Operating voltage range of 3.14V to 3.45V
6. TTL level inputs
7. Temperature range: -40C to +85C Industrial,0C to +70C Commercial (SSOP
only)
8. 28-pin SPDIP, SSOP, SOIC, QFN packages.
As this IC is available only in SMD packages so it was difficult to design its PCB at College
level so we found a ready-made module from embedded market worth $25.

Figure 8:Schematic of Enc28j60 module

3.5 INTERNAL CIRCUIT OF ETHERNET MODULE:


Figure 9: Actual view of General purpose board and Ethernet module
17

CHAPTER -4
SOFTWARE DEVELOPMENT
4.1 Building and loading the software
Unpack the eth_rem_dev_tcp-2.X package (command tar -zxvf eth_rem_dev_tcp-2.X to
unpack, software download at the end of this article). Take a look at the included README
file it contains detailed instructions.
Next you need to set the IP address for your hardware. Edit the file main.c and change the
3 lines:
Static uint8_t mymac[6] = {0x54,0x55,0x58,0x10,0x00,0x24};
Static uint8_t myip[4] = {10,0,0,24};
Static char baseurl[]="http://10.0.0.24/";
For the first device is you will not need to change the mimic line But you will probably
need to change the IP address (my-IP). It must be a free address from the address range in
yournetwork.
There is a range of private addresses (not routed on the public Internet) which you can use:
Net mask Network Addresses
255.0.0.0 10.0.0.0 - 10.255.255.255
255.255.0.0 172.16.0.0 - 172.31.255.255
255.255.255.0 192.168.0.0 - 192.168.255.255
Example: your WIFI router might have 192.168.1.1; your PC might have 192.168.1.2. This
means you could e.g. use 192.168.1.10 and leaves some room for more PCs.If you use DHCP
from your router then make sure that theaddress it not double allocated (exclude it from the
DHCPrange).Now compile the software with the command "make". Load the
eth_rem_dev_tcp.hex file into the microcontroller. Open a web browser and point it to
http://Ip.Addr.you.assigned/secret




18

4.2 Software Design:
All the software is based upon open source codes available for AVR microcontrollers.
Libraries for Enc28j60 Ethernet module have been provided by Microchip. A minimal
TCP/IP stack which was originated from uIP stack written by Adam Dunkells and later on it
was ported for AVR by Pascal Stang from Procyon engineering under AVRlib project.
1. Instructi on set:
The AVR instruction set is more orthogonal than those of most eight-bit microcontrollers, in
particular the 8051 clones and PIC microcontrollers with which AVR competes today.
However, it is not completely regular.
2. Program Executi on:
AVRs have a two stage, single level pipeline design. This means the next machine
instruction is fetched as the current one is executing. Most instructions take just one or two
clock cycles, making AVRs relatively fast among eight-bit microcontrollers.The AVR
processors were designed with the efficient execution of compiled C code in mind and have
several built-in pointers for the task.
4.3.1 WINAVR (avr-gcc):
WinAVR (pronounced "whenever") is a suite of executable, open source software
development tools for the Atmel AVR series of RISC microprocessors hosted on the
Windows platform. It includes the GNU GCC compiler for C and C++.
a) New features in winavr:
1. Major version change for GCC.
2. Support for the ATmega128 and ATmega2561 devices.
3. Change the DWARF2 debug information from 16-bit addresses to 32-bit addresses.
This now allows debugging of code above 64K, including boot loaders for the
ATmega128 and ATmega1281, and debugging of the ATmega2560 and ATmega2561
devices. This requires a version of AVR Studio that has a new ELF/DWARF2 parser
(> 4.12).
4. New AVRlib version with new examples, updated examples, many bugs fixed, and
new APIs for Power Reduction and Clock Pre-scalar.
19

WINAVR is a collection of executable software development tools for the Atmel AVR
processor hosted on Windows.
b) These software development tools include:
1. Compilers
2. Assembler
3. Linker
4. Librarian
5. C Library
6. Debugger
7. In-Circuit Emulator software
8. Editor / IDE
9. Many support utilities
4.4 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, assembler and front-end for
C/C++, programming, emulation and on-chip debugging.

AVR STUDIO-4 Capture
20

AVR Studio supports the complete range of ATMEL AVR tools and each release will always
contain the latest updates for both the tools and support of new AVR devices.
AVR Studio 4 has a modular architecture which allows even more interaction with 3rd party
software vendors. GUI plug-ins and other modules can be written and hooked to the system.
The AVR Simulator is a software simulator for the AVR architecture and devices. It
simulates the CPU, including all instructions, interrupts and most of the on-chip I/O modules.
The AVR Simulator operates within the AVR Studio application as a debug target. This
enables the user to use the normal debug commands such as Run, Break, and Reset, Single
step, set breakpoints and watch variables. The I/O, memory and register views are fully
functional using the AVR Simulator.
Let's look at the code of basic_web_server_example
#include <avr/io.h>
#include <stdlib.h>
#include <string.h>
#include "ip_arp_udp_tcp.h"
#include "enc28j60.h"
#include "timeout.h"
#include "avr_compat.h"
#include "net.h"
1// This software is a web server only.
12static uint8_t mymac[6] = {0x54,0x55,0x58,0x10,0x00,0x29};
// the web server's own IP address:
static uint8_t myip[4] = {192,168,255,100};

21

// server listen port for www
#define MYWWWPORT 80
#define BUFFER_SIZE 550
static uint8_t buf[BUFFER_SIZE+1];
uint16_t http200ok(void)
{
return(fill_tcp_data_p(buf,0,PSTR("HTTP/1.0 200 OK\r\n
Content-Type: text/html\r\nPragma: no-cache\r\n\r\n")));
}
// prepare the webpage by writing the data to the tcp send buffer
uint16_t print_webpage(uint8_t *buf)
{
uint16_t plen;
plen=http200ok();
plen=fill_tcp_data_p(buf,plen,PSTR("<pre>"));
plen=fill_tcp_data_p(buf,plen,PSTR("Hi!\nYour web server works great."));
plen=fill_tcp_data_p(buf,plen,PSTR("</pre>\n"));
return(plen);
}
intmain(void){
uint16_t dat_p;
// set the clock speed
CLKPR=(1<<CLKPCE);
22

CLKPR=0; // 8 MHZ
_delay_loop_1(0); // 12
//initialize the hardware driver for the enc28j60
enc28j60Init(mymac);
enc28j60clkout(2); // change clkout from 6.25MHz to 12.5MHz
_delay_loop_1(0); // 60us
enc28j60PhyWrite(PHLCON,0x476);
_delay_loop_1(0); // 60us
//init the ethernet/ip layer:
init_ip_arp_udp_tcp(mymac,myip,MYWWWPORT);
While (1){
// read packet, handle ping and wait for a tcp packet:
dat_p=packetloop_icmp_tcp(buf,
enc28j60PacketReceive (BUFFER_SIZE, buf));
/* dat_p will be unequal to zero if there is a valid http get */
if(dat_p==0){
// no http request
Continue;
}
// tcp port 80 begin
if (strncmp("GET ",(char *)&(buf[dat_p]),4)!=0){
// head, post and other methods:
dat_p=http200ok ();
23

dat_p=fill_tcp_data_p(buf,dat_p,
PSTR ("<h1>200 OK</h1>"));
\goto SENDTCP;
}
// just one web page in the "root directory" of the web server
if (strncmp("/ ",(char *)&(buf[dat_p+4]),2)==0){
dat_p=print_webpage(buf);
goto SENDTCP;
} else {
dat_p=fill_tcp_data_p(buf,0,PSTR("HTTP/1.0 401 Unauthorized
\r\nContent-Type: text/html\r\n\r\n<h1>401 Unauthorized</h1>"));
goto SENDTCP;
}
SENDTCP:
www_server_reply(buf,dat_p); // send web page data
// tcp port 80 end
}
return (0);
}
1. The interesting part starts on line 12 and 14. It defines the IP address and the MAC
address of this device.
2. The MAC address has be unique in your own LAN your neighbor could re-use the
same numbers.
3. Let's jump to lines 41-51. Here the hardware and Ethernet layer is initialized.
24

4. You don't have to change anything. Line 54 initializes the actual web server TCP/IP
stack and you can leave it also as it is. Microcontrollers do normally not have an
operating system. Line 56 is therefore "our operating system". It is an endless loopthat
executes one by one the tasks that need to be performed. The most important task here
is to wait for incoming packets. This is line 58. Enc28j60PacketReceivegets the
packet from the driver and packetloop_icmp_tcp is the actual stack which returns the
position (dat_p) of the http data in variable but if there is a request for a webpage.

Line 66 handles all requests but an actual http-get. If there is an actual http get then we
go to line 73 and check if the web browser was asking just for the root web page. If you web
server is at 10.0.0.29 then this root page would correspond to the URL http://10.0.0.29.
Web browsers ask these days for all kind of things such as favicon.ico files or crawlers
ask for robots.txt. It is therefore important that we return a http error code 401. On line 74 we
call the previously defined function "dat_p=print webpage (buf);" which prints the actual web
page into the variable buf. The variable buf has to be big enough to hold the IP packet with
the web page. You will notice when it is to small as the web server stops then to work. The
function fill_tcp_data_p is used to fill the web page with data. fill_tcp_data_p takes a hard
coded string, "PSTR", which the compiler puts into flash memory only.
This saves RAM. If you want to print dynamic datae.g sensor data) onto the web page
then you use fill_tcp_data (without the _p).Fill_tcp_datatakesa normal C-string as argument.
The actual web page which we produce in the function print webpagelooks like this:
<pre>
Hi!
Your web server works great.


25

A relay can be connected. Note the diode D1. It is not useless and it is not the wrong
way round in the circuit diagram even though it looks like that. It is there for those who plan
to connect a small 6V relay on that output. It protects the whole circuit against the possibly
very high voltages which can be induced by the coil of a relay.

Figure10: relay coil
If you use a relay with a large coil then you should also add a resistor in parallel to the
relay (e.g 1K or 2.2K). The diodes have a finite response time and such a resistor will prevent
the voltages to raise too fast before the diode cuts them.
If you plan use 9V raw-DC (or maybe more) in combination with a 6V relay on CONN3
then you can add a small resistor (e.g 33 Ohm, you have to experiment) in series to the relay
to compensate for the higher voltages. The connectors named "IO-ports" and "Analog-IN" are
not used for now. They are meant for future functionality which will be described in later
articles. We will only use CONN3 in this project.
Ethernet requires quite high currents because it can be used with rather long cables. The
above circuit consumes about 200mA at 3.3V. The LM2937-33 needs therefore cooling if the
supply voltage is more than 5V (on Raw-DC-In). A small piece of aluminium is normally
enough.

26

CHAPTER-5
IMPLEMENTATION
A UDP command interface is sufficient for most applications but an integrated web-server is
much more universal and easier to use. How to build a web server into an atmega32 chip?

Before starting this Ethernet project I did of course some prototyping and then I noticed
already that UDP was not a problem with lots of space left on the atmega88. Therefore I was
quite confident that TCP + HTTP will work. TCP/IP was invented more than 25 years ago.
Todays microcontrollersprovide almost the computing power a standard computer had at
that time. No java or xml was used at that time. Things were done in smart and efficient
ways.

So here is a real web-server on an atmega32 AVR microcontroller.

Figure 11: Controlling &monitoring from remote PC
27

5.1 TCP is a state machine:
TCP is a protocol where one establishes a connection. For this a number of packets are first
exchanged and both sides of the connection go through several states [see tcp state machine
from rfc793]. Once the connection is established a number of data packets can be sent. More
than one packet, large amounts of data can be sent.Counters and the state machine ensure that
the actual user data arrives in correct order and without data loss. Large web pages will need
to send many data packets. Small pages less. How many do we need to send???
Let's take a look at the application. In this figure shone below we just switch on and off
something. It can be done with a simple web page which might look like this:


Output is: ON

Switch off


Figure 12: The web page needed for the Ethernet Remote Device circuit.

Other applications might be measurement of temperature or air pressure. Those are all
small web pages with is very little data. In other words we will send this less than 100 bytes
including all the html tags. How many IP packets with data will be sent for such a page?
Just one!
The whole point of using TCP is that one can send more than one packet of data but we
don't need that functionality. We need TCP only because HTTP is based on it and we want
HTTP in order to use our web browser.
Under the assumption that you will never need to send more than the one packet with data the
whole TCP protocol and state handling can be simplified a lot.
We can send theFIN immediately together with the data. This makes the state handling
for the closing of the connection very simple.

Under this assumption it possible to implement the web-server in a atmega88 and it have just
under 50% of the chip's memory still free for the actual application.



28

5.2 DESIGN COMPONENTS:
The system contains both hardware & software components which are classified as follows:
5.2.1 SOFTWARE COMPONENTS:
i. Visual Basic: It is a versatile programming language which can be used to create various
GUI applications. In this system, VB is used for creating a client-server application for the
remote and local server respectively.
ii. Telnet: The purpose of the TELNET Protocol is to provide a fairly general, bi-directional,
eight-bit byte oriented communications facility. Its primary goal is to allow astandard method
of interfacing terminal devices and terminal-oriented processes to each other. Telnet will be
used to set up a server-client program to execute commands from the remote terminal.
iii. WINAVR: It is a suite of executable, open source software development tools for the
Atmel AVR series of RISC microprocessors hosted on the Windows platform. It includes the
GNU GCC compiler for C and C++. It is used for creation & embedding of a program for the
microcontroller in C language.
5.2.2 HARDWARE COMPONENTS
i. Microcontroller: The microcontroller used is the brain of the entire system. It will receive
the commands executed on the remote server and compute the appropriate instructions to
control the home appliances.
ii. Local Server: This machine serves as a focal point in the system. It acts as a bridge
between the user (remote machine) & the various home appliances. It also acts an interface to
the microcontroller. .
The local server passes on the user commands to the microcontroller via the interface created
in VB. The local server has a GUI which can also be used to control the home appliances.
iii. Modem: The modem receives the command signals sent to the local server from the
remote PC. The modem is directly connected to the local server & acts as a connection
between the local sever & the internet. The modem used in the system can either be a wired
or a wireless modem.
29

iv. Remote Workstation: The remote machine is the component from which the actual user
of the system will use the system to control the home appliances. The remote machine can be
any machine which is connected to the internet. The remote machine can be used to access
the Telnet client application over the internet. The user of the remote machine will be able to
control the various home appliances remotely.
v. Home Appliance: The home appliances must be connected to the main power supply at all
times. This is a precondition for the system. The various aspects of the system which can be
controlled are:
a. The appliances status (ON/OFF)
b. The output power of the appliance
c. The time for which the appliance is running.
5.3 BLOCK DIAGRAM OF WEB SERVER:

Figure 13: web server


30

5.4 Micro IP (IP) TCP/IP Protocol suit:
With the success of the Internet, the TCP/IP protocol suite has become a global standard for
communication. TCP/IP is the underlying protocol used for web page transfers, e-mail
transmissions, file transfers, and peer-to-peer networking over the Internet. For embedded
systems, being able to run native TCP/IP makes it possible to connect the system directly to
an intranet or even the global Internet. Embedded devices with full TCP/IP support will be
first-class network citizens, thus being able to fully communicate with other hosts in the
network.. The uIP implementation is designed to have only the absolute minimal set of
features needed for a full TCP/IP stack. It can only handle a single network interface and
contains the IP, ICMP, UDP and TCP protocols. UIP is written in the C programming
language.
Many other TCP/IP implementations for small systems assume that the embedded device
always will communicate with a full-scale TCP/IP implementation running on a workstation-
class machine. Under this assumption, it is possible to remove certain TCP/IP mechanisms
that are very rarely used in such situations. Many of those mechanisms are essential,
however, if the embedded device is to communicate with another equally limited device, e.g.,
when running distributed peer-to-peer services and protocols. uIP is designed to be RFC
compliant in order to let the embedded devices to act as first-class network citizens. The uIP
TCP/IP implementation that is not tailored for any specific application.
ENCJ28 MICROCHIP LAYERED DIAGRAM:
Figure 14: layer structure
31

5.4.1 TCP/IP Communication:
The full TCP/IP suite consists of numerous protocols, ranging from low level protocols such
as ARP which translates IP addresses to MAC addresses, to application level protocols such
as SMTP that is used to transfer e-mail.
The uIP is mostly concerned with the TCP and IP protocols and upper layer protocols
will be referred to as "the application". Lower layer protocols are often implemented in
hardware or firmware and will be referred to as "the network device" that is controlled by the
network device driver.
TCP provides a reliable byte stream to the upper layer protocols. It breaks the byte
stream into appropriately sized segments and each segment is sent in its own IP packet. The
IP packets are sent out on the network by the network device driver. If the destination is not
on the physically connected network, the IP packet is forwarded onto another network by a
router that is situated between the two networks. If the maximum packet size of the other
network is smaller than the size of the IP packet, the packet is fragmented into smaller
packets by the router. If possible, the size of the TCP segments is chosen so that
fragmentation is minimized. The final recipient of the packet will have to reassemble any
fragmented IP packets before they can be passed to higher layers.
The formal requirements for the protocols in the TCP/IP stack are specified in a number
of RFC documents published by the Internet Engineering Task Force, IETF. Each of the
protocols in the stack is defined in one more RFC documents and RFC1122 collects all
requirements and updates the previous RFCs.The RFC1122 requirements can be divided into
two categories; those that deal with the host to host communication and those that deal with
communication between the application and the networking stack. An example of the first
kind is "A TCP MUST be able to receive a TCP option in any segment" and an example of
the second kind is "There MUST be a mechanism for reporting soft TCP error conditions to
the application."
A TCP/IP implementation that violates requirements of the first kind may not be able to
communicate with other TCP/IP implementations and may even lead to network failures.
Violation of the second kind of requirements will only affect the communication within the
system and will not affect host-to-host communication.TCP provides a reliable byte stream to
the upper layer protocols. It breaks the byte stream into appropriately sized segments and
32

each segment is sent in its own IP packet. The IP packets are sent out on the network by the
network device driver. If the destination is not on the physically connected network, the IP
packet is forwarded onto another network by a router that is situated between the two
networks. If the maximum packet size of the other network is smaller than the size of the IP
packet, the packet is fragmented into smaller packets by the router. If possible, the size of the
TCP segments is chosen so that fragmentation is minimized. The final recipient of the packet
will have to reassemble any fragmented IP packets before they can be passed to higher
layers.The formal requirements for the protocols in the TCP/IP stack are specified in a
number of RFC documents published by the Internet Engineering Task Force, IETF. Each of
the protocols in the stack is defined in one more RFC documents and RFC1122 collects all
requirements and updates the previous RFCs. The RFC1122 requirements can be divided into
two categories; those that deal with the host to host communication and those that deal with
communication between the application and the networking stack. An example of the first
kind is "A TCP MUST be able to receive a TCP option in any segment" and an example of
the second kind is "There MUST be a mechanism for reporting soft TCP error conditions to
the application." A TCP/IP implementation that violates requirements of the first kind may
not be able to communicate with other TCP/IP implementations and may even lead to
network failures. Violation of the second kind of requirements will only affect the
communication within the system and will not affect host-to-host communication.In uIP, all
RFC requirements that affect host-to-host communication are implemented. However, in
order to reduce code size, we have removed certain mechanisms in the interface between the
application and the stack, such as the soft error reporting mechanism and dynamically
configurable type-of-service bits for TCP connections. Since there are only v+7ery few
applications that make use of those features they can be removed without loss of generality.

Figure 15:data flow
33

5.5 Main Control Loop:
The uIP stack can be run either as a task in a multitasking system, or as the main program in a
singlet asking system. In both cases, the main control loop does two things repeatedly:
Check if a packet has arrived from the network.
Check if a periodic timeout has occurred.
If a packet has arrived, the input handler function, uip_input(), should be invoked by the main
control loop. The input handler function will never block, but will return at once. When it
returns, the stack or the application for which the incoming packet was intended may have
produced one or more reply packets which should be sent out. If so, the network device driver
should be called to send out these packets.
Periodic timeouts are used to drive TCP mechanisms that depend on timers, such as
delayed acknowledgments, retransmissions and round-trip time estimations. When the main
control loop infers that the periodic timer should fire, it should invoke the timer handler
function uip_periodic(). Because the TCP/IP stack may perform retransmissions when
dealing with a timer event, the network device driver should called to send out the packets
that may have been produced.
1. Architecture Specific Functions:
uIP requires a few functions to be implemented specifically for the architecture on which uIP
is intended to run. These functions should be hand-tuned for the particular architecture, but
generic C implementations are given as part of the uIP distribution.
2. Application Program Interface (API):
The Application Program Interface (API) defines the way the application program interacts
with the TCP/IP stack. The most commonly used API for TCP/IP is the BSD socket API
which is used in most UNIX systems and has heavily influenced the Microsoft Windows
WinSock API. Because the socket API uses stop-and-wait semantics, it requires support from
an underlying multitasking operating system. Since the overhead of task management,
context switching and allocation of stack space for the tasks might be too high in the intended
uIP target architectures, the BSD socket interface is not suitable for our purposes.
34

uIP provides two APIs to programmers: protosockets, a BSD socket-like API without the
overhead of full multi-threading, and a "raw" event-based API that is nore low-level than
protosockets but uses less memory.
5.5.1 The uIP raw API:
The "raw" uIP API uses an event driven interface where the application is invoked in
response to certain events. An application running on top of uIP is implemented as a C
function that is called by uIP in response to certain events. uIP calls the application when data
is received, when data has been successfully delivered to the other end of the connection,
when a new connection has been set up, or when data has to be retransmitted. The application
is also periodically polled for new data. The application program provides only one callback
function; it is up to the application to deal with mapping different network services to
different ports and connections. Because the application is able to act on incoming data and
connection requests as soon as the TCP/IP stack receives the packet, low response times can
be achieved even in low-end systems.
uIP is different from other TCP/IP stacks in that it requires help from the application
when doing retransmissions. Other TCP/IP stacks buffer the transmitted data in memory until
the data is known to be successfully delivered to the remote end of the connection. If the data
needs to be retransmitted, the stack takes care of the retransmission without notifying the
application. With this approach, the data has to be buffered in memory while waiting for an
acknowledgment even if the application might be able to quickly regenerate the data if a
retransmission has to be made.
In order to reduce memory usage, uIP utilizes the fact that the application may be able to
regenerate sent data and lets the application take part in retransmissions. uIP does not keep
track of packet contents after they have been sent by the device driver, and uIP requires that
the application takes an active part in performing the retransmission. When uIP decides that a
segment should be retransmitted, it calls the application with a flag set indicating that a
retransmission is required. The application checks the retransmission flag and produces the
same data that was previously sent. From the application's standpoint, performing a
retransmission is not different from how the data originally was sent. Therefore the
application can be written in such a way that the same code is used both for sending data and
retransmitting data. Also, it is important to note that even though the actual retransmission
35

operation is carried out by the application, it is the responsibility of the stack to know when
the retransmission should be made. Thus the complexity of the application does not
necessarily increase because it takes an active part in doing retransmissions.
1. Application Events:
The application must be implemented as a C function, UIP_APPCALL (), that uIP calls
whenever an event occurs. Each event has a corresponding test function that is used to
distinguish between different events. The functions are implemented as C macros that will
evaluate to either zero or non-zero. Note that certain events can happen in conjunction with
each other (i.e., new data can arrive at the same time as data is acknowledged).
2. The Connection Pointer:
When the application is called by uIP, the global variable uip_conn is set to point to the
uip_conn structure for the connection that currently is handled, and is called the "current
connection". The fields in the uip_conn structure for the current connection can be used, e.g.,
to distinguish between different services, or to check to which IP address the connection is
connected. One typical use would be to inspect the uip_conn->lport (the local TCP port
number) to decide which service the connection should provide. For instance, an application
might decide to act as an HTTP server if the value of uip_conn->lport is equal to 80 and act
as a TELNET server if the value is 23.
3. Receiving Data:
If the uIP test function uip_newdata() is non-zero, the remote host of the connection has sent
new data. The uip_appdata pointer point to the actual data. The size of the data is obtained
through the uIP function uip_datalen().The data is not buffered by uIP, but will be
overwritten after the application function returns, and the application will therefore have to
either act directly on the incoming data, or by itself copy the incoming data into a buffer for
later processing.
4. Sending Data:
When sending data, uIP adjusts the length of the data sent by the application according to the
available buffer space and the current TCP window advertised by the receiver. The amount of
buffer space is dictated by the memory configuration. It is therefore possible that all data sent
36

from the application does not arrive at the receiver, and the application may use the
uip_mss() function to see how much data that actually will be sent by the stack.
The application sends data by using the uIP function uip_send(). The uip_send()
function takes two arguments; a pointer to the data to be sent and the length of the data. If the
application needs RAM space for producing the actual data that should be sent, the packet
buffer (pointed to by the uip_appdata pointer) can be used for this purpose.
5. Retransmitting Data:
Retransmissions are driven by the periodic TCP timer. Every time the periodic timer is
invoked, the retransmission timer for each connection is decremented. If the timer reaches
zero, a retransmission should be made. As uIP does not keep track of packet contents after
they have been sent by the device driver, uIP requires that the application takes an active part
in performing the retransmission. When uIP decides that a segment should be retransmitted,
the application function is called with the uip_rexmit() flag set, indicating that a
retransmission is required.
The application must check the uip_rexmit() flag and produce the same data that was
previously sent. From the application's standpoint, performing a retransmission is not
different from how the data originally was sent. Therefore, the application can be written in
such a way that the same code is used both for sending data and retransmitting data. Also, it
is important to note that even though the actual retransmission operation is carried out by the
application, it is the responsibility of the stack to know when the retransmission should be
made.
6. Closing Connections:
The application closes the current connection by calling the uip_close() during an application
call. This will cause the connection to be cleanly closed. In order to indicate a fatal error, the
application might want to abort the connection and does so by calling the uip_abort()
function.
If the connection has been closed by the remote end, the test function uip_closed () is
true. The application may then do any necessary cleanups.
37

7. Reporting Errors:
There are two fatal errors that can happen to a connection, either that the connection was
aborted by the remote host, or that the connection retransmitted the last data too many times
and has been aborted. uIP reports this by calling the application function.
The application can use the two test functions uip_aborted () and uip_timedout() to test
for those error conditions.
8. Polling:
When a connection is idle, uIP polls the application every time the periodic timer fires. The
application uses the test function uip_poll() to check if it is being polled by uIP.
9. Listening Ports:
uIP maintains a list of listening TCP ports. A new port is opened for listening with the
uip_listen() function. When a connection request arrives on a listening port, uIP creates a new
connection and calls the application function. The test function uip_connected () is true if the
application was invoked because a new connection was created.
10. Opening Connections:
New connections can be opened from within uIP by the function uip_connect(). This function
allocates a new connection and sets a flag in the connection state which will open a TCP
connection to the specified IP address and port the next time the connection is polled by uIP.
The uip_connect() function returns a pointer to the uip_conn structure for the new
connection. If there are no free connection slots, the function returns NULL.
The function uip_ipaddr() may be used to pack an IP address into the two element 16-bit
array used by uIP to represent IP addresses.
Two examples of usage are shown below. The first example shows how to open a
connection to TCP port 8080 of the remote end of the current connection. If there are not
enough TCP connection slots to allow a new connection to be opened, the uip_connect()
function returns NULL and the current connection is aborted by uip_abort().
11. Protocol Implementations:
The protocols in the TCP/IP protocol suite are designed in a layered fashion where each
protocol performs a specific function and the interactions between the protocol layers are
38

strictly defined. While the layered approach is a good way to design protocols, it is not
always the best way to implement them. In uIP, the protocol implementations are tightly
coupled in order to save code space.
12. IP -Internet Protocol:
When incoming packets are processed by uIP, the IP layer is the first protocol that examines
the packet. The IP layer does a few simple checks such as if the destination IP address of the
incoming packet matches any of the local IP address and verifies the IP header checksum.
Since there are no IP options that are strictly required and because they are very uncommon,
any IP options in received packets are dropped.
13. IP Fragment Reassembly:
IP fragment reassembly is implemented using a separate buffer that holds the packet to be
reassembled. An incoming fragment is copied into the right place in the buffer and a bit map
is used to keep track of which fragments have been received. Because the first byte of an IP
fragment is aligned on an 8-byte boundary, the bit map requires a small amount of memory.
When all fragments have been reassembled, the resulting IP packet is passed to the transport
layer. If all fragments have not been received within a specified time frame, the packet is
dropped.
14. ICMP --- Internet Control Message Protocol:
The ICMP protocol is used for reporting soft error conditions and for querying host
parameters. Its main use is, however, the echo mechanism which is used by the "ping"
program.
The ICMP implementation in uIP is very simple as itis restricted to only implement ICMP
echo messages. Replies to echo messages are constructed by simply swapping the source and
destination IP addresses of incoming echo requests and rewriting the ICMP header with the
Echo-Reply message type. The ICMP checksum is adjusted using standard techniques (see
RFC1624).
Since only the ICMP echo message is implemented, there is no support for Path MTU
discovery or ICMP redirect messages. Neither of these is strictly required for interoperability;
they are performance enhancement mechanisms.
39

15. TCP --- Transmission Control Protocol:
The TCP implementation in uIP is driven by incoming packets and timer events. Incoming
packets are parsed by TCP and if the packet contains data that is to be delivered to the
application, the application is invoked by the means of the application function call. If the
incoming packet acknowledges previously sent data, the connection state is updated and the
application is informed, allowing it to send out new data.
16. Listening Connections:
Allows a connection to listen for incoming connection requests. In uIP, a listening
connection is identified by the 16-bit port number and incoming connection requests are
checked against the list of listening connections. This list of listening connections is dynamic
and can be altered by the applications in the system.
17. Round-Trip Time Estimation:
TCP continuously estimates the current Round-Trip Time (RTT) of every active connection
in order to find a suitable value for the retransmission time-out.
The RTT estimation in uIP is implemented using TCP's periodic timer. Each time the
periodic timer fires, it increments a counter for each connection that has unacknowledged
data in the network. When an acknowledgment is received, the current value of the counter is
used as a sample of the RTT. The sample is used together with Van Jacobson's standard TCP
RTT estimation function to calculate an estimate of the RTT. Karn's algorithm is used to
ensure that retransmissions do not skew the estimates.
18. Retransmissions:
Retransmissions are driven by the periodic TCP timer. Every time the periodic timer is
invoked, the retransmission timer for each connection is decremented. If the timer reaches
zero, a retransmission should be made.
19. Flow Control:
The purpose of TCP's flow control mechanisms is to allow communication between hosts
with wildly varying memory dimensions. In each TCP segment, the sender of the segment
indicates its available buffer space. A TCP sender must not send more data than the buffer
space indicated by the receiver.
40

In uIP, the application cannot send more data than the receiving host can buffer. And
application cannot send more data than the amount of bytes it is allowed to send by the
receiving host. If the remote host cannot accept any data at all, the stack initiates the zero
window probing mechanism.
20. Congestion Control:
The congestion control mechanisms limit the number of simultaneous TCP segments in the
network. The algorithms used for congestion control are designed to be simple to implement
and require only a few lines of code.
Since uIP only handles one in-flight TCP segment per connection, the amount of
simultaneous segments cannot be further limited, thus the congestion control mechanisms are
not needed.
21. Urgent Data:
TCP's urgent data mechanism provides an application-to-application notification mechanism,
which can be used by an application to mark parts of the data stream as being more urgent
than the normal stream. It is up to the receiving application to interpret the meaning of the
urgent data.
In many TCP implementations, including the BSD implementation, the urgent data
feature increases the complexity of the implementation because it requires an asynchronous
notification mechanism in an otherwise synchronous API. As uIP already use an
asynchronous event based API, the implementation of the urgent data feature does not lead to
increased complexity.
22. Application Layer (HTTP Layer):
HTTP is the protocol behind the World Wide Web. With every web transaction, HTTP is
invoked. HTTP is behind every request for a web document or graphic, every click of a
hypertext link, and every submission of a form. The Web is about distributing information
over the Internet, and HTTP is the protocol used to do so.
HTTP is useful because it provides a standardized way for computers to communicate
with each other. HTTP specifies how clients request data, and how servers respond to these
requests. By understanding how HTTP works, you'll be able to:
41

1. Manually query web servers and receive low-level information that typical web
browsers hide from the user. With this information, you can better understand the
configuration and capabilities of a particular server, and debug configuration errors
with the server or programming errors in programs invoked by the web server.
2. Understand the interaction between web clients (browsers, robots, search engines,
etc.) and web servers.
3. Streamline web services to make better use of the protocol.
5.6 HTTP Transactions:
This section presents an example of a common web transaction, showing the HTTP
exchanged between the client and server program.
1. Requests:
Given the following URL:
http://hypothetical.ora.com:80/
The browser interprets the URL as follows: http://
Contact a computer over the network with the hostname of hypothetical.ora.com.80
Connect to the computer at port 80. The port number can be any legitimate IP port
number: 1 through 65535, inclusively. If the colon and port number are omitted, the port
number is assumed to be HTTP's default port number, which is 80.Anything after the
hostname and optional port number is regarded as a document path. In this example, the
document path is /.So the browser connects to hypothetical.ora.com on port 80 using the
HTTP protocol. The message that the browser sends to the server is:
GET / HTTP/1.1
Accept: image/gif, image/x-bitmap, and image/
Jpeg, image/pipe, */*
Accept-Language: en-us
Accept-Encoding: zip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE
42

5.01; Windows NT)
Host: hypothetical.ora.com
Connection: Keep-Alive

2. Responses:
Given a request like the one previously shown, the server looks for the server resource
associated with "/" and returns it to the browser, preceding it with header information in its
response. The resource associated with the URL depends on how the server is implemented.
It could be a static file or it could be dynamically generated. In this case, the server returns:
HTTP/1.1 200 OK
Date: Mon, 06 Dec 1999 20:54:26 GMT
Server: Apache/1.3.6 (UNIX)
Last-Modified: Fri, 04 Oct 1996 14:06:11 GMT
ETag: "2f5cd-964-381e1bd6"
Accept-Ranges: bytes
Content-length: 327
Connection: close
Content-type: text/html
<title>Sample Homepage</title>
<imgsrc="/images/oreilly_mast.gif">
<h1>Welcome</h1>

The new stack comes with a file called basic_web_server_example.c which is a very simple
web server example. Using this example I will explain how the web server API works.
The stack consists of the files enc28j60.c and ip_arp_udp_tcp.cThere are also the header files
enc28j60.h, ip_arp_udp_tcp.h, net, ip_config.htimeout.h. To compile the code will need the
Make file.

The file ip_config.h is used to configure the stack. If you want only a web server and no
client (=no web browser functionality) then you should undefined all client functions in the
file ip_config.h to save space. Open the file in a text editor and read the comments. I think
you will understand what to do. The eth_tcp_client_server-3.x.tar.gz file from the download
43

section of this article has client functionality enabled because that tar.gz file contains also
other examples. The compiled basic_web_server_example. Hex code is therefore a bit bigger
than it need to be because it contains unused code.

5.7 ADVANTAGES:
1. Fully automated
2. Security Management
3. Less delay
4. Highly precise
5. Low probability of breakdown
6. User friendly model
5.8 LIMITATION:
1. Dependence on the internet - The most significant limitation of the system is that it
is completely dependent on the internet for the feature of remote access. In case of
loss of internet connectivity, the user will still be able to control the home appliances
directly from the Local Server using the GUI created for it.
2. Dependence on power supply For the system to function properly, all appliances
must be connected to the main power supply at all times. If appliances are
disconnected from the main supply, they can no longer be controlled by the user &
that part of the system would be rendered non-functional.

5.9 FUTURE WORK:
By taking advantage of modern Web technologies, the proposed architecture provides
a method to develop management applications efficiently and to manage network
devices effectively. It presents and discusses architectural features, limitations,
performance and trends.


44

CHAPTER-6
6.1 RESULT:
Implemented a system for Remote Grid Automated Power Switching and Control which can
be deployed for power switching and control and also for Industrial applications where user
wishes to control devices remotely over internet. Microchips ENC28J60Ethernet controller
interfaced with Atmels At mega 16customized as a Web-Serverusing Open source TCP/IP
stack for task of power switching and control. Hardware of the system has been completed
and program simulation error is occurring and trying to resolve the errors.

6.1.1 Picture of hardware system:


Figure 16: Actual view of hardware.

45


Figure17: The atmega32 based web-server, screenshot with Mozilla Firefox.
6.2 CONCLUSION
The system for the Home Automation Network has a vast scope & almost limitless
application in todays technology driven market. The system can be made efficient by
modularising each and every component of the system hence ensuring that it can be
integrated with a varied range of devices.
Its reduced the problem of Grid failure at excellent cost performances.
These systems provide not only excellent cost performance but also running steadily
and reliably. This proposed that a method using Microchips ENC28J60 Ethernet
controller interface with Atmels Atmega 32 customized as a Web-Server using Open
source TCP/IP stack for task of power monitoring, switching and control.






46

REFERENCES
1. Takako Nonaka, Masato Shimano, Yuta Uesugi, and Tomohiro. Embedded Server
and Client System for Home Appliances on Real-Time Operating Systems.IEEE
(2010).
2. Xiaoneng Gao, Peng tong Fan. Internet Access Technology Based on the Embedded
Devices. IEEE (2011).
3. Yong-tao ZHOU, Xiao-hu CHEN, XU-ping WANG, Chun-jiang YAO. Design of
Equipment Remote Monitoring System based on Embedded Web, IEEE (2008).
4. http://www.homeautomationinfo.com/Drupal/technology_x10
5. Programming and Customizing the AVR Microcontroller
a. ByDhananjay V. Gadre IEEE
6. FangHong ping, Fang KangLing,The Design of Remote Embedded Monitoring
System based on Internet, 2010 International conference on Measuring Technology
and Automation
2. 7. I. Klimchynski. Extensible embedded web server for internet-based data
acquisition and control, in proceedings of IEEE Sensors, Vol. 6, issue: 3, 2006,
pp.804-811
7. Lixia Liu, Research on Technology of Embedded Web Server Application IEEE,
2005
8. Tao Lin, Hai Zhao, an Embedded Web Server for Equipment, IEEE, 2004
9. Embedded web Server Modules. Company information of SSV Embedded System.
10. Adam Dunkels, project scientist, Swedish institute of computer sciences, UIP1.0-
TCP/IP stack for low computing embedded devices
11. Cirrus Logic Product Data Sheet, Crystal LANTM ISA Ethernet Controller.
12. Bettstetter C, Renner C. A Comparison of Service Discovery Protocols and
Implementation of the Service
1. 13.Location Protocol, in Proceedings EUNICE 2000.
2. Borriello G, Want R. Embedded computation meets the world wide web.
Commun ACM 2000:5966.
3. 1Dong-Sung K, Jae-Min L, Wook HK. In: Kwan Y, editor. Design and
implementation of home network systems
4. using UPnP middleware for networked appliances. IEEE transactions on
consumer Electronics, 2002.
5. p. 96372.
6. Ethernet Hardware Manual. URL: http://www.ethernut.de/
7. HAVi: Home Audio/Video Interoperability URL: http://www.havi.org
8. Jini Community. URL: http://www.jini.org
47

9. Nakajima T. Experiences with building middleware for audio and visual
networked home appliances on
10. commodity software. ACM Multimedia, 2002.
11. Nichols J, Myers B. Studying the use of handhelds to control smart appliances.
ICDCS03, 2003.
12. p. 27479.
13. Nichols J, Myers B, Higgins M, Hughes J, Harris T, Rosenfeld R, et al. Generating
remote control interfaces
14. for complex appliances. Symposium on User Interface Software and Technology
of the ACM, 2002.
15. p. 16170.
16. Olsen Jr DR, Jefferies S, Nielsen T, Moyes W, Fredrickson P. Cross model
interaction using XWeb. In:
17. Proceedings UIST00: ACM SIGGRAPH symposium on user interface software and
technology, San Diego,
18. CA, 2000. p. 191200.
19. Pascoe B, Salutation Architectures and the newly defined service protocols from
Microsoft and Sun, Salutation
20. Consortium, June 1999.
21. Ponnekanti SR, Lee B, Fox A, Hanrahan P, Winograd T. ICrafter: a service
framework for ubiquitous computing
22. environments. UBICOMP Atlanta, 2001. p. 5675.
23. Rekesh J. UPnP, Jini and Salutationa look at some popular coordination
frameworks for future networked
24. devices, California Software Labs, Technical Report, 1999.