Remote AC Controlling Through Embedded Web Server

AC Controlling through embedded web server
1 Index
1 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 Page 1 of 72 02/12/2009

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

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.

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

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.

4 Description (working Procedure)

Flow chart:


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.

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

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

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.

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

Analogy sensors (LDR)

The LDR sensor is connected to channel 0(PF0) of the Atmega128 microcontroller.
External power
The 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 Driver

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

• 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 LEDs
Test 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.
LCD
LCD 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)

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:

PIN DIAGRAM:
PORTS
The 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.
LCD
The 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)

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

5.1 AVR ATMega128:

The ATmega128 is a low-power CMOS 8-bit microcontroller based on the AVR enhanced
RISC
architecture. By executing powerful instructions in a single clock cycle, the ATmega128
achieves throughputs approaching 1 MIPS per MHz allowing the system designer to optimize
power 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

• 64 lead TQFP
Block diagram:
ABSOLUTE MAXIMUM RATINGS:

Sr. No. Description Ratings
1 Operating Temperature -55 to +125 °C

2 Storage Temperature -65 to +150 °C

3 -0.5 to Vcc+0.5 V
Voltage on any Pin except with respect to Ground
4 -0.5 to +13.0 V
Voltage on with respect to Ground
5 Maximum Operating Voltage 6.0 V
6 DC Current per I/O Pin 40.0 mA
7 DC Current Vcc and GND Pins 200.0 – 400.0 mA
PIN DIAGRAM:

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:

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

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.

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

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

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.

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)

 Correspond to high speed MPU bus interface

o 2 MHz (when VCC = 5V)
 4-bit or 8-bit MPU interface enabled
 80 8-bit display RAM (80 characters max.)
Block Diagram:

Pin Diagram:
Function Description:
Registers
The 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.

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 Operation
0 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 Circuit

The 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?

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

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.

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, DC
and 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 together
and used for heatsinking.

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 Unit

Vs Supply Voltage 36 V
Vss Logic Supply 36 V
Vi Input Voltage 7 V
Ven Enable Voltage 7 V
Io Peak Output Current (100 s non 1.2 A
repetitive)
Ptot Total Power Dissipation at Tpins= 90 C 4 W
Tstg, Ti Storage & Junction Temperature -40 to 150 C
PIN DIAGRAM:

APPLICATIONS:
• DC and stepper motor drives

• Position and velocity servomechanisms

5.7 ENC28J60 Ethernet interface card

Ethernet is a local area technology, which is used for reliable and efficient transfer and access
of information across the devices connected to the network. Once a device is attached to the
network, it will have the ability to communicate with any other attached device. This allows the
network to expand to accommodate new devices without requiring any modification to those
devices already on the network.
Ethernet controller ENC28J60 from Microchip forms the building block for our Ethernet
Interface add-on Board. 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.

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.

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.

• 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 < - > MOSI
2. MISO < - > MISO
3. SCK < - > SCK
4. CS < - > SS
5. 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 < - > GND
10. 3V3 < - > VCC (in case of uNiBoard)

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

• 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 Extra
Things 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:

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

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.

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

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

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.

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.

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.

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.

PIN DESCRIPTION:
Pin No. Wire Colour Function

1 WHITE/Orange Transmit Data+
2 ORANGE/White Transmit Data-
3 WHITE/Green Recieve Data+
4 BLUE/White None
5 WHITE/Blue None
6 GREEN/White Recieve Data-
7 WHITE/Brown None
8 BROWN/White None

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:

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

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

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

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 Loop

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

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

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

6.3.4.2 The Connection Pointer

When the application is called by uIP, the global variable uip_conn is set to point to the
uip_conn structure for the connection that currently is handled, and is called the "current
connection". The fields in the uip_conn structure for the current connection can be used, e.g., to
distinguish between different services, or to check to which IP address the connection is
connected. One typical use would be to inspect the uip_conn->lport (the local TCP port
number) to decide which service the connection should provide. For instance, an application
might decide to act as an HTTP server if the value of uip_conn->lport is equal to 80 and act as
a TELNET server if the value is 23.
6.3.4.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 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 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
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.

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

6.3.4.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.
6.3.4.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.
6.3.4.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().
6.3.5 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
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.

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

The ICMP protocol is used for reporting soft error conditions and for querying host parameters.
Its main use is, however, the echo mechanism which is used by the "ping" program.
The ICMP implementation in uIP is very simple as itis restricted to only implement ICMP echo
messages. Replies to echo messages are constructed by simply swapping the source and
destination IP addresses of incoming echo requests and rewriting the ICMP header with the
Echo-Reply message type. The ICMP checksum is adjusted using standard techniques (see
RFC1624).
Since only the ICMP echo message is implemented, there is no support for Path MTU
discovery or ICMP redirect messages. Neither of these is strictly required for interoperability;
they are performance enhancement mechanisms.

6.3.5.3 TCP --- Transmission Control Protocol

The TCP implementation in uIP is driven by incoming packets and timer events. Incoming
packets are parsed by TCP and if the packet contains data that is to be delivered to the
application, the application is invoked by the means of the application function call. If the
incoming packet acknowledges previously sent data, the connection state is updated and the
application is informed, allowing it to send out new data.
Listening Connections
TCP 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.

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.

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

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: close
Content-type: text/html
<title>Sample Homepage</title>

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

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.

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.

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
CHECKLIST
Checklist 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

4. (a)Is the certificate from the supervisor in proper format? Yes/No
(b)Has it been signed by the supervisor?
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? Yes/No
1.Are the pages numbered properly? Yes/No
2.Are the figures numbered properly? Yes/No
3.Are the tables numbered properly? Yes/No
4.Are the captions of figures and tables proper?

Yes/No
5.Are the Appendices numbered properly?
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:
Sign:
Date: Name: venugopal reddy somu

Sign:
Date: Name: Mayuri Bodhankar

Sign:
Date: 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:

Remote AC Controlling Through Embedded Web Server

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Remote AC Controlling Through Embedded Web Server

Загружено:

Авторское право:

Доступные форматы

AC Controlling through embedded web server

CDAC-DESD Page 1 of 72 02/12/2009

CDAC-DESD Page 2 of 72 02/12/2009

 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 Page 3 of 72 02/12/2009

CDAC-DESD Page 4 of 72 02/12/2009

CDAC-DESD Page 5 of 72 02/12/2009

4 Description (working Procedure)

CDAC-DESD Page 6 of 72 02/12/2009

CDAC-DESD Page 7 of 72 02/12/2009

CDAC-DESD Page 8 of 72 02/12/2009

5 Components Involved (hard ware)

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

CDAC-DESD Page 9 of 72 02/12/2009

CDAC-DESD Page 10 of 72 02/12/2009

CDAC-DESD Page 11 of 72 02/12/2009

Atmega8 controller with the firmware for programming through USB

I2C and RTC (DS1307) with Backup Battery:

CDAC-DESD Page 12 of 72 02/12/2009

Analogy sensors (LDR)

Onboard Motor Driver

CDAC-DESD Page 13 of 72 02/12/2009

• PB4 (Chip Enable)

CDAC-DESD Page 14 of 72 02/12/2009

General Purpose Ports

MOTOR DRIVER SECTION:

CDAC-DESD Page 15 of 72 02/12/2009

CDAC-DESD Page 16 of 72 02/12/2009

• R/~W (Hardwired GND)

CDAC-DESD Page 17 of 72 02/12/2009

5.1 AVR ATMega128:

CDAC-DESD Page 18 of 72 02/12/2009

ABSOLUTE MAXIMUM RATINGS:

CDAC-DESD Page 19 of 72 02/12/2009

2 Storage Temperature -65 to +150 °C

CDAC-DESD Page 20 of 72 02/12/2009

5.2 LM35 temperature sensor

CDAC-DESD Page 21 of 72 02/12/2009

• 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

Supply Min 4 Volt

Temperature Min -40, 0, -55 deg C

Temperature Max 100, 110, 150 deg C

Sensor Gain 10 mV/Deg C

Supply Max 30 Volt

CDAC-DESD Page 22 of 72 02/12/2009

Output Impedance 0.4 Ohm

Quiescent Current 0.056 mA

Automotive Selection Guide Yes

CDAC-DESD Page 23 of 72 02/12/2009

5.3 RTC (DS1307)

CDAC-DESD Page 24 of 72 02/12/2009

 I2C Serial Interface

CDAC-DESD Page 25 of 72 02/12/2009