Project Report

On

EMBEDDED WIRELESS COMMUNICATION USING

IrDA STANDARD PROTOCOL

Submitted to National Institute of Technology, Warangal in partial fulfillment of

the requirement for the award of Degree
Of
M.Sc (Tech.) Engineering Physics(Electronics)

Submitted by

J.Ravi Kiran
065006

carried at
Central Electronics Engineering Research Institute
Pilani, Rajasthan

Under the guidance of

Internal Guide External Guide

Dr. RLN Sai Prasad Dr. S.S Sadistap
Asst professor, Scientist ‘EII’
Dept of Physics, CEERI, Pilani, Rajasthan
NIT Warangal Rajasthan

Department of Physics
National Institute Of Technology
Warangal-506004
 CERTIFICATE

This is to certify that the dissertation entitled “EMBEDDED WIRELESS

COMMUNICATION USING IrDA STANDARD PROTOCOL” is being submitted by

J.Ravi Kiran, bearing Roll. No. 065006 in partial fulfillment of the degree M.Sc. [Tech]

Engineering physics, with specialization in ELECTRONICS. This report embodies the work

carried out by him at Central Electronics Engineering Research Institute ,

pilani (Rajasthan) from 01-12-08 to 31-05-09. He was under my guidance and supervision

during the course of project work carried out there.

Head of the Department Guide

Prof. S.V.S Ramana Reddy Dr. RLN Sai Prasad
Asst Professor

Department of Physics
NIT-Warangal
 CERTIFICATE

This is to certify that project report entitled “EMBEDDED WIRELESS

COMMUNICATION USING IrDA STANDARD PROTOCOL” is a bonafied work done

by Mr. J. Ravi Kiran for the partial fulfilment of the requirement for the award of
degree “MSc tech Engg Physics with specialization Electronics” awarded by
National Institute Of Technology, Warangal embodies work carried out by him
under my supervision at Central Electronics Engineering Research Institute,
Pilani (Rajasthan) from December 2008 to May 2009.

Signature of Project Guide:

Dr S.S.Sadistap,
Scientist ‘EII’
Agri Electronics Group,
CEERI, Pilani, Rajasthan.
 ACKNOWLEDGEMENTS

I am thankful to Dr. Chandrashekhar, Director, CEERI for providing me an opportunity to

work in this elite institute of Indian Scientists.

Words , indeed are inadequate to express my deep sense of gratitude to Dr. Sashikanth
Sadistap Scientist ‘EII’, Agri Electronics Group, CEERI, Pilani for suggesting the problem
for Dissertation work and guidance at every stage of the work. It is a great privilege to have an
opportunity to work and learn a lot under his guidance.

I am also very thankful to my colleagues Mr. Satish Bindal, Ms. Rita Nagar and Ms. Chandni
Anand for their extended cooperation and suggestion.

I also thank Mr. Arun Sharma (STA), Mr. Pankaj Kumar (JTA) and Mr.K.K Pande (TOC)
and all other AEG group members for their concern for our well being from time to time and
helping in completing my project successfully.

Finally I want to acknowledge my thanks to Mr. Vinod Verma, planning and coordination cell
for allowing me to work here and overcome all personal problems faced in Pilani.

I would like to thank Dr. M Sai Shankar project coordinator, Department of Physics, National
Institute of Technology, Warangal for giving me an opportunity to work with elite institute of
Indian scientists.

I would also like to thank my college guide Dr.RLN Sai Prasad for his extended co- operation
during my project work and Head of department of Physics Dr. SVS Ramana Reddy and all
staff members.

Last but not the least, I would like to thank my classmates and friends who directly or indirectly
helped me and made my stay at Pilani memorable and pleasant event.
 Abstract

Products embedding the communication technology IrDA defines have been around for over five
years, starting with printers and portable PCs. IrDA is cheap to embed, uses unregulated
spectrum, and is increasingly pervasive in a wide range of devices. From its roots in portable PCs
and printers, IrDA technology is present in virtually all new PDAs, it is emerging in mobile
phones, pagers, digital cameras, and image capture devices. We are sitting on the cusp of the
information appliance age, and IrDA is playing a significant role in enabling the interaction
between information appliances, between information appliances and the information
infrastructure, and between appliances communicating across the information infrastructure.

The Embedded system uses powerful RISC processor PIC18F8722 for developing this system.
The developed system reduces the number of components and thus the overall development cost.
To validate developed system, applied various voltages and tested programs and simulated using
Microchip’s MPLAB simulator and programmed target device using ICD (In circuit Debugger)
successfully. This is very cost- effective system over the existing system.
 Contents

1. Introduction
2. Selecting MCP device for infrared applications
3. IrDA protocols
4. How devices connect
5. Using MCP215X/40 developers daughter board with the PICDEM HPC explorer
demo board
6. What is embedded system
7. Introduction to PIC micro controller
8. Results and conclusion
9. Future scope

Appendix

1. Development tools

2. Flow chart

3. Components list

4. References and bibliography

 Wireless Communication Using the IrDA® Standard Protocol

1. Introduction

The two most popular mediums in the wireless arena are Infrared (IR) and Radio Frequency
(RF). When asked to develop a wireless system, you may be concerned about cost, ease
of- design, and distance requirements. IR technologies are better suited for short distance,
low-to-medium data throughput, wireless communication channels. Two common types
of IR technologies are currently in use. These are the TV Remote (TVR) and the IrDA
(Infrared Data Association) standard protocol. The lowest cost wireless connection
technology is TVR. The trade-off with this technology is between distance and bit-rate.
Usually this interface is also unidirectional. If a bidirectional, higher data bandwidth is
required in your application, you may opt to design an IrDA system. This infrared
communication standard has been defined by the IrDA industry-based group. This group has
developed communication standards that are well suited for low-cost, short-range, point-
to-point infrared channels. These types of channels operate over a wide range of speeds
under a cross-platform environment. IrDA standards have been used to install over 300
million low-cost, short-range communication systems in laptops, printers, handheld PCs, and
PDAs, to name a few.

An example of an IrDA standard embedded system is shown in Figure 1. In this system, the
Primary device (PDA) searches for other IrDA standard devices. The Secondary device
(Host Controller and MCP2150) will respond to queries from the Primary device.

The host controller controls the MCP2150 by sending and receiving data through its
UART interface port. The MCP2150, which is positioned between the host controller
UART device and infrared optical transceiver, decodes and encodes the signal. The MCP2150
has two independent baud rates. One of the baud rates is for communication with the
Primary device (PDA). The Primary device negotiates this baud rate with the MCP2150, as
defined in the IrDA standard. The second baud rate is set with the two hardware pins, BAUD1
and BAUD0. This second baud rate is for communication with the host controller. The
IrDA standard is a network protocol and follows a layered approach in its definition.
A model of the IrDA protocol stack is shown in Figure 2. These protocols deal with a
manageable set of responsibilities and also supply needed capabilities to the layers above and
below. The MCP2150 is an IrDA standard Protocol Stack Controller, which provides support
for the IrDA standard protocol “stack” plus bit encoding/decoding. One of the functions of
the MCP2150 is to encode and decode the asynchronous serial data stream

Figure 1- Example of standard embedded system

Figure 2- Model of IrDA protocol stack

The encode/decode translation format is shown in Figures 3 and 4. Figure 3 shows how the
received IR data from the PDA is decoded to UART-formatted data. Figure 4 demonstrates
how data is taken from the Host Controller, into the MCP2150, and encoded in preparation of
transmission to the PDA. The IrDA bit format is the NAND of the UART signal. The bits are
inverted and high pulses are shortened in order to reduce the optics power consumption. The
MCP2150 decodes the IR data, which is then handled by the protocol handler state machine.
The protocol handler sends the appropriate data bytes to the Host Controller in UART-
formatted serial data. The MCP2150 replaces a wired serial connection with a wireless
solution. The MCP2150 allows designers to add IrDA wireless connectivity to their embedded
system designs easily and cost effectively. With this device, the host UART interface allows
easy connections to PC serial ports. Another product available is the MCP2155, which is best
suited for serial port interfaces (ie., modems). In all cases, these point-to-point systems
connect to devices of “higher intelligence”, such as PCs, PDAs, etc.. This minimizes the cost
of MCP215X type devices. The MCP215X can also serve as a primary device in these point-to-
point applications. Both devices provide support for the IrDA standard protocol “stack” plus
bit encoding and decoding capability.
Another product in this family from Microchip is the MCP2140, which is an IrDA standard
protocol stack controller with a fixed baud communication rate of 9600. Adding IR
connectivity to cost-sensitive, high volume, embedded applications was not really feasible
prior to the introduction of the MCP215X and MCP2140 parts. These parts remove the
requirement of the system designer needing to implement the complex IrDA stack. Finally, the
MCP2120 is an infrared encoder/decoder chip. Sending data using IR light requires some
hardware and specialized communication protocols. These protocol and hardware
requirements are described, in detail, in the IrDA standard specifications. The
encoding/decoding functionality of the MCP2150 is designed to be compatible with the
physical layer component of the IrDA standard. This part of the standard is often referred to as
“IrPHY”.Additionally, the MCP2150 handles the specialized communication protocol,
IrCOMM (9-wire “cooked” service class). A complete list of IrDA standard specifications is
available on the IrDA website (www.irda.org).
Figure 3- Decoding from PDA to MCP

Figure 4- Encoding from MCP to PDA

 2. Selecting MCP device for Infrared Applications

Selecting the appropriate MCP device is very important according to our desired characteristics
and specifications. Table 1 shows the encoder/decoder devices specifications and table 2 shows
the IRCOMM protocol handler devices specifications. According to our needs we will choose
the proper and suitable MCP device.
MCP 21XX selection decision tree
MCP212x selection decision tree
2.1 MCP 2150

The MCP2150 is a cost effective, low pin count (18-pin), easy to use device for
implementing IrDA standard wire- less connectivity. The MCP2150 provides support for
the IrDA standard protocol “stack” plus bit encoding/ decoding. The serial interface baud
rates are user selectable to one of four IrDA standard baud rates between 9600 baud and
115.2 kbaud (9600, 19200, 57600, 115200). The IR baud rates are user selectable to one
of five IrDA standard baud rates between 9600 baud and 115.2 kbaud (9600, 19200,
37400, 57600, 115200). The serial interface baud rate will be specified by the
BAUD1:BAUD0 pins, while the IR baud rate is specified by the Primary Device (during
Discover phase). This means that the baud rates do not need to be the same. The MCP2150
operates in Data Terminal Equipment (DTE) applications and sits between a UART and
an infrared optical transceiver. Figure 5 shows pin diagram of MCP 2150

Figure 5- Pin diagram of MCP2150

The MCP2150 encodes an asynchronous serial data stream, converting each data bit to
the corresponding infrared (IR) formatted pulse. IR pulses received are decoded and
then handled by the protocol handler state machine. The protocol handler sends the
appropriate data bytes to the Host Controller in UART formatted serial data. The
MCP2150 supports “point-to-point” applications. That is, one Primary device and one
Secondary device. The MCP2150 operates as a Secondary device. It does not support
“multi-point” applications.

Sending data using IR light requires some hardware and the use of specialized
communication protocols. These protocol and hardware requirements are described,
in detail, by the IrDA standard specifications. The encoding/decoding functionality
of the MCP2150 is designed to be compatible with the physical layer component of the
IrDA standard. This part of the standard is often referred to as “IrPHY”.

2.2 UART Interface

The UART interface communicates with the "controller". This interface is a half duplex
interface, meaning that the system is either transmitting or receiving, but not both
simultaneously.
BAUD RATE
The baud rate for the MCP2150 serial port (the TX and RX pins) is configured by the state
of the BAUD1 and BAUD0 pins. These two device pins are used to select the baud rate at
which the MCP2150 will transmit and receive serial data (not IR data). Below table shows
the baud rate configurations.

2.3 Modulation

The data that the MCP2150 UART received (on the TX pin) that needs to be transmitted (on
the TXIR pin) will need to be modulated. This modulated signal drives the IR transceiver
module. Figure 6 shows the encoding of the modulated signal. Each bit time is comprised of
16-bit clocks. If the value to be transmitted (as determined by the TX pin) is a logic low,
then the TXIR pin will output a low level for 7-bit clock cycles, a logic high level for 3-
bit clock cycles or a minimum of 1.6 µsec. The remaining 6-bit clock cycles will be
low. If the value to transmit is a logic high, then the TXIR pin will output a low level for the
entire 16-bit clock cycles.
Figure 6 - Encoding

2.4 Demodulation

The modulated signal (data) from the IR transceiver module (on RXIR pin) needs to be
demodulated to form the received data (on RX pin). Once demodulation of the data byte
occurs, the data that is received is transmitted by the MCP2150 UART (on the RX
pin). Figure 7 shows the decoding of the modulated signal. Each bit time is comprised
of 16-bit clocks. If the value to be received is a logic low, then the RXIR pin will be a low
level for the first 3-bit clock cycles or a minimum of 1.6 µs. The remaining 13-bit clock
cycles (or differ- ence up to the 16-bit clock time) will be high. If the value to be received is
a logic high, then the RXIR pin will be a high level for the entire 16-bit clock cycles. The
level on the RX pin will be in the appropriate state for the entire 16 clock cycles

Figure 7 – Decoding
 3. IrDA Protocols

The IrDA standard specifies the following protocols:

 Physical Signaling Layer (PHY)

 Link Access Protocol (IrLAP)

 Link Management Protocol/Information Access

 Service (IrLMP/IAS)
The IrDA data lists optional protocols. They are:
 Tiny TP

 IrTran-P

 IrOBEX

 IrLAN

 IrCOMM

 IrMC

 IrDA Lite

Figure 8 shows the IrDA data protocol stack and which components are implemented by
the MCP2150.

Figure 8-IrDA data protocol stack

3.1 IrDA data protocols supported by MCP2150
The MCP2150 supports these required IrDA standard protocols:
 Physical Signaling Layer (PHY)

 Link Access Protocol (IrLAP)

 Link Management Protocol/Information Access Service (IrLMP/IAS)

The MCP2150 also supports some of the optional protocols for IrDA data. The optional
protocols that the MCP2150 implements are:
 Tiny TP

 IrCOMM

3.2 Physical Signaling Layer

The MCP2150 provides the following Physical Signal Layer specification support:
o Bidirectional communication

o Data Packets are protected by a CRC

 16-bit CRC for speeds up to 115.2 kbaud

o Data Communication Rate

 9600 baud minimum data rate

The following Physical Layer Specification is dependent on the optical transceiver

logic used in the application. The specification states:

• Communication Range, which sets the end user expectation for discovery, recognition
and performance.

 Continuous operation from contact to at least

1 meter (typically 2 meters can be reached)
 A low power specification reduces the objective for operation from contact to at
least 20 cm (low power and low power) or 30 cm (low power and standard power).
3.3 IrLAP
The MCP2150 supports the IrLAP protocol. The IrLAP protocol provides:

 Management of communication processes on the link between devices.

 A device-to-device connection for the reliable, ordered transfer of data.

 Device discover procedures.

 Hidden node handling.

Figure 9 identifies the key parts and hierarchy of the IrDA protocols. The bottom layer is the
Physical layer, IrPHY. This is the part that converts the serial data to and from pulses of IR
light. IR transceivers can’t transmit and receive at the same time. The receiver has to wait
for the transmitter to finish sending. This is some times referred to as a “Half-Duplex”
connection. The IR Link Access Protocol (IrLAP) provides the structure for packets (or
“frames”) of data to emulate data that would normally be free to stream back and forth.

Figure 9- IrDA Standard Protocol Layers

Figure 10 shows how the IrLAP frame is organized. The frame is proceeded by some
number of Beginning of Frame characters (BOFs). The value of the BOF is generally
0xC0, but 0xFF may be used if the last BOF character is a 0xC0. The purpose of multiple
BOFs is to give the other station some warning that a frame is coming.

The IrLAP frame begins with an address byte (“A” field), then a control byte (“C”
field). The control byte is used to differentiate between different types of frames and is also
used to count frames. Frames can carry status, data or commands. The IrLAP protocol has a
command syntax of its own. These commands are part of the control byte. Lastly, IrLAP
frames carry data. This data is the information (or “I”) field. The integrity of the frame is
ensured with a 16-bit CRC, referred to as the Frame Check Sequence (FCS). The 16-bit
CRC value is transmitted LSB first. The end of the frame is marked with an EOF character,
which is always a 0xC1. The frame structure described here is used for all versions of
IrDA protocols used for serial wire replacement for speeds up to 115.2 kbaud.

Figure 10- IrLAP frame

In addition to defining the frame structure, IrLAP provides the “housekeeping” functions
of opening, closing and maintaining connections. The critical parameters that determine
the performance of the link are part of this function. These parameters control how
many BOFs are used, identify the speed of the link, how fast either party may change from
receiving to transmitting, etc. IrLAP has the responsibility of negotiating these parameters
to the highest common set so that both sides can communicate as quickly, and as
reliably, as possible.

3.4 IrLMP
The MCP2150 implements the IrLMP protocol. The IrLMP protocol provides:

 Multiplexing of the IrLAP layer. This allows multiple channels above an

IrLAP connection.

 Protocol and service discovery. This is via the Information Access Service
(IAS).

When two devices that contain the IrDA standard feature are connected, there is generally
one device that has something to do and the other device that has the resource to do it. For
example, a laptop may have a job to print and an IrDA standard compatible printer has the
resources to print it. In IrDA standard terminology, the laptop is a Primary device and the
printer is the Secondary device. When these two devices connect, the Primary device must
determine the capabilities of the Secondary device to determine if the Secondary device is
capable of doing the job. This determination is made by the Primary device asking the
Secondary device a series of questions. Depending on the answers to these questions,
the Primary device may or may not elect to connect to the Secondary device.

The queries from the Primary device are carried to the Secondary device using IrLMP. The
responses to these queries can be found in the Information Access Service (IAS) of the
Secondary device. The IAS is a list of the resources of the Secondary device. The
Primary device compares the IAS responses with its requirements and then makes the
decision if a connection should be made. The MCP2150 identifies itself to the Primary
device as a modem.

3.5 Link Management – Information Access Service (LM-IAS)

The MCP2150 implements the LM-IAS. Each LM-IAS entity maintains an information
database to provide:

 Information on services for other devices that contain the IrDA standard
feature (Discovery).

 Information on services for the device itself.

 Remote accessing of another device’s information base.

This is required so that clients on a remote device can find configuration information
needed to access a service.

3.6 Tiny TP
Tiny TP provides the flow control on IrLMP connections. An optional service of
Segmentation and Reassembly can be handled.

3.7 IrCOMM
IrCOMM provides the method to support serial and parallel port emulation. This is useful
for legacy COM applications, such as printers and modem devices. The IrCOMM standard
is just a syntax that allows the Primary device to consider the Secondary device as a serial
device. IrCOMM allows for emulation of serial or parallel (printer) connections of
various capabilities. The MCP2150 supports the 9-wire “cooked” service class of
IrCOMM. Other service classes supported by IrCOMM are shown in Figure 11.
Figure 11-.Service classes supported by IrCOMM

3.8 Other optional IrDA data protocols

Other IrDA data protocols have been developed to specific application requirements. These
optional protocols are not supported by the MCP2150. These IrDA data protocols are briefly
described in the following sub-sections.

IrTran-P
IrTran-P provides the protocol to exchange images with digital image capture devices/cameras

IrOBEX
IrOBEX provides OBject EXchange services. This is similar to HTTP.

IrLAN
IrLAN describes a protocol to support IR wireless access to a Local Area Network (LAN).

IrMC
IrMC describes how mobile telephony and communications devices can exchange information.
This information includes phonebook, calendar and message data. Also how to control and real
time voice are handled.

IrDA Lite
IrDA Lite describes how to reduce the application code requirements, while maintaining
compatibility with the full implementation.
 4. How devices connect

When two devices implementing the IrDA standard feature establish a connection using the
IrCOMM protocol, the process is analogous to connecting two devices with serial ports
using a cable. This is referred to as a "point-to-point" connection. This connection is
limited to half-duplex operation because the IR transceiver cannot transmit and receive at
the same time. The purpose of the IrDA protocol is to allow this half-duplex link to emulate,
as much as possible, a full-duplex connection. In general, this is done by dividing the data
into “packets”, or groups of data. These packets can then be sent back and forth, when
needed, without risk of collision. The rules of how and when these packets are sent
constitute the IrDA protocols. The MCP2150 supports elements of this IrDA protocol to
communicate with other IrDA standard compatible devices.

When a wired connection is used, the assumption is made that both sides have the same
communications parameters and features. A wired connection has no need to identify
the other connector because it is assumed that the connectors are properly connected. In
the IrDA standard, a connection process has been defined to identify other IrDA
compatible devices and establish a communication link. There are three steps that these
two devices go through to make this connection. They are:

o Normal Disconnect Mode (NDM)

o Discovery Mode
o Normal Connect Mode (NCM)

4.1 Normal Disconnect Mode (NDM)

When two IrDA standard compatible devices come into range they must first recognize each
other. The basis of this process is that one device has some task to accomplish and the
other device has a resource needed to accomplish this task. One device is referred to as a
Primary device and the other is referred to as a Secondary device. This distinction between
Primary device and Secondary device is important. It is the responsibility of the
Primary device to provide the mechanism to recognize other devices. So the Primary
device must first poll for nearby IrDA standard compatible devices. During this polling, the
default baud rate of 9600 baud is used by both devices.
For example, if you want to print from an IrDA equipped laptop to an IrDA
printer, utilizing the IrDA standard feature, you would first bring your laptop in range of
the printer. In this case, the laptop is the one that has something to do and the printer
has the resource to do it. The laptop is called the Primary device and the printer is the
Secondary device. Some data-capable cell phones have IrDA standard infrared ports. If
you used such a cell phone with a Personal Digital Assistant (PDA), the PDA that
supports the IrDA standard feature would be the Primary device and the cell phone would
be the Secondary device.

When a Primary device polls for another device, a nearby Secondary device may
respond. When a Secondary device responds, the two devices are defined to be in the
Normal Disconnect Mode (NDM) state. NDM is established by the Primary device
broadcasting a packet and waiting for a response. These broadcast packets are numbered.
Usually 6 or 8 packets are sent. The first packet is number 0, the last packet is usually
number 5 or 7. Once all the packets are sent, the Primary device sends an ID packet,
which is not numbered.

The Secondary device waits for these packets and then responds to one of the packets. The
packet it responds to determines the “time slot” to be used by the Secondary device. For
example, if the Secondary device responds after packet number 2, then the Secondary
device will use time slot 2. If the Secondary device responds after packet number 0,
then the Secondary device will use time slot 0. This mechanism allows the Primary device
to recognize as many nearby devices as there are time slots. The Primary device will
continue to generate time slots and the Secondary device should continue to respond, even
if there’s nothing to do.

During NDM, the MCP2150 handles all of the responses to the Primary device
without any communication with the Host Controller. The Host Controller is inhibited by
the CTS signal of the MCP2150 from sending data to the MCP2150.

4.2 Discovery Mode

Discovery mode allows the Primary device to determine the capabilities of the
MCP2150 (Secondary device). Discovery mode is entered once the MCP2150 (Secondary
device) has sent an XID response to the Primary device and the Primary device has
completed sending the XIDs and then sends a Broadcast ID. If this sequence is not
completed, then a Primary and Secondary device can stay in NDM indefinitely. When
the Primary device has something to do, it initiates Discovery. Discovery has two parts.
They are:
o Link initialization

o Resource determination

The first step is for the Primary and Secondary devices to determine, and then adjust to,
each other’s hardware capabilities. These capabilities are parameters like:

o Data rate

o Turn around time

o Number of packets without a response

o How long to wait before disconnecting

Both the Primary and Secondary device begin communications at 9600 baud, which is the
default baud rate. The Primary device sends its parameters, then the Secondary device
responds with its parameters. For example, if the Primary supports all data rates up to
115.2 kbaud and the Secondary device only support 19.2 kbaud, the link will be established
at 19.2 kbaud.

Once the hardware parameters are established, the Primary device must determine if the
Secondary device has the resources it requires. If the Primary device has a job to print, then it
must know if it’s talking to a printer, not a modem or other device. This determination is
made using the Information Access Service (IAS). The job of the Secondary device is to
respond to IAS queries made by the Primary device. The Primary device must ask a series
of questions like:

• What is the name of your service?

• What is the address of this service?

• What are the capabilities of this device?

When all the Primary device’s questions are answered, the Primary device can access the
service provided by the Secondary device. During Discovery mode, the MCP2150
handles all responses to the Primary device without any communication with the Host
Controller. The Host Controller is inhibited by the CTS signal of the MCP2150 from sending
data to the MCP2150

4.3 Normal Connect Mode (NCM)

Once discovery has been completed, the Primary device and MCP2150 (Secondary
device) can freely exchange data. The MCP2150 can receive IR data or serial data, but
not both simultaneously. The MCP2150 uses a hardware handshake to stop the local
serial port from sending data while the MCP2150 is receiving IR data. Both the Primary
device and the MCP2150 (Secondary device) check to make sure that data packets are
received by the other without errors. Even when data is required to be sent, the
Primary and Secondary devices will still exchange packets to ensure that the connection
hasn’t, unexpectedly, been dropped. When the Primary device has finished, it then
transmits the close link command to the MCP2150 (Secondary device). The MCP2150
will confirm the close link command and both the Primary device and the MCP2150
(Secondary device) will revert to the NDM state. It is the responsibility of the Host
Controller program to understand the meaning of the data received and how the program
should respond to it. It’s just as if the data were being received by the Host Controller
from a UART.
 Figure 12. How devices connect

4.4 Operation
The MCP2150 emulates a null modem connection. The application on the DTE device sees a
virtual serial port. This serial port emulation is provided by the IrDA standard protocols. The
link between the DTE device and the embedded application is made using the
MCP2150. The connection between the MCP2150 and the embedded application is wired
as if there were a null modem connection. The Carrier Detect (CD) signal of the MCP2150
is used to indicate that a valid IrDA standard infrared link has been established between the
MCP2150 and the Primary device. The CD signal should be monitored closely to make
sure that any communication tasks can be completed. The MCP2150 DSR signal indicates
that the device has powered-up, successfully initialized and is ready for service. This signal
is intended to be connected to the DSR input of the Host Controller. If the Host Controller
was directly connected to an IrDA standard Primary device using a serial cable (the
MCP2150 is not present), the Host Controller would be connected to the Primary device’s
DTR output signal.

The MCP2150 generates the CTS signal locally because of buffer limitations.

Hardware handshaking:

The MCP2150 uses a 64-byte buffer for incoming data from the IR Host. Another 64-byte
buffer is provided to buffer data from the UART serial port. When an IR packet begins
the IrCOMM, the MCP2150 handles IR data exclusively (the UART serial port buffer is
not available). A hardware handshaking pin (CTS) is provided to inhibit the Host
Controller from sending serial data while IR Data is being sent or received.

Buffers and Throughput:

The maximum IR data rate of the MCP2150 is 115.2 kbaud. The actual throughput
will be less, due to several factors. The most significant factors are under the control of the
developer. One factor beyond the control of the designer is the overhead associated with
the IrDA standard. The MCP2150 uses a fixed data block size of 64 bytes. To carry 64
bytes of data, the MCP2150 must send 72 bytes (64+8). The additional 8 bytes are used by
the protocol. When the Primary device receives the frame, it must wait for a minimum
latency period before sending a packet of its own. This turnaround time is set by IrLAP when
the parameters of the link are negotiated. A common turnaround time is 1 ms, although
longer and shorter times may be encountered. 1 ms represents approximately 12 byte
times at a data rate of 115.2 kbaud. The minimum size frame the Primary device can
respond with is 6 bytes. The MCP2150 will add the 12 byte-time latency on its own, again
assuming a 1 ms latency. This means that the maximum throughput will be 64 data bytes out
of a total of 64 + 38 byte times. Thus, the maximum theoretical throughput will be limited to
about 64/(64+38)=63% of the IR data rate. Actual maximum throughput will be dependent
on both the MCP2150 and the characteristics of the Primary device. The most
significant factor in data throughput is how well the data frames are filled. If only 1 byte is
sent at a time, then the maximum throughput is 1/(1+38)=2.5% of the IR data rate. The best
way to maximize through- put is to align the amounts of data with the packet size of the
MCP2150.

Turnaround Latency:

An IR link can be compared to a one-wire data connection. The IR transceiver can

transmit or receive, but not both at the same time. A delay of one bit time is
recommended between the time a byte is received and another byte is
transmitted.

IR Port Baud Rate:

The baud rate for the MCP2150 IR port (the TXIR and RXIR pins) is, initially, at the default
rate of 9600 baud. The Primary device determines the maximum baud rate that the
MCP2150 will operate at. This information is used during NDM, with the Primary device
setting the baud rate of the IR link. The maximum IR baud rate is not required to be the
same as the MCP2150’s serial port (UART) baud rate (as determined by the
BAUD1:BAUD0 pins).

4.5 Programmable Device ID

The MCP2150 has a flexible feature that allows the MCP2150 Device ID to be changed
by the Host Controller. The default ID is “Generic IrDA” and is stored in non-volatile,
electrically erasable programmable memory (EEPROM). The maximum ID String length is
19 bytes. The format of the ID EEPROM is shown in Figure 13. The ID String must
only contain the ASCII characters from 20h to 7Ah (inclusive). The MCP2150 enters into ID
String programming when it exits the reset state and detects that the DTR pin is high and the
RTS pin is low.

A Host Controller connected to the MCP2150 would, typically, perform the following
steps to place the MCP2150 into ID String programming mode:

1. Force the MCP2150 into reset (RESET pin forced low).

2. Force the DTR pin high and the RTS pin low.
3. Release the MCP2150 from reset (RESET pin forced high).
 4. Wait for device to complete initialization

Figure 13- ID string format

4.6. Interfacing The MCP2150 to Host Controller
The Host UART interface includes non-data Flow Control signals. These are the signals
between a Host Controller and a MCP2150 device. The embedded system is comprised
of an Optical Transceiver circuit, a MCP2150 device and a Host Controller. This
typical embedded system implementation is shown in Figure 13.

Figure 13: Embedded system

4.7 Host UART flow control

The MCP2150 uses up to eight signals for the Host UART interface, described in Table 1.
In addition to the UART Transmit and Receive functions (the TX and RX signals), there
are three important functions associated with flow control. These functions do the following:
 1. Indicates when the IR link is “established” (the CD signal on the MCP2150).
2. Indicates when the Host Controller can transmit data to the MCP2150 (the CTS
signal).
3. Indicates when the Host Controller can receive data from the MCP2150 (the RTS
signal).
The DTR, DSR and RI signals are not associated with the Host UART Interface flow
control. Depending on the MCP2150 device, these signals may indicate device status
information over the IR link or the signal may not have a function

4.8 Establishing a Link

Until the MCP2150 device has established a link with a Primary device, the Host UART
Interface is essentially “non-operational”. That is, the Host Controller should not send data
(the CTS signal will not be active) and the Host Controller will not receive data (even with
the RTS signal driven active by the Host Controller).

The IR link is “established” once the MCP2150 device has completed Discovery mode
(with a Primary device). If the “IR Link is Established” signal does not become active,
the Primary device has not completed the discovery phase with the MCP2150.

MCP2150 (THE CD SIGNAL)

The CD signal is an output from the MCP2150 and indicates that the Primary device and
the MCP2150 have “Established an IR Link”. That is, they have completed Discovery
phase of the IrDA Standard and the MCP2150 is in Normal Response Mode (NRM).
Therefore, the IR link is open and data may be transmitted between the Primary and
Secondary devices (MCP2150 embedded system). The CD signal will be active (driven
low) as long as the IR link is open. Once the IR link has been closed, the CD signal will be
driven inactive.
4.9 Data From Host Controller to MCP2150

(CTS Operation)

The CTS signal is an output from the MCP2150 device and is used to indicate when the
Host Controller may transmit data on the Host UART. The MCP215X device operation
requires that communication only occur on the MCP2150’s IR Interface or Host UART
Interface at a given time. The MCP2150 will indicate when the Host Controller can
communicate on the Host UART via the CTS signal. When an IR packet begins
(IrCOMM), the MCP2150 handles IR data exclusively and the MCP2150 Host UART
Interface is not available. The CTS signal indicates when the Host Controller can send
serial data and when the Host Controller should not send serial data, since
asynchronous IR Data is being sent or received.
The MCP2150 uses a 64-byte buffer for incoming data from the Host UART serial port.
When the CTS signal is driven active (low), the 64-byte buffer is clear and can receive up
to the maximum 64-byte buffer space. When the CTS signal is driven low, this indicates
the beginning of the UART Receive Buffer’s “Receive Data Window” (the UART Receive
Buffer is empty). This Receive Data Window is 11.9 ms and is “closed” early if the
UART Receive Buffer receives 64 bytes before the 11.9 ms is complete.

(RTS Operation)

When the Host Controller drives the RTS signal active, the MCP2150 is allowed to transmit
data contained in the IR Receive buffer to the Host Controller. The Host Controller should
use this signal to inhibit the MCP2150 from sending data when the Host Controller
does not have the processing bandwidth to “handle” the received data. In many
applications, the Host Controller will not have bandwidth issues, and the RTS signal can be
tied active (low).

When data is in the MCP2150 IR Receive Buffer and RTS is high, the MCP2150 will ignore
the RXIR pin (IR Receive). This means that the IrDA Standard Hand- shaking packets
from the Primary device are not responded to. If the Host Controller does not drive the
RTS signal active (low) by a given time, the Primary device will see the non-response from
the MCP2150 as an “obstruction” and may shut down the link (dependant on the Primary
device used). If the IrDA link is lost due to the MCP2150 not being able to transfer the
“data” to the Host Controller (MCP2150 is waiting for the RTS signal to be driven
low), the MCP2150 will continue to drive CD active (low), which is helpful determining
the cause of the lost link.

4.10. MCP215X/40 developers daughter board

The MCP215X/40 Developer‘s Daughter Board is used to evaluate and demonstrate the
MCP2150 IrDA® Standard Protocol Handler with Encoder/Decoder devices. This allows the
system designer to implement a low-cost, wireless IR port in any application providing support
for IrDA standard bit encoding/ decoding.
The MCP215X/40 Developer‘s Daughter Board is designed to interface to several of the —new“
low-cost PICmicro® microcontroller-based demonstration (demo) boards, or to be interfaced
into your application. Multiple header interfaces are available that allow support for the many
different PICDEM™ Demo Boards, as well as being easily jumpered into systems for
development purposes. Depending on the features of the PICmicro Microcontroller Unit (MCU)
and the selected demo board, the MCP215X/MCP2140 TX and RX signals can either be
connected (jumpered) directly to the RS-232 line driver or to the PICmicro MCU‘s RX and TX
signals. The PICmicro MCU could process that data and then send it out of the UART.

4.11 Installation and Operation

Here we discusses the operation of the MCP215X/40 Developer‘s Daughter Board and how it
can be used in conjunction with some of Microchip‘s low-cost PICDEM™ Demo Boards or
easily connected to your system. When the MCP215X/40 Developer‘s Daughter Board is used in
conjunction with one of the low-cost PICDEM™ Demo Boards, it demonstrates the
implementation of an embedded system with an IrDA® standard protocol handler with
encoder/decoder. A Primary Device (PC with IR port, PDA, etc.) is required to demonstrate the
operation of this embedded system. The Host UART interface includes the data signals (TX and
RX) and the flow control signals (CTS, RTS, CD, DSR, DTR and RI).
The below table will show the system hardware requirements.
5. Using the MCP215X/40 Developer‘s Daughter Board with the
PICDEM™ HPC Explorer Demo Board

To perform a demonstration of the MCP215X/40 Developer‘s Daughter Board, two systems

are needed. A Primary Device and a Secondary Device (the embedded system).The embedded
system (Secondary Device) is a MCP215X/40 Developer‘s Daughter Board plus the PICDEM
HPC Explorer Demo Board. The Primary Device is either a PC with IR Port (or IR Dongle) or
a PDA. The PC Demos using HyperTerminal shows all three PICDEM HPC Explorer Demo
Board program modes, while those using the Application Note programs only show the Data
Logger (250 Byte) program mode. PC Demos using HyperTerminal.
Figure 14- System Block Diagram

5.1 PC Demos using HyperTerminal

When using a PC with HyperTerminal as the Primary Device interface, all three PICDEM HPC
Explorer Demo Board programs can be demonstrated. These are shown in:

-Demo #1 Operation - 250 Byte Transfer Mode“

-Demo #2 Operation - Echo Mode“.
-Demo #3 Operation - Direct to UART (DB-9) Mode“.

5.2 DEMO #1 Operation - 250 byte transfer mode

In Demo #1, the System 2 unit will receive a character and then stream 250 bytes of data (25
lines of 8 alphanumeric characters plus the return and line feed characters, for a total of 10
characters per line).
The System #1 unit is connected to the PC, while the System #2 unit is not required to be
connected, though it still needs to be powered. The PICDEM HPC Explorer Demo Board is used
to determine the communication baud rate (115,200) via the JP2 and JP1 jumper states. Given
this state, the PICmicro® MCU can then configure the MCP2150 UART baud rate. Power is
supplied over the H1 and H2 interface headers. Jumpers JP3 and JP4 are used to select which
demo program to run. Below table shows the steps for Demo #1.

Figure 15
DEMO#1 STEPS
5.3 DEMO #2 Operation – Echo mode

In Demo #2, the System #2 unit will echo any alpha character received, changing the case of the
character (lowercase to uppercase/uppercase to lowercase). The System #1 unit is connected to
the PC, while the System #2 unit is not required to be connected, though it still needs to be
powered. The PICDEM HPC Explorer Demo Board is used to determine the communication
baud rate (115,200) via the JP2 and JP1 jumper states. Given this state, the PICmicro MCU can
then configure the MCP2150 UART baud rate. Power is supplied over the H1 and H2 interface
headers. Jumpers JP3 and JP4 are used to select which demo program to run. Below table shows
the steps for Demo #2.

Figure 16
DEMO#2 STEPS
5.4 DEMO #3 Operation – Direct to UART (DB9) mode

In Demo #3, the MCP215X/40 Developer‘s Daughter Board will communicate directly to the
PICDEM HPC Explorer Demo Board‘s DB-9 connector (and then to the PC). The PICDEM
HPC Explorer Demo Board is used to determine the communication baud rate (9600) via the JP2
and JP1 jumper states. Given this state, the PICmicro MCU can then configure the MCP2150
UART baud rate. Power is supplied over the H1 and H2 inter- face headers. Jumpers JP3 and JP4
are used to select which demonstration program to run.
Below table shows the steps for Demo #3 operation

Figure 17
DEMO#3 STEPS

5.5. Configuring the HyperTerminal program

In running a demo, the HyperTermial program can be used on both the Primary Device and for
the Secondary Device. The configuration of HyperTerminal is different depending if
HyperTerminal is communicating as the Primary Device or as the Secondary Device. To use a
Laptop PC with an IrDA standard port as the Primary Device, the application program must
connect to the IR port. Some standard Window programs may not be able to connect directly to
the IR port (OS-specific). For a Windows® XP (or Windows 2000) system, a 3rd-party driver
needs to be installed to create“ the virtual port“ that HyperTerminal needs to connect to that
allows it to use the IR port for communications. This driver is called IrCOMM2K and is
available at www.IRCOMM2K.de. Please evaluate this product before installing it on your
system to ensure that it will meet your requirements.

Microchip does not imply any suitability to your system requirements of any of these 3rd-party
products. Please evaluate each product‘s specifications and requirements before installing them
on your system. Once the IrCOMM2K driver is installed, it creates a —new“ com port (such as
COM7). This is a virtual serial port that the PC Terminal Emulation application program (such as
HyperTerminal) can be connected to. To ensure that the PC is able to communicate to the
PICDEM HPC Explorer Demo Board plus MCP215X/40 Developer‘s Daughter Board, the
HyperTerminal program must be properly configured. This section describes how the
HyperTerminal program should be configured.
 6. What is embedded system

A combination of computer hardware and software, and perhaps additional mechanical or other
parts, designed to perform a dedicated function. In some cases, embedded systems are part of a
larger system or product, as in the case of an antilock braking system in a car. Contrast with
general-purpose computer typically an embedded system consists of a single-board
microcomputer with software in ROM, which starts running a dedicated application as soon as
power is turned on and does not stop until power is turned off.

6.1 Advantages of Embedded system

 Reduced cost.
 A rich feature of PIC18F452 enables the system to consume lowest power.
 Reprogrammable while in the target board.
 Portable and compact size.

6.2 CISC versus RISC

Many processors are called RISC (reduced instruction set computers), as there is a perception
that RISC is faster than CISC (complex instruction set computers) because the instructions they
execute are small and tailored to specific tasks required by the application. CISC instructions
tend to be large and perform functions that the processor designer believes will be best suited for
the application they will be used for. When for a specific application, you will be the choice
between RISC, CISC processors.
Both are better according to the applications in which either one of the design methodologies is
more efficient. A well designed RISC processor has small instruction set, which can be very easy
to memorize. A CISC instruction set provides high level functions that are easy to implement and
do not require the programmer to be intimately familiar with the processors architecture. For new
programmers, a CISC processor will be easier to code, but for an experienced programmer, a
RISC processor will actually be easier to create complex code. Proponents of the methodologies
will push different advantages, but when you get right down to it neither is substantially better
than the other.
RISC processor has the ability to access all the registers in a single instruction. This ability to
access all the registers in the processor as if they were the same is known as orthogonality and
provides some unexpectedly powerful and flexible capabilities to applications. The PIC micro
controllers are orthogonal.

7. Introduction to PIC Micro controller

The micro controller is a very common component in modern electronic systems. Its use is so
widespread that it is almost impossible to work in electronics without coming across it. Micro
controllers are used in a wide number of electronic systems such as:
 Keyboard of a PC.
 Electronic measurement instruments (such as digital multimeters,
frequency synthesizers, and oscilloscopes)
 Printers.
 Mobile phones.
 Televisions, radios, CD players, tape recording equipment.
 Hearing aids.
 Engine management systems in automobiles.

Security alarm systems, fire alarm systems, and building services systems

7.1 PIC Families:

Memory technology has no effect on the logical operation of a device. When discussing the
functionality of the device, the memory technology and the voltage range do not matter.
Microchip offers three program memory types:
 ROM devices, identified with the letter CR, as in PIC18CRxxx.
 EPROM devices, identified with the letter C, as in PIC86Cxxx.
 FLASH devices, identified with the letter F, as in PIC18Fxxx..

7.2 Flash Memory Devices

These devices are electrically erasable, and are offered in a low cost plastic package. Being
electrically erasable, these devices can be both erased and reprogrammed without removal from
the circuit. A device will have the same specifications whether it is used for prototype
development, pilot programs, or production. These are the best for development, because
memory can be erased and reprogrammed in few seconds, allowing extensive test and debug of
the software. Such devices have a typical life of 100.000 erase/write cycles.
7.3 Logical Families:

PIC micro devices are grouped by the size of their Instruction Word. The three current PIC micro
families are:
 1. Base-Line: 12-bit Instruction Word length
2. Mid-Range: 14-bit Instruction Word length
3. High-End: 16-bit Instruction Word length

PIC12 Family: 8-pin 12-bit/14-bit program word

PIC16C5x Family: 12-bit program word
PIC16xxxx Family: 14-bit program word
PIC17Cxxx Family: 16-bit program word

7.4 Introduction to PIC18f8722

The PIC18F8722 micro controller is actually one of a family of parts distinguished from each
other on the basis of the number of pins available for inputs and outputs.
The use of the various features of this chip enables the designed system to be more efficient. For
now, it is enough to understand that this chip has a rich feature set, permitting it to meet a wide
range of applications.

As can be seen from the figure 18 that each pin of micro controller is having multiple functions.
Figure 18 showing pin diagram of PIC18f8722

7.5 New Core Features

nanoWatt TECHNOLOGY

All of the devices in the PIC18F8722 family incorporate a range of features that can significantly
reduce power consumption during operation. Key items include:
• Alternate Run Modes: By clocking the controller from the Timer1 source or the internal
oscillator block, power consumption during code execution can be significantly reduced.
• Multiple Idle Modes: The controller can also run with its CPU core disabled but the
peripherals still active. In these states, power consumption can be reduced even further.
• On-the-fly Mode Switching: The power managed modes are invoked by user code during
operation, allowing the user to incorporate power saving ideas into their application’s software
design.
• Low Consumption in Key Modules: The power requirements for both Timer1 and the
Watchdog Timer are minimized.

EXPANDED MEMORY
The PIC18F8722 family provides ample room for application code and includes members with
48, 64, 96 or 128 Kbytes of code space.

• Data RAM and Data EEPROM: The PIC18F8722 family also provides plenty of room for
application data. The devices have 3936 bytes of data RAM, as well as 1024 bytes of data
EEPROM, for long term retention of nonvolatile data.

• Memory Endurance: The Enhanced Flash cells for both program memory and data EEPROM
are rated to last for many thousands of erase/write cycles, up to 100,000 for program memory
and 1,000,000 for EEPROM. Data retention without refresh is conservatively estimated to be
greater than 40 years.

MULTIPLE OSCILLATOR OPTIONS AND FEATURES

All of the devices in the PIC18F8722 family offer ten different oscillator options, allowing users
a wide range of choices in developing application hardware. These include:

• Four Crystal modes, using crystals or ceramic resonators

• Two External Clock modes, offering the option of using two pins (oscillator input and a divide-
by-4 clock output) or one pin (oscillator input, with the second pin reassigned as general I/O)
• Two External RC Oscillator modes with the same pin options as the External Clock modes
• An internal oscillator block which provides an 8 MHz clock and an INTRC source
(approximately 31 kHz), as well as a range of 6 user selectable clock frequencies, between 125
kHz to 4 MHz, for a total of 8 clock frequencies. This option frees the two oscillator pins for use
as additional general purpose I/O.
• A Phase Lock Loop (PLL) frequency multiplier, available to both the high-speed crystal and
internal oscillator modes, which allows clock speeds of up to 40 MHz. Used with the internal
oscillator, the PLL gives users a complete selection of clock speeds, from 31 kHz to 32 MHz –
all without using an external crystal or clock circuit. Besides its availability as a clock source, the
internal oscillator block provides a stable reference source that gives the family additional
features for robust operation:

• Fail-Safe Clock Monitor: This option constantly monitors the main clock source against a
reference signal provided by the internal oscillator. If a clock failure occurs, the controller is
switched to the internal oscillator block, allowing for continued low-speed operation or a safe
application shutdown.

• Two-Speed Start-up: This option allows the internal oscillator to serve as the clock source
from Power-on Reset, or wake-up from Sleep mode, until the primary clock source is available.

EXTERNAL MEMORY INTERFACE

In the unlikely event that 128 Kbytes of program memory is inadequate for an application, the
PIC18F8527/8622/8627/8722 members of the family also implement an external memory
interface. This allows the controller’s internal program counter to address a memory space of up
to 2 Mbytes, permitting a level of data access that few 8-bit devices can claim. With the addition
of new operating modes, the external memory interface offers many new options, including:
• Operating the microcontroller entirely from external memory
• Using combinations of on-chip and external memory, up to the 2-Mbyte limit
• Using external Flash memory for reprogrammable application code or large data tables
• Using external RAM devices for storing large amounts of variable data
EASY MIGRATION

Regardless of the memory size, all devices share the same rich set of peripherals, allowing for a
smooth migration path as applications grow and evolve. The consistent pinout scheme used
throughout the entire family also aids in migrating to the next larger device. This is true when
moving between the 64-pin members, between the 80-pin members, or even jumping from 64-
pin to 80-pin devices.

7.6 Other Special Features

• Communications: The PIC18F8722 family incorporates a range of serial communication

peripherals, including 2 independent Enhanced USARTs and 2 Master SSP modules capable of
both SPI and I2C (Master and Slave) modes of operation. Also, one of the general purpose I/O
ports can be reconfigured as an 8-bit Parallel Slave Port for direct processor-to-processor
communications.

• CCP Modules: All devices in the family incorporate two Capture/Compare/PWM (CCP)
modules and three Enhanced CCP (ECCP) modules to maximize flexibility in control
applications. Up to four different time bases may be used to perform several different operations
at once. Each of the three ECCP modules offer up to four PWM outputs, allowing for a total of
12 PWMs. The ECCPs also offer many beneficial features, including polarity selection,
Programmable Dead-Time, Auto-Shutdown and Restart and Half-Bridge and Full-Bridge Output
modes.

• Self-Programmability: These devices can write to their own program memory spaces under
internal software control. By using a bootloader routine located in the protected boot block at the
top of program memory, it becomes possible to create an application that can update itself in the
field.

• Extended Instruction Set: The PIC18F8722 family introduces an optional extension to the
PIC18 instruction set, which adds 8 new instructions and an Indexed Addressing mode. This
extension, enabled as a device configuration
option, has been specifically designed to optimize re-entrant application code originally
developed in high-level languages, such as C.

• 10-bit A/D Converter: This module incorporates programmable acquisition time, allowing for
a channel to be selected and a conversion to be initiated without waiting for a sampling period
and thus, reduce code overhead.

• Extended Watchdog Timer (WDT): This enhanced version incorporates a 16-bit prescaler,
allowing an extended time-out range that is stable across operating voltage and temperature
 8. Results & Conclusions

All the three demos using HyperTerminal were tested.:

 -Demo #1 Operation - 250 Byte Transfer Mode“

 -Demo #2 Operation - Echo Mode“.

 -Demo #3 Operation - Direct to UART (DB-9) Mode“.

9. Future scope

Embedded wireless communication using IrDA standard protocols are widely used in day today
life. Many more embedded projects are in process using this IrDA protocols. It is proposed for
replacing RS 232.
 Appendix

1. Development tools

---- Introduction to MPLAB IDE software

MPLAB Integrated Development Environment (IDE) is a free, integrated toolset for the
development of embedded applications employing Microchip's PIC micro ® and dsPIC® micro
controllers. MPLAB IDE runs as a 32-bit application on MS Windows®, is easy to use and
includes a host of free software components for fast application development and super-charged
debugging. MPLAB IDE also serves as a single, unified graphical user interface for additional
Microchip and third party software and hardware development tools. Moving between tools is a
snap, and upgrading from the free simulator to MPLAB ICD 2 or the MPLAB ICE emulator is
done in a flash because MPLAB IDE has the same user interface for all tools.
MPLAB IDE is an easy-to-learn and use Integrated Development Environment (IDE). The IDE
provides firmware development engineers the flexibility to develop and debug firmware for
Microchip’s PIC micro MCU families. MPLAB IDE runs under Microsoft Windows 3.1x and
higher.

MPLAB IDE provides functions that allow you to:

 Assemble, compile, and link source code

 Debug the executable logic by watching program flow with the simulator, or in real-time
with the MPLAB ICE 2000 emulator or MPLAB ICD debugger
 Make timing measurements
 View variables in watch windows
 Program firmware with PICSTART Plus or PRO MATE II programmers
 Create and edit source files
 Group files into projects
 Debug source code using Emulator and simulator
MPLAB IDE allows you to create and edit source code by providing you with a full-featured text
editor. Further, you can easily debug source code with the aid of a Build results window that
displays the errors found by the compiler, assembler, and linker when generating executable
files.
A Project Manager allows you to group source files, precompiled object files, libraries and linker
script files into a project format. MPLAB IDE also provides feature-rich simulator and emulator
environments to debug the logic of executables.
The following figure shows the an example MPLAB IDE project

Fig 10 shows file generation

Salient features of MPLAB

Some of the features are:

 A variety of windows allowing you to view the contents of all data and program memory
locations
 Source Code, Program Memory, and Absolute Listing windows allows you to view the
source code and its assembly-level equivalent separately and together (Absolute Listing)
 The ability to step through execution, or apply Break, Trace, Standard or complex trigger
Points.

The MPASM assembler, the MPLINK object linker and the MPLIB object librarian are typically
used together under MPLAB IDE to provide GUI development of application code for PIC micro
MCU devices.

MPLAB IDE Development Tools:

MPLAB IDE integrates several tools to provide a complete development environment.

MPLAB Project Manager

Use the Project Manager to create a project and work with the specific files related to the project.
When using a project, you can rebuild source code and download it to the simulator or emulator
with a single mouse click.

MPLAB Editor
Use the MPLAB Editor to create and edit text files such as source files, code, and linker script
files.

MPLAB ICD In-Circuit Debugger

The MPLAB ICD In-Circuit Debugger is a powerful, low-cost development and evaluation kit
for many PIC micro MCU FLASH devices.

MPLAB SIM Simulator

The software simulator models the instruction execution and I/O of the PIC micro MCU’s.

MPLAB ICE 2000 In-Circuit Emulator

The MPLAB ICE 2000 emulator uses hardware to provide real-time emulation of PIC micro
MCUs, either with or without a target system.

MPASM™ Assembler/MPLINK™ Linker/MPLIB™ Librarian

The MPASM assembler allows source code to be assembled without leaving MPLAB IDE. The
MPLINK linker creates the final application by linking relocatable modules from MPASM,
MPLAB C17 and MPLAB 18 C Compilers. The MPLIB librarian manages custom libraries for
maximum code reuse.

MPLAB CXX C Compilers

The MPLAB C17 and MPLAB C18 C Compilers provide ANSI-based high level source code
solutions. Complex projects can use a combination of C and assembly source files to obtain the
maximum benefits of speed and maintainability.

PRO MATE® II and PICSTART® Plus Programmers

Develop code with the simulator or an emulator, assemble or compile it, then use one of these
tools to program devices. This can all be accomplished with MPLAB IDE. Although the PRO
MATE II programmer does not require MPLAB IDE to operate, programming is easier using
MPLAB IDE.

PICMASTER® and PICMASTER CE Emulators

MPLAB IDE provides legacy support for the PICMASTER and PICMASTER CE emulators.

Third Party Tools

Many other companies have development tools for Microchip products that work with MPLAB
IDE. Good compatibility for third party tools.

Some features of MPLAB IDE

  Fully integrated debugging with right mouse click menus for breakpoints and
editor functions
 Tabbed editor option or separate source windows
 International language Unicode support
 Recordable macros
 Context sensitive color highlighting
 Choice of fonts
 Adjustable tab size
 Custom tool bars
 Auto indent
 Tab to space conversion
 Brace match
 Comment/uncomment block
 Bookmarks

Components of MPLAB IDE:

 Programmer’s text editor

 MPLAB SIM, high speed software simulator for PIC micro and dsPIC MCUs with
peripheral simulation, complex stimulus injection and register logging
 Full featured debugger
 Graphical project manager
 Visual Device Initializer (VDI)
 Version control support for MS Source Safe, CVS, PVCS, Subversion
 MPASM™ macro assembler with MPLINK™ linker and MPLIB™ librarian
 MPLAB ASM30 assembler, MPLAB LINK30 and Utilities for PIC24 and dsPIC devices
 PROCMD command line programmer for MPLAB PM3 and PRO MATE® II
 Visual PROCMD for simplified GUI control of MPLAB PM3 and PRO MATE®
 CCS PCB C Compiler
 Many Powerful Plug-ins: AN851 Boot loader programmer, AN901 BLDC Motor Control
Interface, AN908 ACIM Tuning Interface, KeeLoq, Data Monitor and Control, CMX
Scheduler and RTOS viewer.
Simple, powerful source level debugging:

 Auto alignment of breakpoints after source code modification

 Mouse-over variable inspection
 Drag and drop variables to watch windows
 Watch variables, structures and arrays
 Mixed source code/disassembly view
 Stack symbolic return label display
 Automatic single-step "animate" feature
 Pass counts and break on PIC18F, PIC24 and dsPIC file register R/W for MPLAB ICD 2
 Step-Out-Of function
 Watch windows support structures, enums and structure members
 Custom hot keys
 Powerful simulator stimulus generator
 Trace to source correlation

MPLAB v7.41 Interim:

These new features are available in the interim release, MPLAB IDE v7.41:
 KeeLoq plug-in allows hex file generation from MPLAB IDE for KeeLoq programming
in Visual PROCMD.
 AN851-compliant "Quick Programmer" for PIC18 devices (beta) for implementation of
device self-programming via MPLAB IDE as detailed in Microchip Application Note
AN851.
 The Data Monitor and Control Interface (DMCI) allows variables to be fine tuned while
the application is running.
 The Project Manager displays symbols and labels from the assembler.
 The Project Manager can use files outside the project directory structure to be included in
the project using a relative path.
 MPLAB IDE now includes a free copy of the CCS PCB C Compiler.
 CodeGuardTM security for 16-bit device’s on-chip advanced code protection features.
 New device support –
 2. Flow charts
Figure 7: MCP2150 Application Flowchart

Initialize PIC18f8722

 Ports

 USART
-BRGH =1
-8 – bit
-TX Enabled
-Asynchronous Operation
-Continuous Receive
Figure 8: MCP flow control flow chart
Figure 9: MCP2150 flow control flow chart- transmit
Figure 10: MCP flow control flow chart- receive
3. Components list
  MCP215X/40 developers daughter board
 PICDEM HPC explorer demo board
 Adapter
 IR dongle
 IrCOMM driver software
 MPLAB software
 In Circuit Debugger

4. References and bibilography

www. Microchip.com
www.irda.org
PIC micro controller by Myke Predko