Updated Reportd

7/27/2019 Updated Reportd

1/48

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 ofone anothers services and functions while improving the user interfaces. The main benefits

of this approach include its lightweight design, automatic configuration, and utilization of

widely available and tested network protocols of TCP/IP and HTTP. The validity of the

approach has been verified 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.


2/48

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 fit 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 computersof 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


3/48

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 othersservices 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


4/48

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 needof 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.


5/48

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 differentapproaches.

2. GSM-SMS protocols using GSM module individually or in combination with InternetTechnologies.

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.


6/48

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 networkconsisting 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.


7/48

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).


8/48

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


9/48

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 thismodel, 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


10/48

9

a) Layer 1: Physical LayerThePhysical Layer defineselectrical 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 ofpins,voltages,cable specifications,hubs,repeaters,

network adapters,host bus adapters (HBA used instorage area networks)and more.

The major functions and services performed by the Physical Layer are:

1. Establishment and termination of aconnection to a communications medium.2. Participation in the process whereby the communication resources are effectively

shared among multiple users. For example,contention resolution andflow control.

3.

Modulation,or conversion between the representation ofdigital data in userequipment and the corresponding signals transmitted over a communicationschannel.

These are signals operating over the physical cabling (such as copper and optical fibre)or

over a link. Parallelbuses operate in this layer, although it must be remembered that the logical

SCSIprotocol 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 LayerTheData Link Layerprovides 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 inIEEE 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 asPoint-to-Point Protocol (PPP), and,

on local area networks, the IEEE 802.2 LLC layer is not used for most protocols on the
http://en.wikipedia.org/wiki/Physical_Layerhttp://en.wikipedia.org/wiki/Electricalhttp://en.wikipedia.org/wiki/Transmission_mediumhttp://en.wikipedia.org/wiki/Lead_%28electronics%29http://en.wikipedia.org/wiki/Voltagehttp://en.wikipedia.org/wiki/Network_hubhttp://en.wikipedia.org/wiki/Repeaterhttp://en.wikipedia.org/wiki/Network_cardhttp://en.wikipedia.org/wiki/Host_adapterhttp://en.wikipedia.org/wiki/Storage_area_networkhttp://en.wikipedia.org/wiki/Electrical_connectorhttp://en.wikipedia.org/wiki/Contention_%28computer_networking%29http://en.wikipedia.org/wiki/Flow_controlhttp://en.wikipedia.org/wiki/Modulationhttp://en.wikipedia.org/wiki/Digital_datahttp://en.wikipedia.org/wiki/Channel_%28communications%29http://en.wikipedia.org/wiki/Optical_fiberhttp://en.wikipedia.org/wiki/SCSIhttp://en.wikipedia.org/wiki/IBM_token_ringhttp://en.wikipedia.org/wiki/Fiber_distributed_data_interfacehttp://en.wikipedia.org/wiki/ITU-Thttp://en.wikipedia.org/wiki/ITU-Thttp://en.wikipedia.org/wiki/G.hnhttp://en.wikipedia.org/wiki/IEEE_802.11http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/IEEE_802.15#Task_group_4_.28Low_Rate_WPAN.29http://en.wikipedia.org/wiki/IEEE_802.15#Task_group_4_.28Low_Rate_WPAN.29http://en.wikipedia.org/wiki/Data_Link_Layerhttp://en.wikipedia.org/wiki/IEEE_802http://en.wikipedia.org/wiki/Point-to-Point_Protocolhttp://en.wikipedia.org/wiki/Logical_Link_Controlhttp://en.wikipedia.org/wiki/Logical_Link_Controlhttp://en.wikipedia.org/wiki/Point-to-Point_Protocolhttp://en.wikipedia.org/wiki/IEEE_802http://en.wikipedia.org/wiki/Data_Link_Layerhttp://en.wikipedia.org/wiki/IEEE_802.15#Task_group_4_.28Low_Rate_WPAN.29http://en.wikipedia.org/wiki/IEEE_802.15#Task_group_4_.28Low_Rate_WPAN.29http://en.wikipedia.org/wiki/Bluetoothhttp://en.wikipedia.org/wiki/IEEE_802.11http://en.wikipedia.org/wiki/G.hnhttp://en.wikipedia.org/wiki/ITU-Thttp://en.wikipedia.org/wiki/ITU-Thttp://en.wikipedia.org/wiki/Fiber_distributed_data_interfacehttp://en.wikipedia.org/wiki/IBM_token_ringhttp://en.wikipedia.org/wiki/SCSIhttp://en.wikipedia.org/wiki/Optical_fiberhttp://en.wikipedia.org/wiki/Channel_%28communications%29http://en.wikipedia.org/wiki/Digital_datahttp://en.wikipedia.org/wiki/Modulationhttp://en.wikipedia.org/wiki/Flow_controlhttp://en.wikipedia.org/wiki/Contention_%28computer_networking%29http://en.wikipedia.org/wiki/Electrical_connectorhttp://en.wikipedia.org/wiki/Storage_area_networkhttp://en.wikipedia.org/wiki/Host_adapterhttp://en.wikipedia.org/wiki/Network_cardhttp://en.wikipedia.org/wiki/Repeaterhttp://en.wikipedia.org/wiki/Network_hubhttp://en.wikipedia.org/wiki/Voltagehttp://en.wikipedia.org/wiki/Lead_%28electronics%29http://en.wikipedia.org/wiki/Transmission_mediumhttp://en.wikipedia.org/wiki/Electricalhttp://en.wikipedia.org/wiki/Physical_Layer


11/48

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 asTCP,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 LayerThe Network Layer provides the functional and procedural means of transferring variable

lengthdata 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 atransit network up to the level of networks on either side;

3.

Sub network Independent Convergence - which handles transfer across multiplenetworks?

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 toingress 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.
http://en.wikipedia.org/wiki/Transmission_Control_Protocolhttp://en.wikipedia.org/wiki/X.25http://en.wikipedia.org/wiki/ITU-Thttp://en.wikipedia.org/wiki/Data_Link_Layerhttp://en.wikipedia.org/wiki/Network_Layerhttp://en.wikipedia.org/wiki/Datahttp://en.wikipedia.org/wiki/Quality_of_servicehttp://en.wikipedia.org/wiki/Routinghttp://en.wikipedia.org/wiki/Routerhttp://en.wikipedia.org/wiki/Connectionless_protocolhttp://en.wikipedia.org/wiki/Ingress_routerhttp://en.wikipedia.org/wiki/Egress_routerhttp://en.wikipedia.org/wiki/Egress_routerhttp://en.wikipedia.org/wiki/Ingress_routerhttp://en.wikipedia.org/wiki/Connectionless_protocolhttp://en.wikipedia.org/wiki/Routerhttp://en.wikipedia.org/wiki/Routinghttp://en.wikipedia.org/wiki/Quality_of_servicehttp://en.wikipedia.org/wiki/Datahttp://en.wikipedia.org/wiki/Network_Layerhttp://en.wikipedia.org/wiki/Data_Link_Layerhttp://en.wikipedia.org/wiki/ITU-Thttp://en.wikipedia.org/wiki/ITU-Thttp://en.wikipedia.org/wiki/X.25http://en.wikipedia.org/wiki/Transmission_Control_Protocol


12/48

11

d) Layer 4: Transport LayerThe 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 TransmissionControl Protocol (TCP) and User Datagram Protocol (UDP).

Table 2: OSI Protocol

Fig OSI Model with Protocols
http://en.wikipedia.org/wiki/Transport_Layerhttp://en.wikipedia.org/wiki/Transport_Layer


13/48

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.
http://www.tuxgraphics.org/electronics/200606/article06061.shtmlhttp://www.tuxgraphics.org/electronics/200606/article06061.shtmlhttp://www.tuxgraphics.org/electronics/200606/article06061.shtmlhttp://www.tuxgraphics.org/electronics/200606/article06061.shtml


14/48

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 LEDsor switches.

5. Having option to provide DC supply using 2.5 mm DC jack or wires.


15/48

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 allowsthe 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


16/48

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 buffermemory 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 controller2. Integrated MAC and 10BASE-T PHY3. Receiver and collision squelch circuit4. Supports one 10BASE-T port with automatic polarity detection and correction5. Supports Full and Half-Duplex modes6. Programmable automatic retransmit on collision7. Programmable padding and CRC generation8. Programmable automatic rejection of erroneous packets9. 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 pins3. 25MHz clock


17/48

16

4. Clock out pin with programmable pre-scalar5. Operating voltage range of 3.14V to 3.45V6. TTL level inputs7. 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 fromembedded 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
http://www.embeddedmarket.com/http://www.embeddedmarket.com/


18/48

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
http://ip.addr.you.assigned/secrethttp://ip.addr.you.assigned/secret


19/48

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 writtenby Adam Dunkells and later on itwas ported for AVR by Pascal Stang from Procyon engineering under AVRlib project.

1. Instruction set:

TheAVR instruction set is moreorthogonal than those of most eight-bit microcontrollers, in

particular the8051 clones andPIC microcontrollers with which AVR competes today.

However, it is not completely regular.

2. Program Execution:

AVRs have a two stage, single levelpipeline 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 amongeight-bit microcontrollers.The AVR

processors were designed with the efficient execution ofcompiledC 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, andnew APIs for Power Reduction and Clock Pre-scalar.
http://en.wikipedia.org/wiki/Atmel_AVR_instruction_sethttp://en.wikipedia.org/wiki/Orthogonal_instruction_sethttp://en.wikipedia.org/wiki/Intel_8051http://en.wikipedia.org/wiki/PIC_microcontrollerhttp://en.wikipedia.org/wiki/Pipeline_(computing)http://en.wikipedia.org/wiki/Eight-bithttp://en.wikipedia.org/wiki/Compilerhttp://en.wikipedia.org/wiki/C_(programming_language)http://en.wikipedia.org/wiki/C_(programming_language)http://en.wikipedia.org/wiki/Compilerhttp://en.wikipedia.org/wiki/Eight-bithttp://en.wikipedia.org/wiki/Pipeline_(computing)http://en.wikipedia.org/wiki/PIC_microcontrollerhttp://en.wikipedia.org/wiki/Intel_8051http://en.wikipedia.org/wiki/Orthogonal_instruction_sethttp://en.wikipedia.org/wiki/Atmel_AVR_instruction_set


20/48

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. Compilers2. Assembler3. Linker4. Librarian5. C Library6. Debugger7.

In-Circuit Emulator software

8. Editor / IDE9. 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


21/48

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

#include

#include

#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};


22/48

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(""));

plen=fill_tcp_data_p(buf,plen,PSTR("Hi!\nYour web server works great."));

plen=fill_tcp_data_p(buf,plen,PSTR("\n"));

return(plen);

}

intmain(void){

uint16_t dat_p;

// set the clock speed

CLKPR=(1


23/48

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 ();


24/48

23

dat_p=fill_tcp_data_p(buf,dat_p,

PSTR ("200 OK"));

\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\n401 Unauthorized"));

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 MACaddress of this device.

2. The MAC address has be unique in your own LAN your neighbor could re-use thesame numbers.

3. Let's jump to lines 41-51. Here the hardware and Ethernet layer is initialized.


25/48

24

4. You don't have to change anything. Line 54 initializes the actual web server TCP/IPstack 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:

Hi!

Your web server works great.


26/48

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 coilIf 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.


27/48

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


28/48

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 allsmall 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 handlingfor 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.
http://www.tuxgraphics.org/electronics/200611/article06111_tcpstates.htmlhttp://www.tuxgraphics.org/electronics/200611/article06111_tcpstates.htmlhttp://www.tuxgraphics.org/electronics/200611/article06111.shtmlhttp://www.tuxgraphics.org/electronics/200611/article06111_tcpstates.htmlhttp://www.tuxgraphics.org/electronics/200611/article06111_tcpstates.htmlhttp://www.tuxgraphics.org/electronics/200611/article06111.shtmlhttp://www.tuxgraphics.org/electronics/200611/article06111_tcpstates.htmlhttp://www.tuxgraphics.org/electronics/200611/article06111_tcpstates.html


29/48

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.


30/48

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


31/48

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


32/48

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. TheIP 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


33/48

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


34/48

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.


35/48

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


36/48

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->lportis 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 toeither 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


37/48

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.


38/48

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


39/48

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 anddestination 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.


40/48

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 theincoming 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.


41/48

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 arenot 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:


42/48

41

1. Manually query web servers and receive low-level information that typical webbrowsers 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


43/48

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 OKDate: 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

Sample Homepage

Welcome

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


44/48

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 automated2. Security Management3. Less delay4. Highly precise5. Low probability of breakdown6. User friendly model

5.8 LIMITATION:

1. Dependence on the internet- The most significant limitation of the system is that itis 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 supplyFor the system to function properly, all appliancesmust 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.


45/48

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.


46/48

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 limitlessapplication 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.


47/48

46

REFERENCES

1. Takako Nonaka, Masato Shimano, Yuta Uesugi, and Tomohiro. Embedded Serverand Client System for Home Appliances on Real-Time Operating Systems.IEEE

(2010).

2. Xiaoneng Gao, Peng tong Fan. Internet Access Technology Based on the EmbeddedDevices. IEEE (2011).

3. Yong-tao ZHOU, Xiao-hu CHEN, XU-ping WANG, Chun-jiang YAO. Design ofEquipment Remote Monitoring System based on Embedded Web, IEEE (2008).

4. http://www.homeautomationinfo.com/Drupal/technology_x105. Programming and Customizing the AVR Microcontroller

a. ByDhananjay V. Gadre IEEE6. FangHong ping, Fang KangLing,The Design of Remote Embedded Monitoring

System based on Internet, 2010 International conference onMeasuring Technology

and Automation

2. 7. I. Klimchynski. Extensible embedded web server for internet-based dataacquisition 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, 20049. 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 andimplementation of home network systems

4. using UPnP middleware for networked appliances. IEEE transactions onconsumer Electronics, 2002.

5. p. 96372.6. Ethernet Hardware Manual. URL: http://www.ethernut.de/7. HAVi: Home Audio/Video Interoperability URL: http://www.havi.org8. Jini Community. URL: http://www.jini.org


48/48

9. Nakajima T. Experiences with building middleware for audio and visualnetworked 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 Technologyof 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 andtechnology, 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.

Documents

Updated Reportd