Overview of PIC 16F877

PIC 16F877 is one of the most advanced microcontroller from Microchip. This controller is widely
used for experimental and modern applications because of its low price, wide range of applications,
high quality, and ease of availability. It is ideal for applications such as machine control applications,
measurement devices, study purpose, and so on. The PIC 16F877 features all the components
which modern microcontrollers normally have

General Features
o High performance RISC CPU.
o ONLY 35 simple word instructions.
o All single cycle instructions except for program branches which are two cycles.
o Operating speed: clock input (200MHz), instruction cycle (200nS).
o Up to 3688bit of RAM (data memory), 2568 of EEPROM (data memory),
8k14 of flash memory.
o Pin out compatible to PIC 16C74B, PIC 16C76, PIC 16C77.
o Eight level deep hardware stack.
o Interrupt capability (up to 14 sources).
o Different types of addressing modes (direct, Indirect, relative addressing modes).
o Power on Reset (POR).
o Power-Up Timer (PWRT) and oscillator start-up timer.
o Low power- high speed CMOS flash/EEPROM.
o Fully static design.
o Wide operating voltage range (2.0 5.56)volts.
o High sink/source current (25mA).
o Commercial, industrial and extended temperature ranges.
o Low power consumption (<0.6mA typical @3v-4MHz, 20A typical @3v-32MHz
and <1 A typical standby).
Peripheral Features
o Timer 0: 8 bit timer/counter with pre-scalar.
o Timer 1:16 bit timer/counter with pre-scalar.
o Timer 2: 8 bit timer/counter with 8 bit period registers with pre-scalar and postscalar.

o Two Capture (16bit/12.5nS), Compare (16 bit/200nS), Pulse Width Modules

(10bit).
o 10bit multi-channel A/D converter
o Synchronous Serial Port (SSP) with SPI (master code) and I2C (master/slave).
o Universal Synchronous Asynchronous Receiver Transmitter (USART) with 9 bit
address detection.
o Parallel Slave Port (PSP) 8 bit wide with external RD, WR and CS controls
(40/46pin).
o Brown Out circuitry for Brown-Out Reset (BOR).
Key Features
o Maximum operating frequency is 20MHz.
o Flash program memory (14 bit words), 8KB.
o Data memory (bytes) is 368.
o EEPROM data memory (bytes) is 256.
o 5 input/output ports.
o 3 timers.
o 2 CCP modules.
o 2 serial communication ports (MSSP, USART).
o PSP parallel communication port
o 10bit A/D module (8 channels)
Analog Features
o 10bit, up to 8 channel A/D converter.
o Brown Out Reset function.
o Analog comparator module.
Special Features
o 100000 times erase/write cycle enhanced memory.
o 1000000 times erase/write cycle data EEPROM memory.
o Self programmable under software control.
o In-circuit serial programming and in-circuit debugging capability.
o Single 5V,DC supply for circuit serial programming
o WDT with its own RC oscillator for reliable operation.

o Programmable code protection.

o Power saving sleep modes.

Selectable oscillator options.

PIC16F887 BASIC FEATURES

RISC architecture
o

Only 35 instructions to learn

All single-cycle instructions except branches

Operating frequency 0-20 MHz

Precision internal oscillator

Factory calibrated

Software selectable frequency range of 8MHz to 31KHz

Power supply voltage 2.0-5.5V

o

Consumption: 220uA (2.0V, 4MHz), 11uA (2.0 V, 32 KHz) 50nA (standby mode)

Power-Saving Sleep Mode

Brown-out Reset (BOR) with software control option

35 input/output pins

High current source/sink for direct LED drive

software and individually programmable pull-up resistor

Interrupt-on-Change pin

8K ROM memory in FLASH technology

o

In-Circuit Serial Programming Option

o

Chip can be reprogrammed up to 100.000 times

Chip can be programmed even embedded in the target device

256 bytes EEPROM memory

o

Data can be written more than 1.000.000 times

368 bytes RAM memory

A/D converter:

14-channels

10-bit resolution

3 independent timers/counters

Watch-dog timer

Analogue comparator module with

o

Two analogue comparators

Fixed voltage reference (0.6V)

Programmable on-chip voltage reference

PWM output steering control

Enhanced USART module

Supports RS-485, RS-232 and LIN2.0

Auto-Baud Detect

Master Synchronous Serial Port (MSSP)

o

supports SPI and I2C mode

So what is a Watchdog Timer?

Suppose you have written a program that is continuously running on a PIC. Now, you want to
make sure that this program is always running, and that no matter what happens it will never
stop. The first thing you would have, of course, is a loop back at the end of the program that
brings us back to the start of the program. But consider this case. Let us say that the PIC is
monitoring an input. When this input goes high, it jumps to another part of the program and waits
for another pin to go high. If the second pin doesnt go high, the PIC will just sit there and wait. It
will only exit if the second pin goes high. Let us consider another example. Suppose you have
written a program. You have compiled it successfully, and you have even simulated it over and
over again using a simulator such as MPLAB. Everything seems to work fine. You program the
PIC and place it into a circuit. However after a long period of time, the program gets stuck
somewhere and the PIC gets caught in a loop. Whats needed in both cases is some kind of
reset if the program gets stuck. This is the purpose of a watchdog circuit.
A watchdog circuit is nothing new. Many microprocessors and microcontrollers have them. But
how does it work? Well, inside the PIC there is a resistor/capacitor network. This provides a
unique clock, which is independent of any external clock that you provide in your circuit. Now,
when the Watchdog Timer (abbreviated to WDT) is enabled, a counter starts at 00 and
increments by 1 until it reaches FF. When it goes from FF to 00 (which is FF + 1) then the PIC will
be reset, irrespective of what it is doing. The only way we can stop the WDT from resetting the
PIC is to periodically reset the WDT back to 00 throughout our program. Now you can see that if
our program does get stuck for some reason, then the WDT will not be set. The WDT will then
reset the PIC, causing our program to restart from the beginning.

In order to use the WDT, we need to know three things. First, how long have we got before we
need to reset the WDT, secondly how do we clear it. Finally, we have to tell the PIC programming
software to enable the WDT inside the PIC. Lets look at these separately.

he general schematic diagram of 8051 microcontroller is shown above. We can see 3 system inputs,
3 control signals and 4 ports (for external interfacing). A Vcc power supply and ground is also
shown.. System inputs are necessary to make the micro controller functional. So the first and most
important of this is power, marked as Vcc with a GND (ground potential). Without proper power
supply, no electronic system would work. XTAL 1 and XTAL 2 are for the system clock inputs from
crystal clock circuit. RESET input is required to initialize microcontroller to default/desired values and
to make a new start.
There are 3 control signals, EA,PSEN and ALE. These signals known as External Access (EA),
Program Store Enable (PSEN), and Address Latch Enable (ALE) are used for external memory
interfacing.

EA
The 8051 family members, such as the 8751/52, 89C51/52, or DS89C4xO, all come
with on-chip ROM to store programs. In such cases, the EA pin is connected to V cc. For
family members such as the 8031 and 8032 in which there is no on-chip ROM. code is
stored on an external ROM and is fetched by the 8031/32. Therefore, for the 8031 the
EA pin must be connected to GND to indicate that the code is stored externally. EA.
which stands for external access, is pin number 31 in the DIP packages. It is an input

pin and must be connected to either V cc or GND. In other words, it cannot be left
unconnected.
PSEN

pg 28

This is an output pin. PSEN stands for program store enable. In an 8031-based
system in which an external ROM holds the program code, this pin is connected to the
OE pin of the ROM.

TRIS Registers
The TRISx register control bits determine whether each pin associated with
the I/O port is an
input or an output. If the TRIS bit for an I/O pin is a 1, then the pin is an
input. If the TRIS bit for an I/O pin is a 0, then the pin is configured for an
output. An easy way to remember is that a 1 looks like an I (input) and a
0 looks like an O (output). All port pins are defined as inputs after a
Reset.
Types of instructions
Depending on operation they perform, all instructions are divided in several groups:

Arithmetic Instructions

Branch Instructions

Data Transfer Instructions

Logic Instructions

Bit-oriented Instructions

Conditional Jump

If some specified condition is satisfied in conditional jump, the control flow is transferred to a target
instruction. There are numerous conditional jump instructions depending upon the condition and data.

Following are the conditional jump instructions used on signed data used for arithmetic operations:

Instruction

Description

Flags tested

JE/JZ

Jump Equal or Jump Zero

ZF

JNE/JNZ

Jump not Equal or Jump Not Zero

ZF

JG/JNLE

Jump Greater or Jump Not Less/Equal

OF, SF, ZF

JGE/JNL

Jump Greater or Jump Not Less

OF, SF

JL/JNGE

Jump Less or Jump Not Greater/Equal

OF, SF

JLE/JNG

Jump Less/Equal or Jump Not Greater

OF, SF, ZF

Following are the conditional jump instructions used on unsigned data used for logical operations:

Instruction

Description

Flags tested

JE/JZ

Jump Equal or Jump Zero

ZF

JNE/JNZ

Jump not Equal or Jump Not Zero

ZF

JA/JNBE

Jump Above or Jump Not Below/Equal

CF, ZF

JAE/JNB

Jump Above/Equal or Jump Not Below

CF

JB/JNAE

Jump Below or Jump Not Above/Equal

CF

JBE/JNA

Jump Below/Equal or Jump Not Above

AF, CF

The following conditional jump instructions have special uses and check the value of flags:

Instruction

Description

Flags tested

JXCZ

Jump if CX is Zero

none

JC

Jump If Carry

CF

JNC

Jump If No Carry

CF

JO

Jump If Overflow

OF

JNO

Jump If No Overflow

OF

JP/JPE

Jump Parity or Jump Parity Even

PF

JNP/JPO

Jump No Parity or Jump Parity Odd

PF

JS

Jump Sign (negative value)

SF

JNS

Jump No Sign (positive value)

SF

The STATUS register contains:

the arithmetic status of the ALU

the RESET status
the bank select bit for data memory
As with any register, the STATUS register can be the destination for any instruction.
If the STATUS register is the destination for an instruction that affects the Z, DC or C
bits, then the write to these three bits is disabled. These bits are set or cleared according
to device logic.
the TO and PD bits are not writable.

For example, CLRF STATUS will clear the upper three bits and set the Z bit. This leaves the
STATUS register as 000u u1uu (where u =unchanged).

Only the BCF, BSF, SWAPF and MOVWF instructions should be used to alter the
STATUS register, because these instructions do not affect any status bit.

1. PCL and PCLATH:

Fig. 9. :

Format of PCLATH and PCL registers

The program counter (PC) specifies the address of the instruction to fetch for execution.
The PC is 13 bits wide.
The low byte is called the PCL register. This register is readable and writable.

The high byte is called the PCH register. This register contains the PC<12:8> bits and is
not directly readable or writable.

If the program counter (PC) is modified or a conditional test is true, the instruction
requires two cycles.
The second cycle is executed as a NOP.

All updates to the PCH register go through the PCLATH register.

The abbreviation CCP stands for Capture/Compare/PWM.

The abbreviation CCP stands for Capture/Compare/PWM.

The CCP module is a peripheral which allows the user to time and control different
events.

Capture Mode, allows timing for the duration of an event. This circuit gives insight
into the current state of a register which constantly changes its value. In this case, it
is the timer TMR1 register.

Compare Mode compares values contained in two registers at some point. One of
them is the timer TMR1 register. This circuit also allows the user to trigger an
external event when a predetermined amount of time has expired.

PWM - Pulse Width Modulation can generate signals of varying frequency and duty
cycle.

The PIC16F887 microcontroller has two such modules - CCP1 and CCP2.

Both of them are identical in normal mode, with the exception of the Enhanced PWM
features available on CCP1 only

CAPTURE/COMPARE/PWM
Modules in PIC 16F877

(CCP)

Capture-Compare-Pulse-Width-Module (CCP) is a special module designs for modulation and

waveform generation applications. This module basically works on three different modes
(capture/compare and PWM odes). The PIC 16F877 chip contains two CCP ports (CCP1 and
CCP2). Each of this CCP module contains 16 bit registers which works as
16-bit Capture register
16-bit Compare register

 PWM Master/Slave Duty Cycle registers

The CCP1 and CCP2 modules are identical in its operation except in its special event trigger
operation. In each CCP modules, the capture, compare and PWM modes using different timer
resources.

CCP1 Module
Capture/Compare/PWM Register 1 (CCPR1) is a 16 bit register comprised of two 8-bit registers:
CCPR1L (low byte) and CCPR1H (high byte). The CCP1CON register controls the operation of
CCP1. The special event trigger is generated by a compare match and will reset Timer1.

CCP2 Module
Capture/Compare/PWM Register 2 (CCPR2) is comprised of two 8-bit registers: CCPR2L (low byte)
and CCPR2H (high byte). The CCP2CON register controls the operation of CCP2. The special event
trigger is generated by a compare match and will reset Timer1 and start an A/D conversion (if the
A/D module is enabled).

Capture Mode
In Capture mode, CCPR1H:CCPR1L captures the 16-bit value of the TMR1 register when an event
occurs on pin RC2/CCP1.
An event is defined as one of the following:
Every falling edge
Every rising edge
Every 4th rising edge
Every 16th rising edge
The type of event is configured by control bits, CCP1M3:CCP1M0 (CCPxCON<3:0>). When a
capture is made, the interrupt request flag bit, CCP1IF (PIR1<2>), is set. The interrupt flag must be
cleared in software. If another capture occurs before the value in register CCPR1 is read, the old
captured value is overwritten by the new value

Compare Mode

In Compare mode, the 16-bit CCPR1 register value is constantly compared against the TMR1
register pair value. When a match occurs, the RC2/CCP1 pin is:
Driven high
Driven low
Remains unchanged
The action on the pin is based on the value of control bits, CCP1M3:CCP1M0 (CCP1CON<3:0>). At
the same time, interrupt flag bit CCP1IF is set.

PWM Mode (PWM)

In Pulse Width Modulation mode, the CCPx pin produces up to a 10-bit resolution PWM output.
Since the CCP1 pin is multiplexed with the PORTC data latch, the TRISC<2> bit must be cleared to
make the

CCP1 pin an output.

Introduction:
IC is a multi-master, low-bandwidth, short distance, serial communication
bus protocol. Nowadays it is not only used on single boards, but also to
attach low-speed peripheral devices and components to a motherboard,
embedded system, or cell-phone, as the new versions provide lot of
advanced features and much higher speed. The features like simplicity &
flexibility make this bus attractive for consumer and automotive electronics.
Details:

The basic design of IC has a 7-bit address space with 16 reserved

addresses, which makes the maximum number of nodes that can
communicate on the same bus as 112. That means each IC device is
recognized by a unique 7-bit address. It is important to note that the
maximum number of nodes is obviously limited by the address space, and
also by the total bus capacitance of 400 pf.
The two bi-directional lines, which carry information between the devices
connected to the bus, are known as Serial Data line (SDA) and Serial Clock
line (SCL). As the name indicates the SDA line contains the data and the
SCL with the clock signal for synchronization. The typical voltages used are
+5 V or +3.3V.

Like the CAN & LIN protocols, the IC also follows the masterslave communication protocol. But the IC bus is a multi-master
bus, which means more than one IC/device capable of initiating a
data transfer can be connected to it. The device that initiates the
communication is called MASTER, whereas the device being
addressed by the Master is called as SLAVE. It is the master
device who always do generation of clock signals, which means
each master generates its own clock signals when transferring
data on the bus.
Watchdog Timer

A watchdog timer is an internal timer running independently of the system clock.

It resets the device in the event of a program or circuit malfunction or if an unknown

logical state is encountered.

For example, if the program hangs, the watchdog timer will time out and reset the
processor.

A cross compiler is a compiler capable of creating executable code for a platform other than the
one on which the compiler is running. For example, a compiler that runs on aWindows 7 PC but
generates code that runs on Android smartphone is a cross compiler.
A cross compiler is necessary to compile for multiple platforms from one machine. A platform could
be infeasible for a compiler to run on, such as for the microcontroller of anembedded

system because those systems contain no operating system. In paravirtualization one machine runs
many operating systems, and a cross compiler could generate an executable for each of them from
one main source.
Cross compilers are not to be confused with source-to-source compilers. A cross compiler is for
cross-platform software development of binary code, while a source-to-source "compiler" just
translates from one programming language to another in text code. Both are programming tools.
The fundamental use of a cross compiler is to separate the build environment from target
environment. This is useful in a number of situations:

Embedded computers where a device has extremely limited resources. For example, a
microwave oven will have an extremely small computer to read its touchpad and door sensor,
provide output to a digital display and speaker, and to control the machinery for cooking food.
This computer will not be powerful enough to run a compiler, a file system, or a development
environment. Since debugging and testing may also require more resources than are available
on an embedded system, cross-compilation can be less involved and less prone to errors than
native compilation.

Compiling for multiple machines. For example, a company may wish to support several
different versions of an operating system or to support several different operating systems. By
using a cross compiler, a single build environment can be set up to compile for each of these
targets.

Compiling on a server farm. Similar to compiling for multiple machines, a complicated build
that involves many compile operations can be executed across any machine that is free,
regardless of its underlying hardware or the operating system version that it is running.

Bootstrapping to a new platform. When developing software for a new platform, or the
emulator of a future platform, one uses a cross compiler to compile necessary tools such as the
operating system and a native compiler.

Compiling native code for emulators for older now-obsolete platforms like the Commodore
64 or Apple II by enthusiasts who use cross compilers that run on a current platform (such as
Aztec C's MS-DOS 6502 cross compilers running under Windows XP).

Use of virtual machines (such as Java's JVM) resolves some of the reasons for which cross
compilers were developed. The virtual machine paradigm allows the same compiler output to be
used across multiple target systems, although this is not always ideal because virtual machines are
often slower and the compiled program can only be run on computers with that virtual machine.

Typically the hardware architecture differs (e.g. compiling a program destined for the MIPS
architecture on an x86 computer) but cross-compilation is also applicable when only theoperating
system environment differs, as when compiling a FreeBSD program under Linux, or even just the
system library, as when compiling programs with uClibc on a glibc host.

A cross assembler is a program which generates machine code for a

processor other than the one it is currently run on.
An assembler is a program that converts assembly language ("human
readable" text - if you are a nerd) into the actual binary processor specific
machine code (non-human readable binary code - unless you are a nerd).
Normally the machine code generated is for the processor used in the
machine it is run on. A cross assembler takes this conversion process a
step further by allowing you to generate machine code for
a different processor than the one the compiler is run on.
Cross assemblers are generally used to develop programs which are
supposed to run on game consoles, appliances and other specialized small
electronics systems which are not able to run a development environment.
They can also be used to speed up development for low powered system, for
example XAsm enables development on a PC based system for a Z80
powered MSX computer. Even though the MSX system is capable of running
an assembler, having the additional memory, processor speed and storage
capabilities like a harddisk significantly speeds up development effort
A cross assembler (see also cross compiler) is an assembler that is run on a computer or operating
system of a different type from the system on which the resulting code is to run (the target system).
Cross-assembling may be necessary if the target system cannot run an assembler itself, as is
typically the case for small embedded systems. The computer on which the cross assembler is run
must have some means of transporting the resulting machine code to the target system. Common
methods involve transmitting an exact byte-by-byte copy of the machine code or
an ASCII representation of the machine code in a portable format (such
as Motorola or Intel hexadecimal) through a compatible interface to the target system for execution.
A toolchain is a set of distinct software development tools that are linked (or chained) together by
specific stages such as GCC, binutils and glibc (a portion of the GNU Toolchain). Optionally, a
toolchain may contain other tools such as a Debugger or a Compiler for a specific programming
language, such as ,C++. Quite often, the toolchain used for embedded development is a cross
toolchain, or more commonly known as a cross compiler. All the programs (like GCC) run on a host
system of a specific architecture (such as x86) but produce binary code (executables) to run on a
different architecture (e.g. ARM). This is called cross compilation and is the typical way of building
embedded software. It is possible to compile natively, running gcc on your target. Before searching
for a prebuilt toolchain or building your own, it's worth checking to see if one is included with your
target hardware's Board Support Package (BSP) if you have one
When talking about toolchains, one must distinguish three different machines :

the build machine, on which the toolchain is built

the host machine, on which the toolchain is executed

the target machine, for which the toolchain generates code

From these three different machines, we distinguish four different types of toolchain building
processes :

A native toolchain, as can be found in normal Linux distributions, has usually been compiled
on x86, runs on x86 and generates code for x86.

A cross-compilation toolchain, which is the most interesting toolchain type for embedded
development, is typically compiled on x86, runs on x86 and generates code for the target
architecture (be it ARM, MIPS, PowerPC or any other architecture supported by the different
toolchain components)

A cross-native toolchain, is a toolchain that has been built on x86, but runs on your target
architecture and generates code for your target architecture. It's typically needed when you want
a native gcc on your target platform, without building it on your target platform.

A canadian build is the process of building a toolchain on machine A, so that it runs on

machine B and generates code for machine C. It's usually not really necessary

file.

Master Synchronous Serial Port Module

MSSP module (Master Synchronous Serial Port) is a very useful, but at the same time one of the most
complex circuit within the microcontroller. It enables high speed communication between a microcontroller
and other peripherals or microcontroller devices by using few input/output lines (maximum two or three).
Therefore, it is commonly used to connect the microcontroller to LCD displays, A/D converters, serial
EEPROMs, shift registers etc. The main feature of this type of communication is that it is synchronous
and suitable for use in systems with a single master and one or more slaves. A master device contains
the necessary circuitry for baud rate generation and supplies the clock for all devices in the system. Slave
devices may in that way eliminate the internal clock generation circuitry. The MSSP module can operate
in one of two modes:

SPI mode (Serial Peripheral Interface)

IC mode (Inter-Integrated Circuit)

one MSSP module represents only a half of the hardware needed to establish serial communication,
while another half is stored in the device the data is exchanged with. Even though the modules on both
ends of the line are the same, their modes are essentially different depending on whether they operate as
a Master or a Slave:
If the microcontroller to be programmed controls another device or circuit (peripherals), it should operate
as a master device. A module defined as such will generate clock when needed, i.e. only when data
receive and transmit is required by the software. It depends on the master whether the connection will be
established or not. Otherwise, if the microcontroller to be programmed is a part of some peripheral which
belongs to some more complex device (for example PC), then it should operate as a slave device. As
such, it always has to wait for request for data transfer from master device.

Context switching
When the multithreading kernel decides to run a different thread,
it simply saves the current threads context(CPU registers,etc.)
in the current threads context storage space. Once this operation
is performed, the new threads context is retrieved from its
context storage space and the CPU executes the new threads code.
This process is called context switching.
data can be shared by tasks while running in a RTOS environment. However, this
sharing of data among tasks has some problems as it arises out of the switching of
the CPU from one task to another task and changing the flow of execution when an

interrupt occurs. The semaphore is one such tool that is used to tackle this
problem.
A semaphore is like a key that allows a task to carry out some operation or to
access a resource. There may be several keys for each semaphore. If a task can
acquire the semaphore, it can carry out the intended operation or access the
desired resource. Otherwise that task is blocked, if it chooses to wait for the release
of the semaphore. The semaphores are required to synchronize the switching of
resources between tasks.
Some RTOSs even have more than one kind of semaphore. There can be three kinds
of semaphores--- Binary semaphores
Counting semaphores
Mutual exclusion semaphores or Mutexes.
Often the binary semaphore term is used as a synonym of mutex, though there are
fundamental differences between the two. We shall be discuss the most commonly
used semaphores, the binary semaphore in this note.
A semaphore is a variable or a lock or a flag used to control access to shared
resource by task. So to activate or deactivate a semaphore (and allocate or deallocate it to a task) for giving or taking away desired resource to the task
respectively, terms get and give, take and release, pend and post, p and v,
wait and signal, and many other combination of terms are used. We shall use the
terms take and release while discussing the way semaphores are used.
A typical binary semaphore works like this: tasks can call two RTOS functions,
TakeSemaphore( ) and ReleaseSemaphore( ). If one task has called TakeSemaphore( ) to
take the semaphore and has not called ReleaseSemaphore( ) to release the
semaphore, then any other task that calls TakeSemaphore( ) will be blocked from
getting a semaphore until the first task calls ReleaseSemaphore( ). Only one task can
have the semaphore at a time.
A universal asynchronous receiver/transmitter, abbreviated UART /jurt/, is a piece
of computer hardware that translates data between parallel and serial forms. UARTs are commonly
used in conjunction with communication standards such as EIA, RS-232, RS-422 or RS-485.
The universal designation indicates that the data format and transmission speeds are configurable.
The electric signaling levels and methods (such as differential signaling etc.) are handled by a driver
circuit external to the UART.
A UART is usually an individual (or part of an) integrated circuit used for serial communications over
a computer or peripheral device serial port. UARTs are now commonly included in microcontrollers.
A dual UART, or DUART, combines two UARTs into a single chip. An octal UART
or OCTART combines eight UARTs into one package, an example being the NXP SCC2698. Many
modern ICs now come with a UART that can also communicate synchronously; these devices are
called USARTs (universal synchronous/asynchronous receiver/transmitter).

Converts the bytes it receives from the computer along parallel circuits
into a singleserial bit stream for outbound transmission

On inbound transmission, converts the serial bit stream into the bytes

that the computer handles

Adds a parity bit (if it's been selected) on outbound transmissions and

checks the parity of incoming bytes (if selected) and discards the parity
bit
Adds start and stop delineators on outbound and strips them from

inbound transmissions
Handles interrupt s from the keyboard and mouse (which are serial

devices with specialport s)

May handle other kinds of interrupt and device management that

require coordinating the computer's speed of operation with device

speeds
More advanced UARTs provide some amount of buffering of data so that the
computer and serial devices data streams remain coordinated. The most
recent UART, the 16550, has a 16-byte buffer that can get filled before the
computer's processor needs to handle the data. The original UART was the
8250. If you purchase an internal modem today, it probably includes a 16550
UART (although you should ask when you buy it). According to modem
manufacturer US Robotics, external modems do not include a UART. If you
have an older computer, you may want to add an internal 16550 to get the
most out of your external modem.

An embedded system is some combination of computer hardware and software,

either fixed in capability or programmable, that is specifically designed for a
particular function. Industrial machines, automobiles, medical equipment,
cameras, household appliances, airplanes, vending machines and toys (as well
as the more obvious cellular phone and PDA) are among the myriad possible
hosts of an embedded system. Embedded systems that are programmable are
provided with programming interfaces, and embedded systems programming is a
specialized occupation.
Certain operating systems or language platforms are tailored for the embedded
market, such as EmbeddedJava andWindows XP Embedded. However, some
low-end consumer products use very inexpensive microprocessors and limited
storage, with the application and operating system both part of a single program.
The program is written permanently into the system's memory in this case, rather
than being loaded intoRAM (random access memory) like programs on a

personal computer. Embedded systems are commonly found in consumer, cooking, industrial,
automotive, medical, commercial and military applications.
Telecommunications systems employ numerous embedded systems fromtelephone switches for the
network to cell phones at the end-user. Computer networking uses dedicated routers and network
bridges to route data.
Consumer electronics include personal digital assistants (PDAs), mp3 players, mobile
phones, videogame consoles, digital cameras, DVD players, GPS receivers, and printers.
Household appliances, such as microwave ovens, washing machinesand dishwashers, include
embedded systems to provide flexibility, efficiency and features. Advanced HVAC systems use
networked thermostats to more accurately and efficiently control temperature that can change by
time of day and season.Home automation uses wired- and wireless-networking that can be used to
control lights, climate, security, audio/visual, surveillance, etc., all of which use embedded devices
for sensing and controlling.

User interface[edit]

Embedded system text user interface using MicroVGA[nb 1]

Embedded systems range from no user interface at all, in systems dedicated only to one task, to
complex graphical user interfaces that resemble modern computer desktop operating systems.
Simple embedded devices use buttons, LEDs, graphic or character LCDs (HD44780 LCD for
example) with a simple menu system.
More sophisticated devices which use a graphical screen with touch sensing or screen-edge buttons
provide flexibility while minimizing space used: the meaning of the buttons can change with the
screen, and selection involves the natural behavior of pointing at what's desired. Handheld
systems often have a screen with a "joystick button" for a pointing device.
Some systems provide user interface remotely with the help of a serial (e.g. RS-232, USB, IC, etc.)
or network (e.g. Ethernet) connection.

Processors in embedded systems

Ordinary microprocessors (P) use separate integrated circuits for memory and peripherals.
Microcontrollers (C) have on-chip peripherals, thus reducing power consumption, size and cost. In

contrast to the personal computer market, many different basic CPU architectures are used, since
software is custom-developed for an application and is not a commodity product installed by the end
user. Both Von Neumann as well as various degrees of Harvard architectures are used.
Ready made computer boards[edit]
PC/104 and PC/104+ are examples of standards for ready made computer boards intended for
small, low-volume embedded and ruggedized systems, mostly x86-based. These are often
physically small compared to a standard PC, although still quite large compared to most simple
(8/16-bit) embedded systems. They often use DOS, Linux, NetBSD, or an embedded real-time
operating system such as MicroC/OS-II, QNX or VxWorks. Sometimes these boards use non-x86
processors.
ASIC and FPGA solutions[edit]
A common array of n configuration for very-high-volume embedded systems is the system on a
chip (SoC) which contains a complete system consisting of multiple processors, multipliers, caches
and interfaces on a single chip. SoCs can be implemented as an application-specific integrated
circuit (ASIC) or using a field-programmable gate array (FPGA).

Peripherals[edit]

A close-up of the SMSC LAN91C110 (SMSC 91x) chip, an embeddedethernet chip.

Embedded Systems talk with the outside world via peripherals, such as:

Serial Communication Interfaces (SCI): RS-232, RS-422, RS-485 etc.

Synchronous Serial Communication Interface: I2C, SPI, SSC and ESSI (Enhanced
Synchronous Serial Interface)

Universal Serial Bus (USB)

Multi Media Cards (SD Cards, Compact Flash etc.)

Networks: Ethernet, LonWorks, etc.

Fieldbuses: CAN-Bus, LIN-Bus, PROFIBUS, etc.

Timers: PLL(s), Capture/Compare and Time Processing Units

Discrete IO: aka General Purpose Input/Output (GPIO)

Analog to Digital/Digital to Analog (ADC/DAC)

Debugging: JTAG, ISP, ICSP, BDM Port, BITP, and DP9 ports

Embedded software architectures

imple control loop
In this design, the software simply has a loop. The loop calls subroutines, each of which manages a
part of the hardware or software.

Interrupt-controlled system
Some embedded systems are predominantly controlled by interrupts. This means that tasks
performed by the system are triggered by different kinds of events; an interrupt could be generated,
for example, by a timer in a predefined frequency, or by a serial port controller receiving a byte
These kinds of systems are used if event handlers need low latency, and the event handlers are
short and simple. Usually, these kinds of systems run a simple task in a main loop also, but this task
is not very sensitive to unexpected delays.

Cooperative multitasking
A nonpreemptive multitasking system is very similar to the simple control loop scheme, except that
the loop is hidden in anAPI. The programmer defines a series of tasks, and each task gets its own
environment to run in. When a task is idle, it calls an idle routine, usually called pause, wait,
yield, nop (stands for no operation), etc.

Microkernels and exokernels

A microkernel is a logical step up from a real-time OS. The usual arrangement is that the operating
system kernel allocates memory and switches the

In this case, a relatively large kernel with sophisticated capabilities is adapted to suit an embedded
environment. This gives programmers an environment similar to a desktop operating system
like Linux or Microsoft Windows, and is therefore very productive for development; on the downside,
it requires considerably more hardware resources, is often more expensive, and, because of the
complexity of these kernels, can be less predictable and reliableCommon examples of embedded
monolithic kernels are embedded Linux and Windows CE.

. Exotic custom operating systems

A small fraction of embedded systems require safe, timely, reliable, or efficient behavior unobtainable
with any of the above architectures. In this case an organization builds a system to suit. In some
cases, the system may be partitioned into a "mechanism controller" using special techniques, and a
"display controller" with a conventional operating system. A communication system passes data
between the two.

Additional software components[edit]

In addition to the core operating system, many embedded systems have additional upper-layer
software components. These components consist of networking protocol stacks
like CAN, TCP/IP, FTP, HTTP, and HTTPS, and also included storage capabilities like FAT and flash
memory management systems. If the embedded device has audio and video capabilities, then the
appropriate drivers and codecs will be present in the system. In the case of the monolithic kernels,
many of these software layers are included. In the RTOS category, the availability of the additional
software components depends upon the commercial offering.
Message Queues, Mailboxes, and Pipes

Message Tasks must be able to communicate with one

another to coordinate their activities or to share data. For
example, in the underground tank monitoring system the
task that calculates the amount of gas in the tanks must let
other parts of the system know how much gasoline there
is. In Telegraph, the system we discussed earlier that
connects a serial-port printer to a network, the tasks that
receive data on the network must hand that data off to
other tasks that pass the data on to the printer or that
determine responses to send on the network.
We also discussed using shared data and semaphores to
allow tasks to communicate with one another. In this
section we will discuss several other methods that most
RTOSs other: queues, mailboxes, and pipes.

Heres a very simple example. Suppose that we have two

tasks, Task1 and Task2, each of which has a number of
high-priority, urgent things to do. Suppose also that from
time to time these two tasks discover error conditions that
must be reported on a network, a time consuming process.
In order not to delay Task1 and Task2, it makes sense to
have a separate task, Errors Task that is responsible for
reporting the error conditions on the network. Whenever
Task1 or Task2 discovers an error, it reports that error to
ErrorsTask and then goes on about its own business. The
error reporting process undertaken by ErrorsTask does not
delay the other tasks. An RTOS queue is the way to
implement this design.
Some Ugly Details.
As youve no doubt guessed, queues are not quite simple.
Here are some of the complications that you will have to
deal with in most RTOSs:
Most RTOSs require that you initialize your queues before
you use them, by calling a function provided for this
purpose. On some systems, it is also up to you to allocate
the memory that the RTOS will manage as a queue. As with
semaphores, it makes most sense to initialize queues in
some code that is guaranteed to run before any task tries
to use them.
Since most RTOSs allow you to have as many queues as
you want, you pass an additional parameter to every queue
function: the identity of the queue to which you want to
write or from which you want to read. Various systems do
this in various ways.

If your code tries to write to a queue when the queue is full,

the RTOS must either return an error to let you know that
the write operation failed (a more common RTOS behavior)
or it must block the task until some other task reads data
from the queue and thereby creates some space (a less
common RTOS behavior). Your code must deal with
whichever of these behaviors your RTOS exhibits.
Many RTOSs include a function that will read from a queue
if there is any data and will return an error code if not. This
function is in addition to the one that will block your task if
the queue is empty.
The amount of data that the RTOS lets you write to the
queue in one call may not be exactly the amount that you
want to write. Many RTOSs are inflexible about this. One
common RTOS characteristic is to allow you to write onto a
queue in one call the number of bytes taken up by a void
pointer.
Mailboxes
In general, mailboxes are much like queues. The typical
RTOS has functions to create, to write to, and to read from
mailboxes, and perhaps functions to check whether the
mailbox contains any messages and to destroy the mailbox
if it is no longer needed. The details of mailboxes, however,
are different in different RTOSs.
Here are some of the variations that you might see:
Although some RTOSs allow a certain number of messages
in each mailbox, a number that you can usually choose
when you create the mailbox, others allow only one

message in a mailbox at a time. Once one message is

written to a mailbox under these systems, the mailbox is
full; no other message can be written to the mailbox until
the first one is read.
In some RTOSs, the number of messages in each mailbox
is unlimited. There is a limit to the total number of
messages that can be in all of the mailboxes in the system,
but these messages will be distributed into the individual
mailboxes as they are needed.
In some RTOSs, you can prioritize mailbox messages.
Higher-priority messages will be read before lower-priority
messages, regardless of the order in which they are written
into the mailbox.
Pipes
Pipes are also much like queues. The RTOS can create
them, write to them, read from them, and so on. The details
of pipes, however, like the details of mailboxes and queues,
vary from RTOS to RTOS. Some variations you might see
include the following:
Some RTOSs allow you to write messages of varying
lengths onto pipes (unlike mailboxes and queues, in which
the message length is typically fixed).
Pipes in some RTOSs are entirely byte-oriented: if Task A
writes 11 bytes to the pipe and then Task B writes 19 bytes
to the pipe, then if Task C reads 14 bytes from the pipe, it
will get the 11 that Task A wrote plus the first 3 that Task B
wrote. The other 16 that task B wrote remain in the pipe for
whatever task reads from it next.

Some RTOSs use the standard C library functions fread

and fwrite to read from and write to pipes.
Which Should I Use?
Since queues, mailboxes, and pipes vary so much from
one RTOS to another, it is hard to give much universal
guidance about which to use in any given situation. When
RTOS vendors design these features, they must make the
usual programming trade-offs among flexibility, speed,
memory space, the length of time that interrupts must be
disabled within the RTOS functions, and so on. Most RTOS
vendors describe these characteristics in their
documentation; read it to determine which of the
communications mechanisms best meets your
requirements.
Pitfalls
Although queues, mailboxes, and pipes can make it quite
easy to share data among tasks, they can also make it
quite easy to insert bugs into your system. Here are a few
tried-and-true methods for making yourself some trouble:
Most RTOSs do not restrict which tasks can read from or
write to any given queue, mailbox, or pipe. Therefore, you
must ensure that tasks use the correct one each time. If
some task writes temperature data onto a queue read by a
task expecting error codes, your system will not work very
well. This is obvious, but it is easy to mess up.
The RTOS cannot ensure that data written onto a queue,
mailbox, or pipe will be properly interpreted by the task

that reads it. If one task writes an integer onto the queue
and another task reads it and then treats it as a pointer,
your product will not ship until the problem is found and
fixed.
Running out of space in queues, mailboxes, or pipes is
usually a disaster for embedded software. When one task
needs to pass data to another, it is usually not optional.
Good solutions to this problem are scarce. Often, the only
workable one is to make your queues, mailboxes, and
pipes large enough in the first place.
Passing pointers from one task to another through a
queue, mailbox, or pipe is one of several ways to create
shared data inadvertently. Queues, Mailboxes, and Pipes

Tasks must be able to communicate with one another to coordinate their activities or to share data. Fo
that calculates the amount of gas in the tanks must let other parts of the system know how much gas
connects a serial-port printer to a network, the tasks that receive data on the network must hand that
determine responses to send on the network.

We also discussed using shared data and semaphores to allow tasks to communicate with one anoth
RTOSs other: queues, mailboxes, and pipes.

Heres a very simple example. Suppose that we have two tasks, Task1 and Task2, each of which has
from time to time these two tasks discover error conditions that must be reported on a network, a time
makes sense to have a separate task, Errors Task that is responsible for reporting the error condition
reports that error to ErrorsTask and then goes on about its own business. The error reporting process
RTOS queue is the way to implement this design.
Some Ugly Details.

As youve no doubt guessed, queues are not quite simple. Here are some of the complications that yo

Most RTOSs require that you initialize your queues before you use them, by calling a function provide
allocate the memory that the RTOS will manage as a queue. As with semaphores, it makes most sen
before any task tries to use them.

Since most RTOSs allow you to have as many queues as you want, you pass an additional paramete

want to write or from which you want to read. Various systems do this in various ways.

If your code tries to write to a queue when the queue is full, the RTOS must either return an error to le
behavior) or it must block the task until some other task reads data from the queue and thereby creat
deal with whichever of these behaviors your RTOS exhibits.

Many RTOSs include a function that will read from a queue if there is any data and will return an erro
your task if the queue is empty.

The amount of data that the RTOS lets you write to the queue in one call may not be exactly the amo
One common RTOS characteristic is to allow you to write onto a queue in one call the number of byte
Mailboxes

In general, mailboxes are much like queues. The typical RTOS has functions to create, to write to, an
the mailbox contains any messages and to destroy the mailbox if it is no longer needed. The details o
Here are some of the variations that you might see:
Although some RTOSs allow a certain number of messages in each mailbox, a number that you can
message in a mailbox at a time. Once one message is written to a mailbox under these systems, the
until the first one is read.

In some RTOSs, the number of messages in each mailbox is unlimited. There is a limit to the total nu
system, but these messages will be distributed into the individual mailboxes as they are needed.

In some RTOSs, you can prioritize mailbox messages. Higher-priority messages will be read before lo
written into the mailbox.
Pipes
Pipes are also much like queues. The RTOS can create them, write to them, read from them, and so
queues, vary from RTOS to RTOS. Some variations you might see include the following:

Some RTOSs allow you to write messages of varying lengths onto pipes (unlike mailboxes and queue

Pipes in some RTOSs are entirely byte-oriented: if Task A writes 11 bytes to the pipe and then Task B
pipe, it will get the 11 that Task A wrote plus the first 3 that Task B wrote. The other 16 that task B wro
Some RTOSs use the standard C library functions fread and fwrite to read from and write to pipes.
Which Should I Use?

Since queues, mailboxes, and pipes vary so much from one RTOS to another, it is hard to give much

When RTOS vendors design these features, they must make the usual programming trade-offs amon
interrupts must be disabled within the RTOS functions, and so on. Most RTOS vendors describe thes
of the communications mechanisms best meets your requirements.
Pitfalls

Although queues, mailboxes, and pipes can make it quite easy to share data among tasks, they can a
few tried-and-true methods for making yourself some trouble:

Most RTOSs do not restrict which tasks can read from or write to any given queue, mailbox, or pipe. T
time. If some task writes temperature data onto a queue read by a task expecting error codes, your s
up.

The RTOS cannot ensure that data written onto a queue, mailbox, or pipe will be properly interpreted
queue and another task reads it and then treats it as a pointer, your product will not ship until the prob

Running out of space in queues, mailboxes, or pipes is usually a disaster for embedded software. Wh
optional. Good solutions to this problem are scarce. Often, the only workable one is to make your que

Passing pointers from one task to another through a queue, mailbox, or pipe is one of several ways to