23521348 Remote AC Controlling Through Embedded Web Server

AC Controlling through embedded web server

1 Index1 Index ...................................................................................................................................................... 1

2 Introduction ............................................................................................................................................ 2

3 Block Diagram: ....................................................................................................................................... 3

4 Description (working Procedure) ............................................................................................................ 6

5 Components Involved (hard ware) ......................................................................................................... 9

5.1 AVR ATMega128: .......................................................................................................................... 18

5.2 LM35 temperature sensor .............................................................................................................. 21

5.3 RTC (DS1307) ............................................................................................................................... 24

5.4 LCD (HD44780U) .......................................................................................................................... 27

5.5 LED ............................................................................................................................................... 31

5.6 Motor Driver(L293D) ...................................................................................................................... 33

5.7 ENC28J60 Ethernet interface card ................................................................................................ 36

5.8 Extra .............................................................................................................................................. 41

5.8.1 SPI Bus ................................................................................................................................... 41

5.8.2 I2C Bus ................................................................................................................................... 45

5.8.3 Rj45 Network cable ................................................................................................................. 49

6 Components Involved (software) .......................................................................................................... 51

6.1 WINAVR(avr-gcc) .......................................................................................................................... 51

6.2 AVR STUDIO 4.14 ......................................................................................................................... 52

6.3 Micro IP(µIP) TCP/IP Protocol suit ................................................................................................. 54

6.3.1 TCP/IP Communication ........................................................................................................... 55

6.3.2 Main Control Loop ................................................................................................................... 56

6.3.3 Architecture Specific Functions ............................................................................................... 57

6.3.4 Application Program Interface (API) ........................................................................................ 57

6.3.5 Protocol Implementations ........................................................................................................ 61

6.3.6 Application Layer (HTTP Layer) .............................................................................................. 65

6.4 HTML ............................................................................................................................................ 67

7 Future Enhancements .......................................................................................................................... 68

8 Bibliography ......................................................................................................................................... 69

8.1.1 Books and Journals: ............................................................................................................... 69

8.1.2 Reference links: ...................................................................................................................... 70

CDAC-DESD of 72 02/12/2009


2 IntroductionPowerful microcontrollers are used as parts of most home and office appliances of today.

Integrating web servers to these intelligent devices will aid in controlling such devices over the

Internet and also creating user interfaces for them in the form of web pages. Assigning multiple

functionalities to a single button help manufacturers economize user interfaces but, this makes

them more complicated. 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 project is to control the Remote AC with an internet enabled device. This controlling

system has various features like start and stop time, upper and lower limit of temperature and

holiday controlling. HTTP protocol is implemented on the top of uip (micro-ip) for Ethernet

communication and AVR microcontroller is used for accessing and processing the data.

CDAC-DESD of 72 02/12/2009


3 Block Diagram:

The block diagram shows the all the components involved in the project,

The AVR (uniboard) kit is connected by LM35 temperature sensor.

LED’s for condenser on off representation.

DC motor for AC on off.

Ethernet interface card for interface the AVR kit to internet.

CDAC-DESD of 72 02/12/2009


From user point of view, when we enter the site address as www.192.168.72.12/index.html then it will

open the index page. In that we will get the current info regarding current temperature and the

temperature lower and upper limits, those are shown in the figure

CDAC-DESD of 72 02/12/2009

http://www.192.168.72.12/index.html


The browser is currently showing the current date and time, and the holidy and temp limits , start

and stop times. If you enter the username and password and press login, this will show the page

as

Once you fill the form, and submit then it will update the values into the web server. And the

holiday will be added to the holiday table, and the temperature limits will be changed according to new

values.

CDAC-DESD of 72 02/12/2009


4 Description (working Procedure)Flow chart:

CDAC-DESD of 72 02/12/2009


CDAC-DESD of 72 02/12/2009


1. When the system is started, all the components like- Uip, RTC, Ports, Holiday list,

variables, etc. are initialized.

2. RTC gives the Current date.

3. Check whether today is Holiday or not.

4. If it is Holiday then, go to step 15.

5. If it’s not a holiday then, the Current time is checked with the help of RTC.

6. After this, Flag is checked.

7. If Flag is Set, user can make changes as per the requirement.

8. If flag is not set then, check Current time.

9. If current time is ON_TIME, then check whether AC is ON or not.

10. If AC is not ON, turn ON the AC.

11. After turning on the AC, sense the Temperature with the help of Temperature Sensor.

12. Now check Temperature Limits.

13. If Current temperature is more than Temperature Upper Limit, then turn ON the

Condenser.

14. If Current temperature is less than Temperature Lower Limit, then turn OFF Condenser.

15. Check whether Packet is available or not.

16. If Packet is available then, read the packet.

17. Decode the data received from the packet.

18. Now update the variables like- Add holiday, Temperature Upper limit, Temperature

Lower limit, On time, Off time, etc.

19. After updating the variables, send the Reply.

20. Again go to step 2.

CDAC-DESD of 72 02/12/2009


5 Components Involved (hard ware)

The board we are using in this project is the UNIBOARD.

The uNiBoard version 1.1 is an ideal open source development platform for Embedded

and Real Time Systems Programming. It is powered by a RISC machine (ATMega128) that

provides a throughput of 16 MIPS and up to 128KB of internal storage (flash), the board would

be suitable for any sort of embedded application development.

Onboard peripherals like the communication ports (RS232) and the Gtkterm driver

(hyperterminal for Windows) make the board apt for various projects development in an

Embedded (nonOS) as well as OS based environment. RT Kernels with small footprint (uC /OS

II, Free RTOS, nut OS) can be ported on the board to gain hands on experience of Real time

application design.

The board is powered by the USB port. The board is also programmable through USB

port thereby making it complete stand alone lab equipment needing nothing apart from a basic

PC/laptop to get started with the development process. The open interface (open LED interface,

open ports) extend the platform’s role for prototyping applications like external device/sensor

interfacing. The controller by itself supports protocols like SPI, I2C (on board I2C based RTC),

UART (dual

programmable UART) which can be used for multi board communication.

Additionally, the board also features an onboard motor driver which allows to control

up to two DC motors bidirectional. External supply, if required for the motors can be provided

with appropriate hardware configuration settings.

Kit Contents:

• UNiBoard development board – 1 unit

• 16x2 LCD – 1 unit

• Serial cable (DB9) – 1 unit

• USB cable – 1 unit

• FRC connector cables – 2 units

CDAC-DESD of 72 02/12/2009


Board Features:

• ATmega128 controller with external crystal of 16MHZ

• usbasp: ATmega8 based USB programmer for ATmega128 (open source firmware running on

hardware licensed under GNU GPLv2

• I2C communication lines

• SPI communication lines

• 16x2 alphanumeric LCD with contrast adjustment

• RTC with Backup Battery

• Analog Joystick with centre click

• LDR sensor

• Buzzer (beneath the processor board)

• Onboard Motor Driver (L293D)

• LEDs for USB programmer ready indicator, Programming status indicator, and Power ON

indicator

• Test LEDs (open for interface with any PORT)

• Open interface Ports such as PORTF/ADC, PORTC

• JTAG interface(External JTAG hardware required)

• USB Port for programming the Board

• Dual programmable UARTs

• Push Buttons for External Interrupts, Reset

• Configuration Switches for USB Power/External power, External ADC /Joystick and Program

Enable/UART0

• Modular design to permit replacement of processor board

CDAC-DESD of 72 02/12/2009


KIT IMAGE:

Description Of Board:The uNiBoard version 1.1 connects to the PC using USB port. As shown in the figure

1.1 on the board there is a serial port and USB port connectors. The serial port is used for

debugging purpose while USB port is used for power and burning the hex files into

ATmega128 microcontroller.

CDAC-DESD of 72 02/12/2009


The USB cable (for power/programming purposes) and serial cable can be interfaced

with the PC. The serial cable is optional as we are not using it for programming the hex file into

the Atmega128 chip. For any UART related activities having the serial cable is a must.

Atmega128 controllerThe ATmega128 is a low power 8 bit microcontroller based on the AVR enhanced RISC

architecture. The Atmel ATmega128 is a powerful microcontroller that provides a highly

flexible and cost effective solution to many embedded control applications.

Atmega8 controller with the firmware for programming through USB

USBasp is a USB in circuit programmer for Atmel AVR controllers. It simply consists of an

ATMega8 and a couple of passive components. The programmer uses a firmware (USB driver)

to program Atmega128 microcontroller. It is an open source firmware along with hardware

licensed under GNU GPLv2.

I2C and RTC (DS1307) with Backup Battery:

The DS1307 serial real time clock (RTC) is a low power, full binary coded decimal (BCD)

clock/calendar plus 56 bytes of NV SRAM. Address and data are transferred serially through

an I2C, bidirectional bus. The clock/calendar provides seconds, minutes, hours, day, date,

month, and year information (Compensation Valid up to 2100). No special hardware

configuration is required as it is mounted on our board and internally connected to the

processors pins.

CDAC-DESD of 72 02/12/2009


Analogy sensors (LDR)The LDR sensor is connected to channel 0(PF0) of the Atmega128 microcontroller.

External powerThe external power connector in the above figure can also be used for connecting rechargeable

batteries and making the board operate on battery power in case of robotic or other such mobile

applications.

Onboard Motor DriverThe Motor driver chip (L293D) is used to drive the motors which can be connected to the PTR

connectors as shown in the above figure. Through software you need to configure as follows:

• PB6 and PB5 (Motor1)

• PE2 and PE3 (Motor2)

CDAC-DESD of 72 02/12/2009


• PB4 (Chip Enable)

There are motors which might need higher than 5V (up to 12V) operating voltage. In such

cases an external supply can be given to the board and the USB power switch can be toggled to

make the external supply available instead of a USB powered connection.

Test LEDsTest LED's are pulled up so to glow the LEDs we need to make the particular port pin Low.

You can connect the General Purpose Port to test LED using FRC Cable.

Two UART's• UART1 is used to connect PC through the MAX232 voltage converter chip since pc

uses RS 232 standard for serial port. UART1 can be used for debugging the code or for

any sort of interaction with Gtkterm.

• UART0 is not connected to MAX232 as it is left open for communication between two

Boards.

LCDLCD for uNiBoard is using 4 data lines, 2 control lines and WR of LCD is connected to GND.

• Data Lines (PA4, PA5, PA6, PA7)

• Control Lines (PA0 for RS, PA2 for LCD EN)

CDAC-DESD of 72 02/12/2009


Selection Switches• USB Power (Pressed) / External power (Depressed)

• Joystick (Pressed) / External ADC (Depressed)

• Program Enable (Pressed) / UART0 (Depressed)

General Purpose Ports

• PORTC

PORTC is an open interface port which can be used to connect any devices on FRC connector.

• PORTF

PORTF can be used to connect external analog or digital sensors or it can also be used as LDR

ADC channels. There are two connectors FRC connector and Berg sensor port connector either

of which can be used to connect the external sensors.

• PORTG

PORTG is an open interface port which can be used to connect any devices on berg connector.

• PORTC and PORT F

The PORTC and PORTF (ADC) are open ports and can be connected to test LEDs through

FRC cable. These can be accessed using 10 pin the FRC connector.

MOTOR DRIVER SECTION:

CDAC-DESD of 72 02/12/2009


PIN DIAGRAM:

PORTSThe LEDS are connected to one of the general purpose port (PORTC) available of the

ATmega128. These LEDs are connected using the FRC cable. The open FRC connectors are

given on the UNiBoard so that their status can be monitored by interfacing them to LEDs using

the FRC cable.

LCDThe LCD can be used as an output device and can be placed on the uNiBoard LCD connector.

The hardware connections are as follows:

• LCD control lines Enable (PD2)

CDAC-DESD of 72 02/12/2009


• R/~W (Hardwired GND)

• RS (PD0)

• LCD data lines (PD4 – PD7).

Therefore LCD is initialized using 4 line mode.

The given LCD library contains the API’s for printing character, string, values (decimal) on

LCD, changing the LCD positions, clearing the LCD screen.

SPIThere are two programs given for SPI, one for Master and another for Slave. You can

communicate between two UNiBoard by connecting wires on SPI lines and making GND

common of both the boards. The Output is debugged using the serial terminal whatever

character typed on master’s serial terminal is transferred to the slave’s serial terminal using

SPI. Make sure you have connected the SPI lines and the GND points of the master and slave

correctly as follows:

I2C (RTC)The DS1307 is the RTC (Real Time Clock) chip interfaced on the I2C lines of the controller.

The API’s can be used for reading the date and time from RTC. Before reading you need to call

this API Update_RTC_variables() which actually updates local variables that data and time

API’s returns. You can also set date and time for RTC using Write_RTC() API and date and

time values for writing to RTC registers are taken from RTC_def_cfg.h.

CDAC-DESD of 72 02/12/2009


5.1 AVR ATMega128:The ATmega128 is a low-power CMOS 8-bit microcontroller based on the AVR enhanced RISCarchitecture. By executing powerful instructions in a single clock cycle, the ATmega128achieves throughputs approaching 1 MIPS per MHz allowing the system designer to optimizepower consumption versus processing speed.

Features:

• Advanced RISC Architecture

• 128K Bytes of In System Self programmable Flash program memory

• 4K Bytes EEPROM

• 4K Bytes Internal SRAM

• JTAG (IEEE std. 1149.1 Compliant) Interface

• Two 8 bit Timer/Counters with Separate pre scaler and Compare Modes

• Two Expanded 16 bit Timer/Counters with Separate pre scaler, Compare Mode and Capture

Mode

• Real Time Counter with Separate Oscillator

• Two 8 bit PWM Channels

• 6 PWM Channels with Programmable Resolution from 2 to 16 Bits

• 8 channel, 10 bit ADC

• Byte oriented Two wire Serial Interface

• Dual Programmable Serial USARTs

• Master/Slave SPI Serial Interface

• Programmable Watchdog Timer with On chip Oscillator

• Power on Reset and Programmable Brown out Detection

• External and Internal Interrupt Sources

• Six Sleep Modes: Idle, ADC Noise Reduction, Power save, Power down, Standby, and

Extended Standby

• Software Selectable Clock Frequency (using Fuse bits)

• 53 Programmable I/O Lines

• 4.5V 5.5V for Atmega128 Operating Voltages

CDAC-DESD of 72 02/12/2009


• 64 lead TQFP

Block diagram:

ABSOLUTE MAXIMUM RATINGS:Sr. No. Description Ratings1 Operating Temperature -55 to +125 °C

CDAC-DESD of 72 02/12/2009


2 Storage Temperature -65 to +150 °C3

Voltage on any Pin except with respect to Ground-0.5 to Vcc+0.5 V

4Voltage on with respect to Ground

-0.5 to +13.0 V

5 Maximum Operating Voltage 6.0 V6 DC Current per I/O Pin 40.0 mA7 DC Current Vcc and GND Pins 200.0 – 400.0 mA

PIN DIAGRAM:

CDAC-DESD of 72 02/12/2009


For pin description and more info see the datasheet of ATMega128

5.2 LM35 temperature sensor

An analog temperature sensor is pretty easy to explain, its a chip that tells you what the ambient

temperature is!

These sensors use a solid-state technique to determine the temperature. That is to say, they dont

use mercury (like old thermometers), bimetallic strips (like in some home thermometers or

stoves), nor do they use thermostats (temperature sensitive resistors). Instead, they use the fact

as temperature increases, the voltage across a diode increases at a known rate. (Technically, this

is actually the voltage drop between the base and emitter - the Vibe - of a transistor. By

precisely amplifying the voltage change, it is easy to generate an analog signal that is directly

proportional to temperature. There have been some improvements on the technique but,

essentially that is how temperature is measured.

Because these sensors have no moving parts, they are precise, never wear out, don't need

calibration, work under many environmental conditions, and are consistent between sensors

and readings. Moreover they are very inexpensive and quite easy to use

Pin Layout:

CDAC-DESD of 72 02/12/2009


Features:

• Calibrated directly in ° Celsius (Centigrade)

• Linear + 10.0 mV/°C scale factor

• 0.5°C accuracy guarantee able (at +25°C)

• Rated for full -55° to +150°C range

• Suitable for remote applications

• Low cost due to wafer-level trimming

• Operates from 4 to 30 volts

• Less than 60 µA current drain

PARAMETERS VALUES

Temperature Accuracy (+/-) 1, 0.5 deg C

Supply Min 4 Volt

Quiescent Current_ 56 uA

Temperature Min -40, 0, -55 deg C

Temperature Max 100, 110, 150 deg C

Sensor Gain 10 mV/Deg C

Supply Max 30 Volt

Single Supply No

CDAC-DESD of 72 02/12/2009


Output Impedance 0.4 Ohm

Quiescent Current 0.056 mA

Automotive Selection Guide Yes

Typical Performance:

Description:

It can be used to measure temperature with accuracy of 0.5 degree centigrade. We can

interface it easily with AVR MCUs and can create thermometers, temperature controller, fire

alarms etc. LM35 by National Semiconductor is a popular and low cost temperature sensor. It

is also easily available.

It has three pins as follows: The Vcc can be from 4V to 20V as specified by the

datasheet. To use the sensor simply connect the Vcc to 5V ,GND to Gnd and the Out to one of

the ADC (analog to digital converter channel). The output linearly varies with temperature. The

output is 10MilliVolts per degree centigrade. So if the output is 310 mV then temperature is

31 degree C.

CDAC-DESD of 72 02/12/2009


The LM35 series are precision integrated-circuit temperature sensors, whose output

voltage is linearly proportional to the Celsius (Centigrade) temperature. The LM35 thus has an

advantage over linear temperature sensors calibrated in ° Kelvin, as the user is not required to

subtract a large constant voltage from its output to obtain convenient Centigrade scaling. The

LM35 does not require any external calibration or trimming to provide typical accuracies of

±¼°C at room temperature and ±¾°C over a full -55 to +150°C temperature range. Low cost is

assured by trimming and calibration at the wafer level. The LM35's low output impedance,

linear output, and precise inherent calibration make interfacing to readout or control circuitry

especially easy.

5.3 RTC (DS1307)The DS1307 serial real-time clock (RTC) is a low-power, full binary-coded decimal (BCD)

clock/calendar plus 56 bytes of NV SRAM. Address and data are transferred serially through

an I2C, bidirectional bus. The clock/calendar provides seconds, minutes, hours, day, date,

month, and year information. The end of the

month date is automatically adjusted for months with fewer than 31 days, including corrections

for

leap year. The clock operates in either the 24- hour or 12-hour format with AM/PM indicator.

The DS1307 has a built-in power-sense circuit that detects power failures and automatically

switches to the backup supply. Timekeeping operation continues while the part operates from

the backup supply.

FEATURES Real-Time Clock (RTC) Counts Seconds,Minutes, Hours, Date of the Month, Month,

Day of the week, and Year with Leap-Year

Compensation Valid Up to 2100

56-Byte, Battery-Backed, Nonvolatile (NV) RAM for Data Storage

CDAC-DESD of 72 02/12/2009


I2C Serial Interface

Programmable Square-Wave Output Signal

Automatic Power-Fail Detect and Switch Circuitry

Consumes Less than 500nA in Battery-Backup Mode with Oscillator Running

Pin Configurations:

Block Diagram :

CDAC-DESD of 72 02/12/2009


Description:The DS1307 is a low-power clock/calendar with 56 bytes of battery-backed SRAM. The

clock/calendar provides seconds, minutes, hours, day, date, month, and year information. The

date at the end of the month is automatically adjusted for months with fewer than 31 days,

including corrections for leap year.

The DS1307 operates as a slave device on the I2C bus. Access is obtained by implementing a

START condition and providing a device identification code followed by a register address.

Subsequent registers can be accessed sequentially until a STOP condition is executed. When

VCC falls below 1.25 x VBAT, the device terminates an access in progress and resets the

device address counter. Inputs to the device will not be recognized at this time to prevent

erroneous data from being written to the device from an out-oftolerance system. When VCC

falls below VBAT, the device switches into a low-current battery-backup mode. Upon power-

up, the device switches from battery to VCC when VCC is greater than VBAT +0.2V and

recognizes inputs when VCC is greater than 1.25 x VBAT. The block diagram in Figure 1

shows the main elements of the serial RTC.

CDAC-DESD of 72 02/12/2009


Time keeper registers:

5.4 LCD (HD44780U)The HD44780U dot-matrix liquid crystal display controller and driver LSI displays

alphanumerics, Japanese kana characters, and symbols. It can be configured to drive a dot-

matrix liquid crystal display under the control of a 4- or 8-bit microprocessor. Since all the

functions such as display RAM, character generator, and liquid crystal driver, required for

driving a dot-matrix liquid crystal display are internally provided on one chip, a minimal

system can be interfaced with this controller/driver.

A single HD44780U can display up to one 8-character line or two 8-character lines. The

HD44780U has pin function compatibility with the HD44780S which allows the user to easily

replace an LCD-II with an HD44780U. The HD44780U character generator ROM is extended

to generate 208 5 8 dot character fonts and 32 5 10 dot character fonts for a total of 240

different character fonts. The low power supply (2.7V to 5.5V) of the HD44780U is suitable for

any portable battery-driven product.

Features 5 .8 and 5 .10 dot matrix possible Low power operation support:

o 2.7 to 5.5V Wide range of liquid crystal display driver power

o 3.0 to 11V Liquid crystal drive waveform

o A (One line frequency AC waveform)

CDAC-DESD of 72 02/12/2009


Correspond to high speed MPU bus interfaceo 2 MHz (when VCC = 5V)

4-bit or 8-bit MPU interface enabled 80 8-bit display RAM (80 characters max.)

Block Diagram:

CDAC-DESD of 72 02/12/2009


Pin Diagram:

Function Description:RegistersThe HD44780U has two 8-bit registers, an instruction register (IR) and a data register (DR).

The IR stores instruction codes, such as display clear and cursor shift, and address information

for display data RAM (DDRAM) and character generator RAM (CGRAM). The IR can only be

written from the MPU.

CDAC-DESD of 72 02/12/2009


The DR temporarily stores data to be written into DDRAM or CGRAM and temporarily stores

data to be read from DDRAM or CGRAM. Data written into the DR from the MPU is

automatically written into DDRAM or CGRAM by an internal operation. The DR is also used

for data storage when reading data from DDRAM or CGRAM. When address information is

written into the IR, data is read and then stored into the DR from DDRAM or CGRAM by an

internal operation. Data transfer between the MPU is then completed when the MPU reads the

DR. After the read, data in DDRAM or CGRAM at the next address is sent to the DR for the

next read from the MPU. By the register selector (RS) signal, these two registers can be

selected.

Register Selection

RS R/W Operation0 0 IR write as an internal operation (display clear, etc.)

0 1 Read busy flag (DB7) and address counter (DB0 to DB6)

1 0 write as an internal operation (DR to DDRAM or CGRAM)

1 1 DR read as an internal operation (DDRAM or CGRAM to DR)

Liquid Crystal Display Driver CircuitThe liquid crystal display driver circuit consists of 16 common signal drivers and 40 segment

signal drivers. When the character font and number of lines are selected by a program, the

required common signal drivers automatically output drive waveforms, while the other

common signal drivers continue to output non-selection waveforms.

Sending serial data always starts at the display data character pattern corresponding to the last

address of the display data RAM (DDRAM). Since serial data is latched when the display data

character pattern corresponding to the starting address enters the internal shift register, the

HD44780U drives from the head display.

HOW LCD WORKS?

CDAC-DESD of 72 02/12/2009


It turns out that liquid crystals are closer to a liquid state than a solid. It takes a fair amount of

heat to change a suitable substance from a solid into a liquid crystal, and it only takes a little

more heat to turn that same liquid crystal into a real liquid. This explains why liquid crystals

are very sensitive to temperature and why they are used to make thermometers and mood

rings. It also explains why a laptop computer display may act funny in cold weather or during a

hot day at the beach.

PICTURE:

5.5 LED

A light-emitting diode (LED) is a semiconductor device that emits visible light when an electric

current passes through it. The light is not particularly bright, but in most LEDs it is

monochromatic, occurring at a single wavelength. The output from an LED can range from red

(at a wavelength of approximately 700 nanometers) to blue-violet (about 400 nanometers).

Some LEDs emit infrared (IR) energy (830 nanometers or longer); such a device is known as

an infrared-emitting diode (IRED).

An LED or IRED consists of two elements of processed material called P-type semiconductors

and N-type semiconductors. These two elements are placed in direct contact, forming a region

called the P-N junction. In this respect, the LED or IRED resembles most other diode types, but

there are important differences. The LED or IRED has a transparent package, allowing visible

CDAC-DESD of 72 02/12/2009


or IR energy to pass through. Also, the LED or IRED has a large PN-junction area whose shape

is tailored to the application.

Basically, LEDs are just tiny light bulbs that fit easily into an electrical circuit. But unlike

ordinary incandescent bulbs, they don't have a filament that will burn out, and they don't get

especially hot. They are illuminated solely by the movement of electrons in a semiconductor

material, and they last just as long as a standard transistor.

BENEFITS OF LED:

• Low power requirement: Most types can be operated with battery power supplies.

• High efficiency: Most of the power supplied to an LED or IRED is converted into

radiation in the desired form, with minimal heat production.

• Long life: When properly installed, an LED or IRED can function for decades.

TYPICAL APPLICATIONS:

• Indicator lights: These can be two-state (i.e., on/off), bar-graph, or alphabetic-numeric

readouts.

• LCD panel backlighting: Specialized white LEDs are used in flat-panel computer

displays.

• Fiber optic data transmission: Ease of modulation allows wide communications

bandwidth with minimal noise, resulting in high speed and accuracy.

• Remote control: Most home-entertainment "remotes" use IREDs to transmit data to the

main unit.

• optoisolator: Stages in an electronic system can be connected together without

unwanted interaction.

CDAC-DESD of 72 02/12/2009


DIAGRAM:

While all diodes release light, most don't do it very effectively. In an ordinary diode, the semiconductor material itself ends up absorbing a lot of the light energy. LEDs are specially constructed to release a large number of photons outward. Additionally, they are housed in a plastic bulb that concentrates the light in a particular direction. As you can see in the diagram, most of the light from the diode bounces off the sides of the bulb, traveling on through the rounded end.

5.6 Motor Driver(L293D)The Device is a monolithic integrated high voltage, high current four channel driver

designed to accept standard DTL or TTL logic levels and drive inductive loads (such as relays solenoides, DCand stepping motors) and switching power transistors.

To simplify use as two bridges each pair of channels is equipped with an enable input. A separate supply input is provided for the logic, allowing operation at a lower voltage and internal clamp diodes are included.

This device is suitable for use in switching applications at frequencies up to 5 kHz. The L293D is assembled in a 16 lead plastic packaage which has 4 center pins connected togetherand used for heatsinking.

CDAC-DESD of 72 02/12/2009


The L293D is a quadruple push-pull 4 channel driver capable of delivering 600 mA (1.2 A peak surge) per channel. The L293D is ideal for controlling the forward/reverse/brake motions of small DC motors controlled by a microcontroller such as a PIC or BASIC Stamp.

The L293D is a high voltage, high current four channel driver designed to accept standard TTL logic levels and drive inductive loads (such as relays solenoids, DC and stepping motors) and switching power transistors. The L293D is suitable for use in switching applications at frequencies up to 5 KHz.

Features:

• 600 mA Output Current Capability Per Driver • Pulsed Current 1.2 A / Driver • Wide Supply Voltage Range: 4.5 V to 36 V • Separate Input-Logic Supply • NE Package Designed for Heat Sinking • Thermal Shutdown & Internal ESD Protection • High-Noise-Immunity Inputs

ABSOLUTE MAXIMUM RATINGS

Symbol Parameter Value UnitVs Supply Voltage 36 VVss Logic Supply 36 VVi Input Voltage 7 VVen Enable Voltage 7 VIo Peak Output Current (100 s non

repetitive)1.2 A

Ptot Total Power Dissipation at Tpins= 90 C 4 WTstg, Ti Storage & Junction Temperature -40 to 150 CPIN DIAGRAM:

CDAC-DESD of 72 02/12/2009


APPLICATIONS:

• DC and stepper motor drives• Position and velocity servomechanisms

CDAC-DESD of 72 02/12/2009


5.7 ENC28J60 Ethernet interface cardEthernet 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. It’s an SPI based add-on chip which has Ethernet PHY and MAC to

equip any embedded controller with SPI interface with network capability. 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.

CDAC-DESD of 72 02/12/2009


Description:

Ethernet Interface board contains the Ethernet Controller ENC28J60 with SPI support and

Ethernet Jack – MAG Jack (RJ45).

The Ethernet Interface Board can be connected to the uNiBoard (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 uNiBoard. This Ethernet Interface can be used to develop different

applications like embedded web server, Ethernet based Data acquisition system, internet controlled

robot etc.

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.

CDAC-DESD of 72 02/12/2009


Features:

• Ethernet Controller – Microchip’s ENC28J60 with SPI interface.

• Supports Data Transfer up to 10 Mb/s.

• LINK/STATUS LEDs for indication/debugging.

Ethernet Controller Features:

• IEEE 802.3 compatible Ethernet controller.

• Integrated MAC and Receiver and Supports Full and Half-Duplex modes.

• Programmable padding and CRC generation.

• SPI Interface with speeds up to 10 Mb/s.

Buffer:

• 8-Kbyte transmit/receive packet dual port SRAM.

• Configurable transmit/receive buffer size.

• Internal DMA for fast data movement.

CDAC-DESD of 72 02/12/2009


• Hardware assisted IP checksum calculation.

Physical Layer (PHY) Features:

• Wave shaping output filter.

• Loopback mode.

Medium Access Controller (MAC) Features:

• Supports Unicast, Multicast and Broadcast packets.

• Loopback mode.

• Programmable receive packet filtering and following:

1. Unicast destination address.2. Multicast address.3. Broadcast address.4. Magic Packet TM.5. Group destination addresses as defined by 64-bit hash table.

Setting up the Connection:

Connect the pins of the Ethernet Interface board with the Development Board (uNiBoard) accordingly.

1. MOSI < - > MOSI2. MISO < - > MISO3. SCK < - > SCK4. CS < - > SS5. WOL < - > NC for current configuration (LAN interrupt o/p pin)6. INT < - > NC for current configuration (Interrupt o/p pin)7. CLK0 < - > NC for current configuration (Programmable clock o/p pin)8. RST < - > PB7 (in case of uNiBoard)9. GND < - > GND10. 3V3 < - > VCC (in case of uNiBoard)

CDAC-DESD of 72 02/12/2009


Working Of Ethernet Interface Board:

Reception: Data coming from the network through the cable will be stored in the Ethernet

Buffer, this will be done by the firmware written on the ENC28J60. From the Ethernet Buffer

we can read the data through the SPI pins of the ENC28J60 to the uNiBoard. The following are

API's used in the Source code:

• enc28j60PacketReceive() - to receive packets

• enc28j60Write() - to write register values

• enc28j60SetBank() - to set the address bank

• enc28j60WriteOp() - to do the write operation

• enc28j60ReadOp() - to read the data from the buffer

PacketReceive function would be called first and in that Write function will take the value and

address to which the write operation to be performed. SetBank will set the address bank and the

WriteOp will actually do the write. These two function calls are done within Write function as

can be seen above. In ReadOp we will provide address of the buffer as argument and it will

return with buffer values, so using this function the actual read is done from the buffer.

Transmission: For sending the data packets through the interface, the data should be written on

Ethernet Buffer which is done by using the SPI. Then that data will be transmitted from the

buffer through the network cable to the network, which is done by the firmware written on the

ENC28J60 controller. The following are API's used in the Source code:

• enc28j60PacketSend() - to send packets

CDAC-DESD of 72 02/12/2009


• enc28j60Write() - to write register values

• enc28j60SetBank() - to set the address bank

• enc28j60WriteOp() - to do the write

• enc28j60WriteBuffer() - to write into the buffer

PacketSend function will be called first and in that Write function will take the value and

address to which the write operation to be performed. SetBank will set the address bank and the

WriteOp will actually do the write. These two function calls are invoked in Write function.

WriteBuffer will write the data to be sent into the buffer.

Ethernet Interface Board interfaced with uNiBoard:

5.8 ExtraThings which needed other than the above components are

5.8.1 SPI Bus

SPI is a serial bus standard established by Motorola and supported in silicon products from various manufacturers. SPI interfaces are available on popular communication processors such as the MPC8260 and microcontrollers such as the M68HC11. It is a synchronous serial data link that operates in full duplex (signals carrying data go in both directions simultaneously).

DESCRIPTION:

CDAC-DESD of 72 02/12/2009


SPI stands for Serial Peripheral Interface. SPI is a synchronous protocol that allows a master device to initiate communication with a slave device. Data is exchanged between these devices.

SPI is implemented in the PICmicro MCU by a hardware module called the Synchronous Serial Port or the Master Synchronous Serial Port. This module is built into many different PICmicro devices. It allows serial communication between two or more devices at a high speed and is reasonably easy to implement.

SPI AS SYNCHRONOUS PROTOCOL:SPI is a Synchronous protocol.The clock signal is provided by the master to provide synchronization. The clock signal controls when data can change and when it is valid for reading. Since SPI is synchronous, it has a clock pulse along with the data. RS-232 and other asynchronous protocols do not use a clock pulse, but the data must be timed very accurately.

Since SPI has a clock signal, the clock can vary without disrupting the data. The data rate will simply change along with the changes in the clock rate. This makes SPI ideal when the microcontroller is being clocked imprecisely, such as by a RC oscillator.

SPI AS MASTER-SLAVE PROTOCOL:SPI is a Master-Slave protocol.

Only the master device can control the clock line, SCK. No data will be transferred unless the

clock is manipulated. All slaves are controlled by the clock which is manipulated by the master

device. The slaves may not manipulate the clock. The SSP configuration registers will control

how a device will respond to the clock input.

OPERATIONIn SPI, data typically changes during the rising or falling edge of SCK. This is how the data is

synchronized with the clock signal.

Logically, the point at which data is read is opposite from when it changes. The data is valid at

the point of reading.

The SPI bus specifies four logic signals.

• SCLK — Serial Clock (output from master)

• MOSI/SIMO — Master Output, Slave Input (output from master)

• MISO/SOMI — Master Input, Slave Output (output from slave)

• SS — Slave Select (active low; output from master)

CDAC-DESD of 72 02/12/2009


SIGNALS USED BY SPI:SPI is a Serial Interface and uses the following signals to serially exchange data with another

device:

• SS - This signal is known as Slave Select. When it goes low, the slave device will listen

for SPI clock and data signals.

• SCK - This is the serial clock signal. It is generated by the master device and controls

when data is sent and when it is read.

• SDO - This is the Serial Data Output signal. SDO carries data out of a device.

• SDI - SDI is the Serial Data Input line. It carries data into a device.

DATA TRANSFER:

SPI creates a data loop between two devices. Data leaving the master exits on the SDO (serial

data output) line. Data entering the master enters on the serial data input, SDI line.

A clock (SCK), is generated by the master device. It controls when and how quickly data is

exchanged between the two devices.

SS allows a master device to control when a particular slave is being addressed. This allows the

possibility of having more than one slave and simplifies the communications. When the SS

signal goes low at a slave device, only that slave is accessed by SPI.

CDAC-DESD of 72 02/12/2009


SPI WORKING:

Devices communicate using a master/slave relationship, in which the master initiates the data

frame. When the master generates a clock and selects a slave device, data may be transferred in

either or both directions simultaneously. In fact, as far as SPI is concerned, data are always

transferred in both directions. It is up to the master and slave devices to know whether a

received byte is meaningful or not. So a device must discard the received byte in a "transmit

only" frame or generate a dummy byte for a "receive only" frame.

SPI specifies four signals: clock (SCLK); master data output, slave data input (MOSI); master

data input, slave data output (MISO); and slave select (ÇSS). Figure 1 shows these signals in a

single-slave configuration. SCLK is generated by the master and input to all slaves. MOSI

carries data from master to slave. MISO carries data from slave back to master. A slave device

is selected when the master asserts its ÇSS signal.

Advantages

• Full duplex communication

• Higher throughput than I²C or SMBus

• Complete protocol flexibility for the bits transferred

o Arbitrary choice of message size, content, and purpose

• Uses many fewer pins on IC packages, and wires in board layouts or connectors, than

parallel interfaces

• At most one "unique" bus signal per device (chip select); all others are shared

Disadvantages

• Requires more pins on IC packages than I²C, even in the "3-Wire" variant

• No in-band addressing; out-of-band chip select signals are required on shared buses

CDAC-DESD of 72 02/12/2009


• No hardware flow control

• No hardware slave acknowledgment

APPLICATIONS:

SPI is used to talk to a variety of peripherals, such as:

• Sensors: temperature, pressure, ADC, touch screens

• Control devices: audio codec’s, digital potentiometers, DAC

• Camera lenses: Canon EF lens mount

• Communications: Ethernet, USB, USART, CAN, IEEE 802.15.4, IEEE 802.11

5.8.2 I2C Bus

The name I2C translates into "Inter IC". Sometimes the bus is called IIC or I²C bus. The

original communication speed was defined with a maximum of 100 kbit per second and many

applications don't require faster transmissions. For those that do there is a 400 kbit fastmode

and - since 1998 - a high speed 3.4 Mbit option available. Recently, fast mode plus a transfer

rate between this has been specified.

I2C is not only used on single boards, but also to connect components which are linked via

cable. Simplicity and flexibility are key characteristics that make this bus attractive to many

applications.

FEATURES:

• Only two bus lines are required.

• No strict baud rate requirements like for instance with RS232, the master generates a

bus clock.

• Simple master/slave relationships exist between all components.

• Each device connected to the bus is software-addressable by a unique address.

CONCEPT:

CDAC-DESD of 72 02/12/2009


The I2C-bus supports any IC fabrication process (NMOS, CMOS, bipolar). Two wires, serial

data (SDA) and serial clock (SCL), carry information between the devices connected to the bus.

Each device is recognized by a unique address (whether it’s a microcontroller, LCD driver,

memory or keyboard interface) and can operate as either a transmitter or receiver, depending on

the function of the device. Obviously an LCD driver is only a receiver, whereas a memory can

both receive and transmit data. In addition to transmitters and receivers, devices can also be

considered as masters or slaves when performing data transfers.

A master is the device which initiates a data transfer on the bus and generates the clock signals

to permit that transfer. At that time, any device addressed is considered a slave.

The I2C-bus is a multi-master bus. This means that more than one device capable of controlling

the bus can be connected to it.

The possibility of connecting more than one microcontroller to the I2C-bus means that more

than one master could try to initiate a data transfer at the same time. To avoid the chaos that

might ensue from such an event - an arbitration procedure has been developed. This procedure

relies on the wired-AND connection of all I2C interfaces to the I2C-bus. If two or more masters

try to put information onto the bus, the first to produce a ‘one’ when the other produces a ‘zero’

will lose the arbitration. The clock signals during arbitration are a synchronized combination of

the clocks generated by the masters using the wired-AND connection to the SCL line.

GENERAL CHARACTERISTICS

Both SDA and SCL are bi-directional lines, connected to a positive supply voltage via a

current-source or pull-up resistor (see Fig.3). When the bus is free, both lines are HIGH. The

output stages of devices connected to the bus must have an open-drain or open-collector to

perform the wired-AND function. Data on the I2C-bus can be transferred at rates of up to 100

kbit/s in the Standard-mode, up to 400 kbit/s in the Fast-mode, or up to 3.4 Mbit/s in the High-

speed mode. The number of interfaces connected to the bus is solely dependent on the bus

capacitance limit of 400 pF.

CDAC-DESD of 72 02/12/2009


STANDARD MODES:

The Standard-mode I2C-bus specification, with its data transfer rate of up to 100 kbit/s and 7-

bit addressing, has been in existence since the beginning of the 1980’s. This concept rapidly

grew in popularity and is today accepted worldwide as a de facto standard with several hundred

different compatible ICs on offer from Philips Semiconductors and other suppliers. To meet the

demands for higher speeds, as well as make available more slave address for the growing

number of new devices, the Standard-mode I2C-bus specification was upgraded over the years

and today is available with the following extensions:

· Fast-mode: with a bit rate up to 400 kbit/s.

· High-speed mode (Hs-mode): with a bit rate up to 3.4 Mbit/s.

· 10-bit addressing: this allows the use of up to 1024 additional slave addresses.

There are two main reasons for extending the regular I2C-bus specification:

• Many of today’s applications need to transfer large amounts of serial data and require

bit rates far in excess of 100 kbit/s (Standard-mode), or even 400 kbit/s (Fast-mode). As

a result of continuing improvements in semiconductor technologies, I2C-bus devices

are now available with bit rates of up to 3.4 Mbit/s (Hs-mode) without any noticeable

increases in the manufacturing cost of the interface circuitry.

• As most of the 112 addresses available with the 7-bit addressing scheme were soon

allocated; it became apparent that more address combinations were required to prevent

problems with the allocation of slave addresses for new devices. This problem was

resolved with the new 10-bit addressing scheme, which allowed about a tenfold increase

in available addresses.

The I2C Bus Protocol

The I2C bus physically consists of 2 active wires and a ground connection. The active wires,

called SDA and SCL, are both bi-directional. SDA is the Serial DAta line, and SCL is the

Serial CLock line.

CDAC-DESD of 72 02/12/2009


Every device hooked up to the bus has its own unique address, no matter whether it is an MCU,

LCD driver, memory, or ASIC. Each of these chips can act as a receiver and/or transmitter,

depending on the functionality. Obviously, an LCD driver is only a receiver, while a memory

or I/O chip can be both transmitter and receiver.

The I2C bus is a multi-master bus. This means that more than one IC capable of initiating a

data transfer can be connected to it. The I2C protocol specification states that the IC that

initiates a data transfer on the bus is considered the Bus Master. Consequently, at that time, all

the other ICs are regarded to be Bus Slaves.

As bus masters are generally microcontrollers, let's take a look at a general 'inter-IC chat' on the

bus. Lets consider the following setup and assume the MCU wants to send data to one of its

slaves.

First, the MCU will issue a START condition. This acts as an 'Attention' signal to all of the

connected devices. All ICs on the bus will listen to the bus for incoming data.

Then the MCU sends the ADDRESS of the device it wants to access, along with an indication

whether the access is a Read or Write operation (Write in our example). Having received the

address, all IC's will compare it with their own address. If it doesn't match, they simply wait

until the bus is released by the stop condition (see below). If the address matches, however, the

chip will produce a response called the ACKNOWLEDGE signal.

Once the MCU receives the acknowledge, it can start transmitting or receiving DATA. In our

case, the MCU will transmit data. When all is done, the MCU will issue the STOP condition.

This is a signal that the bus has been released and that the connected ICs may expect another

transmission to start any moment.

CDAC-DESD of 72 02/12/2009


We have had several states on the bus in our example: START, ADDRESS, ACKNOWLEDGE,

DATA, STOP. These are all unique conditions on the bus. Before we take a closer look at these

bus conditions we need to understand a bit about the physical structure and hardware of the

bus.

5.8.3 Rj45 Network cable

RJ45 is a standard type of connector for network cables. RJ45 connectors are most commonly

seen with Ethernet cables and networks.

RJ45 connectors feature eight pins to which the wire strands of a cable interface electrically.

Standard RJ-45 pin outs define the arrangement of the individual wires needed when attaching

connectors to a cable.

Several other kinds of connectors closely resemble RJ45 and can be easily confused for each

other. The RJ-11 connectors used with telephone cables, for example, are only slightly smaller

(narrower) than RJ-45 connectors.

CONNECTION:

UTP consists of 4 twisted pairs. The standard colors are:

1. white/blue – blue

2. white/orange – orange

3. white/green – green

4. white/brown – brown

Connection Types:

1. Hub to Hub or Computer to Computer Connection : end T568A, other end T568B

2. Hub to Computer connection: T568B on each end.

CDAC-DESD of 72 02/12/2009


PIN DESCRIPTION:

Pin No. Wire Colour Function1 WHITE/Orange Transmit Data+2 ORANGE/White Transmit Data-3 WHITE/Green Recieve Data+4 BLUE/White None5 WHITE/Blue None6 GREEN/White Recieve Data-7 WHITE/Brown None8 BROWN/White None

CDAC-DESD of 72 02/12/2009


6 Components Involved (software)

6.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++.

New features in winavr 4.11:

• Major version change for GCC. Now at version 4.1.1.

• Support for the ATmega128, and ATmega2561 devices.

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

• New avr-libc version with new examples, updated examples, many bugs fixed, and new

APIs for Power Reduction and Clock Prescaler.

WinAVR is a collection of executable software development tools for the Atmel AVR

processor hosted on Windows.

These software development tools include:

CDAC-DESD of 72 02/12/2009


• Compilers

• Assembler

• Linker

• Librarian

• C Library

• Debugger

• In-Circuit Emulator software

• Editor / IDE

• Many support utilities

6.2 AVR STUDIO 4.14

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.

CDAC-DESD of 72 02/12/2009


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.

CDAC-DESD of 72 02/12/2009


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, Reset, Single step, set

breakpoints and watch variables. The I/O, memory and register views are fully functional using

the AVR Simulator.

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

Traditional TCP/IP implementations have required far too much resources both in terms of

code size and memory usage to be useful in small 8 or 16-bit systems. Code size of a few

hundred kilobytes and RAM requirements of several hundreds of kilobytes have made it

impossible to fit the full TCP/IP stack into systems with a few tens of kilobytes of RAM and

room for less than 100 kilobytes of code.

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

CDAC-DESD of 72 02/12/2009


let the embedded devices to act as first-class network citizens. The uIP TCP/IP implementation

that is not tailored for any specific application.

6.3.1 TCP/IP CommunicationThe 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 are 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 are 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 is 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

CDAC-DESD of 72 02/12/2009


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 very

few applications that make use of those features they can be removed without loss of

generality.

6.3.2 Main Control LoopThe uIP stack can be run either as a task in a multitasking system, or as the main program in a

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

CDAC-DESD of 72 02/12/2009


6.3.3 Architecture Specific FunctionsuIP 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.

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

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.

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

CDAC-DESD of 72 02/12/2009


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

6.3.4.1 Application EventsThe 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).

CDAC-DESD of 72 02/12/2009


6.3.4.2 The Connection PointerWhen 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.

6.3.4.3 Receiving DataIf 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 therefor have to either act directly

on the incoming data, or by itself copy the incoming data into a buffer for later processing.

6.3.4.4 Sending DataWhen 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

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.

CDAC-DESD of 72 02/12/2009


6.3.4.5 Retransmitting DataRetransmissions 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. Therefor, 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.3.4.6 Closing ConnectionsThe 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.

6.3.4.7 Reporting ErrorsThere 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.

CDAC-DESD of 72 02/12/2009


6.3.4.8 PollingWhen 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.

6.3.4.9 Listening PortsuIP 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.

6.3.4.10 Opening ConnectionsNew 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().

6.3.5 Protocol ImplementationsThe 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

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.

CDAC-DESD of 72 02/12/2009


6.3.5.1 IP --- Internet ProtocolWhen 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.

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.

6.3.5.2 ICMP --- Internet Control Message ProtocolThe 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.

CDAC-DESD of 72 02/12/2009


6.3.5.3 TCP --- Transmission Control ProtocolThe 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.

Listening ConnectionsTCP 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.

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.

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.

CDAC-DESD of 72 02/12/2009


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.

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.

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.

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.

CDAC-DESD of 72 02/12/2009


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

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

• Understand the interaction between web clients (browsers, robots, search engines, etc.)

and web servers.

• Streamline web services to make better use of the protocol.

HTTP Transactions:

This section presents an example of a common web transaction, showing the HTTP exchanged between the client and server program.

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

CDAC-DESD of 72 02/12/2009


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-xbitmap, image/

jpeg, image/pjpeg, */*

Accept-Language: en-us

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE

5.01; Windows NT)

Host: hypothetical.ora.com

Connection: Keep-Alive

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: closeContent-type: text/html

<title>Sample Homepage</title>

CDAC-DESD of 72 02/12/2009


<img src="/images/oreilly_mast.gif">

<h1>Welcome</h1>

6.4 HTML HTML, which stands for Hypertext Markup Language, is the predominant markup language

for web pages. It provides a means to create structured documents by denoting structural

semantics for text such as headings, paragraphs, lists etc as well as for links, quotes, and other

items. It allows images and objects to be embedded and can be used to create interactive forms.

It is written in the form of HTML elements consisting of "tags" surrounded by angle brackets

within the web page content. It can include or can load scripts in languages such as JavaScript,

which affect the behavior of HTML processors like Web browsers, and Cascading Style Sheets

(CSS) to define the appearance and layout of text and other material. The use of CSS is

encouraged over explicit presentational markup.

The document Structure should be like this:

<html>...</html>

The Root element of an HTML document; all other elements are contained in this.

Standardised in HTML 2.0; still current.

<head>...</head>

Container for processing information and metadata for an HTML document.


(See Document head elements for child elements.)

<body>...</body>

Container for the displayable content of an HTML document.


(See Document body elements for child elements.)

CDAC-DESD of 72 02/12/2009


7 Future Enhancements

This project can enhanced to remote AC controller for group of buildings or remote buildings

just by adding an zigbee technology in it. The approach for this is shown in the figure.

Here all the floors having zigbee end module having temperature sensor, which is always

sending the current temperature to the zigbee coordinator, which is mounted on the AVR board,

and the ATMega128 uc will control the ac system according to the program and the updated

values from the embedded web server.

So by this from any place in the world the administrator or the controller can control the ac

system.

CDAC-DESD of 72 02/12/2009


8 Bibliography

8.1.1 Books and Journals: 1. TCP-IP Lean--Web Servers for Embedded Systems By Jeremy Bentham

2. The uIP Embedded TCP/IP Stack By Adam Dunkels

3. Data Communications & Networking By Forouzan

4. HTML for Dummies, 4th Edition By Ed Tittel

5. HTML: The Definitive Guide By Chuck Musciano

6. Atmel AVR Quick Start By Hubert Hogl

7. Embedded C Programing & Atmel AVR By Barnett

8.

CDAC-DESD of 72 02/12/2009


8.1.2 Reference links:1. http://www.sics.se/~adam/uip/ (uip protocol suit)

2. http://www.fh-augsburg.de/~hhoegl (AVR Quick start)

3. http://www.avrfreaks.net

4. http://www.atmel.com

5. http://www.thinklabs.in/forums

6. http://www.microchip.com

CHECKLISTChecklist of items for Award of “Diploma in Embedded System Design” at CDAC, ACTS, Pune

1. Is the report properly hard bound? Yes/No

2. Is the cover page in proper format? Yes/No

3. Is the Title page (inner cover page) in proper format? Yes/No

CDAC-DESD of 72 02/12/2009

http://www.microchip.com/

http://www.thinklabs.in/forums

http://www.atmel.com/

http://www.avrfreaks.net/

http://www.fh-augsburg.de/~hhoegl

http://www.sics.se/~adam/uip/


4. (a)Is the certificate from the supervisor in proper format?

(b)Has it been signed by the supervisor?

Yes/No

5. Is the Abstract written in the report properly written? Yes/No

6. Does the Report contain a summary of the literature survey? Yes/No

7. Is the conclusion of the report based on the discussion of the work?

1.Are the pages numbered properly?

2.Are the figures numbered properly?

3.Are the tables numbered properly?

4.Are the captions of figures and tables proper?

5.Are the Appendices numbered properly?

Yes/No

Yes/No

Yes/No

Yes/No

Yes/No

Yes/No

8. Is the conclusion of the report based on the discussion of the work? Yes/No

9. Are the References or Bibliography given in the report? Yes/No

DECLARATION

Place:

Date:

Sign:

Name: venugopal reddy somu

CDAC-DESD of 72 02/12/2009


Date:

Sign:

Name: Mayuri Bodhankar

Date:

Sign:

Name: Simerdeep Singh Bhatti

I have duly verified all the items in the checklist and ensured that the report is in

proper format.

Place: Signature of the Project Guide

Date: Name:

CDAC-DESD of 72 02/12/2009

23521348 Remote AC Controlling Through Embedded Web Server

Documents

Transcript of 23521348 Remote AC Controlling Through Embedded Web Server