The document provides information about embedded systems and microprocessors. It defines embedded systems and gives examples. It discusses microprocessors and microcontrollers, their components, and differences between the two. It describes characteristics of embedded computing applications like sophisticated functionality, real-time operation, cost, power, and design teams. It also covers topics like instruction sets, ARM and Texas Instruments C55x processors, assembly language, and the ARM programming model.

2. TEAM NAME: KAIROS AAROHAN

3. TEAM MEMBER NAME:BERA SRUJANA

4. INSTITUTE NAME:MANAC INFO TECH PVT LTD

5. CONTACT INFORMATION:9346941662

6. By,
BERA SRUJANA

7. Embedded computing-Computers have been
embedded into applications
 It is any device that includes a programmable
computer but is not itself intended to be a general-
purpose computer.
 Thus, a PC is not itself an embedded computing
system, although PCs are often used to build
embedded computing systems.
 But a fax machine is an embedded computing system.

8. Definition
 Embedded system: any device that includes a
programmable computer but is not itself a general-
purpose computer.
 Embedded system is a combination of hardware and
software
 Specific to a task

9. Embedded computing-Block Dia
CPU
mem
input
output analog
analog
embedded
computer

10. Examples
 Personal digital assistant (PDA).
 Printer.
 Cell phone.
 Automobile: engine, brakes, dash, etc.
 Television.
 Household appliances.
 PC keyboard (scans keys).

11. Microprocessor
Microprocessor is a programmable integrated chip that is
capable of performing arithmetic, logic and decision –
making operations similar to that of the Central Processing
Unit (CPU) of a computer. Also called a CPU on a chip.
 Components Inside CPU
ALU Register
Section
Timing and Control
section
Address
bus
Data bus
Control bus

12. Microcontroller
 Microcontroller: A single chip that contains the
processor (the CPU), non-volatile memory for the
program (ROM or flash), volatile memory for
input and output (RAM), a clock and an I/O
control unit.
 Also called a computer on a chip.

13. Differences
 Microprocessor
 CPU on a chip.
 Von Neuman
Architecture(same
memory for program and
data)
 Applications:
Desktop,laptops,worksta
tion,servers,super
computer
 Eg:8085,8086…
 Microcontroller
 Computer on a chip
 Harvard Architecture
(separate memory for
program and data)
 Applications:used in
making embedded
systems eg: microwave
oven, camcoder, camera,
ECG,EEG…
 Eg:8048,8051

14. Characteristics of Embedded
Computing Applications
1. Sophisticated functionality:Complex algorithms,
User interface:
2. Real-time operation.
3. Low manufacturing cost.
4. Low power.
5. Designed to tight deadlines by small teams.

15. Sophisticated functionality
 Complex algorithms: Often have to run sophisticated
algorithms or multiple algorithms.
For example, the microprocessor that controls an
automobile engine must perform complicated
filtering functions to optimize the performance of the
car while minimizing pollution and fuel utilization-
Cell phone, laser printer
 User interface: Microprocessors are frequently used
to control complex user interfaces that may include
multiple menus and many options.
 The moving maps in Global Positioning System (GPS)

16. Real-time operation
Real Time: Must finish operations by deadlines.
 Hard real time: missing deadline causes failure.
 Soft real time: missing deadline results in degraded
performance.
Multi Rate: several real-time activities going on at the
same time. They may simultaneously control some
operations that run at slow rates and others that run at
high rates
Eg :Multimedia The audio and video portions of a
multimedia stream run at very different rates, but they
must remain closely synchronized.

17. Non-functional requirements
 Manufacturing cost: The total cost of building the
system is very important in many cases. Manufacturing
cost is determined by many factors, including the type
of microprocessor used, the amount of memory
required, and the typesof I/O devices.
 Power and energy:
Power consumption directly affects the cost of the
hardware
Energy consumption affects battery life, which is
important in many applications

18. Design teams
 Often designed by a small team of designers.
 Often must meet tight deadlines.
 6 month market window is common.

19. Challenges in embedded system
design
 How much hardware do we need?
 How big is the CPU? Memory?
 How do we meet our deadlines?
 Faster hardware or cleverer software?
 How do we minimize power?
 Turn off unnecessary logic? Reduce memory accesses?

20. Challenges, etc.
 How do we design for upgradability?
-hardware platform may be used over several product
generations, However, we want to be able to add
features by changing software
 Does it really work?
 Is the specification correct?
 Does the implementation meet the spec?
 Reliability in safety-critical systems

21. THE EMBEDDED SYSTEM DESIGN
PROCESS
 THE EMBEDDED SYSTEM DESIGN PROCESS aimed at two
objectives.
 Introduction to the various steps in embedded system
design.
 Second design methodology.

22. THE EMBEDDED SYSTEM DESIGN
PROCESS
 A design methodology is important for three reasons.
 First, it allows us to keep a scorecard on a design to ensure that we
have done everything we need to do,such as optimizing performance or
performing functional tests.
 Second, it allows us to develop computer-aided design tools.
but by first breaking the process into manageable steps,we can work
on automating (or at least semi automating) the steps one at a time.
 Third, a design methodology makes it much easier for members
of a design team to communicate. By defining the overall process,
team members can more easily understand what they are supposed to
do,what they should receive from other team members at certain times,
and what they are to hand off whenthey complete their assigned steps.
Since most embedded systems are designed by teams, coordination is
perhaps the most important role of a well-defined design methodology.

23. Embedded System Design Specifications
Levels of abstraction
requirements
specification
architecture
component
design
system
integration
Top down Design
Bottom up design

24. THE EMBEDDED SYSTEM DESIGN
PROCESS
Top down design proceeds from the abstract entity to
get to the concrete design. Bottom up design proceeds
from the concrete design to get to the abstract entity.
Top down design is most used in designing brand new
system, while Bottom up design is used one is reverse
engineering the design ie: when one is trying to
figure out what somebody else designed in an existing
system

25. Goals of the Embedded system
design
 manufacturing cost;
 performance (both overall speed and deadlines); and
power consumption.
 Stepwise refinement: At each level of abstraction, we
must:
 analyze the design to determine characteristics of the
current state of the design;
 refine the design to add detail.

26. Requirements
 Plain language description of what the user wants and
expects to get.
 May be developed in several ways:
 talking directly to customers;
 talking to marketing representatives;
 providing prototypes to users for comment.

27. Functional vs. non-functional
requirements
 Functional requirements:
 output as a function of input.
 Non-functional requirements:
 time required to compute output;
 size, weight, etc.;
 power consumption;
 reliability;
 etc.

28. Our requirements form
name
purpose
inputs
outputs
functions
performance
manufacturing cost
power
physical size/weight

29. Example: GPS moving map
requirements
 Moving map obtains
position from GPS,
paints map from local
database.
lat: 40 13 lon: 32 19
I-78
ScotchRoad

30. GPS moving map needs
 Functionality: For automotive use. Show major roads
and landmarks.
 User interface: At least 400 x 600 pixel screen. Three
buttons max. Pop-up menu.
 Performance: Map should scroll smoothly. No more
than 1 sec power-up. Lock onto GPS within 15 seconds.
 Cost: $500 street price = approx. $100 cost of goods
sold.

31. GPS moving map needs, cont’d.
 Physical size/weight: Should fit in hand.
 Power consumption: Should run for 8 hours on four
AA batteries.

32. GPS moving map requirements
form
name GPS moving map
purpose consumer-grade
moving map for driving
inputs power button, two
control buttons
outputs back-lit LCD 400 X 600
functions 5-receiver GPS; three
resolutions; displays
current lat/lon
performance updates screen within
0.25 sec of movement
manufacturing cost $100 cost-of-goods-
sold
power 100 mW
physical size/weight no more than 2: X 6:,
12 oz.

33. Specification
 A more precise description of the system:
 should not imply a particular architecture;
 provides input to the architecture design process.
 May include functional and non-functional elements.
 May be executable or may be in mathematical form for
proofs.

34. GPS specification
 Should include:
 What is received from GPS;
 map data;
 user interface;
 operations required to satisfy user requests;
 background operations needed to keep the system
running.

35. Architecture design
 What major components go satisfying the
specification?
 Hardware components:
 CPUs, peripherals, etc.
 Software components:
 major programs and their operations.
 Must take into account functional and non-functional
specifications.

36. GPS moving map block diagram
GPS
receiver
search
engine
renderer
user
interfacedatabase
display

37. GPS moving map hardware
architecture
GPS
receiver
CPU
panel I/O
display frame
buffer
memory

38. GPS moving map software
architecture
position database
search
renderer
timer
user
interface
pixels

39. Designing hardware and software
components
 Must spend time architecting the system before you
start coding.
 Some components are ready-made, some can be
modified from existing designs, others must be
designed from scratch.

40. System integration
 Put together the components.
 Many bugs appear only at this stage.
 Have a plan for integrating components to uncover
bugs quickly, test as much functionality as early as
possible.

41. Summary
 Embedded computers are all around us.
 Many systems have complex embedded hardware and
software.
 Embedded systems pose many design challenges:
design time, deadlines, power, etc.
 Design methodologies help us manage the design
process.

42. FORMALISMS FOR SYSTEM DESIGN-We use UML
to describe designs at several levels of
abstraction.
 Unified Modeling Language(UML) [Boo99,Pil05].
UML was designed to be useful at many levels of
abstraction in the design process. UML is useful
because it encourages design by successive refinement
and progressively adding detail to the design, rather
than rethinking the design at each new level of
abstraction.
 UML is an object-oriented modeling language.

43. Instruction Sets

44. Instruction Sets
 We use two CPUs as examples.
 TheARM processor [Fur96, Jag95] is widely used in cell
phones and many other systems. (The ARM
architecture comes in several versions;we will
concentrate on ARM version 7.)
 The Texas Instruments C55x is a family of digital
signal processors (DSPs) [Tex01,Tex02

45. PRELIMINARIES-Computer
Architecture TaxonomyHarvard architecture has separate
data and instruction busses, allowing
transfers to be performed
simultaneously on both busses.
–ARM-9
A von Neumann architecture has only
one bus which is used for both data
transfers and instruction fetches,
and therefore data transfers and
instruction fetches must be scheduled
–
they can not be performed at the
same time.-ARM-7

46. Another axis along which we can organize computer
architectures relates to their instructions and how they
are executed.
 complex instruction set
computers (CISC).
 These machines provided a
variety of instructions that
may perform very
complex tasks, such as
string searching; they also
generally used a number of
different instruction
formats of varying
lengths.
 reduced instruction set
computers (RISC).
 These computers tended to
provide somewhat fewer
and simpler
instructions.The
instructions were also
chosen so that they could
be efficiently executed in
pipelined processors

47. Characteristics of InstructionsInstructions can have a variety of characteristics, including:
 Fixed versus variable length.
 Addressing modes.
 Numbers of operands.
 Types of operations supported.

48. Assembly languages usually share
the same basic features:
 One instruction appears per
line.
 Labels, which give names
to memory locations, start
in the first column.
 instructions must start in the
second column or after to
distinguish them from
labels.
 Comments run from some
designated comment
character (; in the case of
ARM) to the end of the line.

49. ARM ProcessorFeatures:
1.ARM is a RISC processor.
2.It is used for small size and high performance
applications.
3.Simple architecture – low power consumption.
4.When used in relation to the ARM:
1. Byte means 8 bits
2. Halfword means 16 bits (two bytes)
3. Word means 32 bits (four bytes)
5.Most ARM’s implement two instruction sets
1. 32-bit ARM Instruction Set
2. 16-bit Thumb Instruction Set
ARM System - On - Chip
Architecture 49

50. ARM Processor6.ARM Processor can be configured
at power-up to address the bytes in
word in:
 Little Endian Mode: Lowest Order
Byte residing in low order bits of
the word.
 Big Endian: Lowest Order Byte
residing in highest order bits of
the word.
7. ARM is a Load-Store architecture:
Data operands must first be loaded
into the CPU and then stored back to
the main memory to store results.

51. ARM Processor
8. Four addressing modes:
1. Register addressing ADD r8,r7,r6
2. Immediate MOV r0,#01
3. Indirect LDR r1,[r2]
4. Base plus offset addressing LDR r0,[r1,#16]
9.ARM has16 General purpose registers (r0-r15)
1. R15=can also be used as program counter
2. CPSR-Current Program Status Register: Sets after
every arithmetic, logical or shifting operations

52. Registers of ARM
 The set of registers available for use by
programs is called the programming
model,also knownas the
programmer model.
 ARM has 16 general-purpose registers,
r0 through r15.
 Except for r15, they are identical—any
operation that can be done on one of
them can be done on the other one also.
 The r15 register has the same
capabilities as the other registers, but it
is also used as the program counter
ARM
programmin
g
model.

53. R14 is used as the subroutine link register (LR) and
stores the return address when Branch with Link
operations are performed,
calculated from the PC.
 Thus to return from a linked branch
 MOV r15,r14
or
 MOV pc,lr
R13 is used as Stack Pointer

54. The other important basic register in the programming model is
the current program status register (CPSR). This register is set
automatically during every arithmetic, logical, or shifting
operation.
Copies of the ALU status flags (latched if the
instruction has the "S" bit set).
N = Negative result from ALU flag.
Z = Zero result from ALU flag.
C = ALU operation Carried out
V = ALU operation oVerflowed
* Interrupt Disable bits.
I = 1, disables the IRQ.
F = 1, disables the FIQ.
* T Bit (Architecture v4T only)
T = 0, Processor in ARM state
T = 1, Processor in Thumb state
* Condition Code Flags
ModeN Z C V
2831 8 4 0
I F T
* Mode Bits
M[4:0] define the processor mode.

55. Logical Instruction Arithmetic Instruction
Flag
Negative No meaning Bit 31 of the result has been set
(N=‘1’) Indicates a negative number in
signed operations
Zero Result is all zeroes Result of operation was zero
(Z=‘1’)
Carry After Shift operation Result was greater than 32 bits
(C=‘1’) ‘1’ was left in carry flag
oVerflow No meaning Result was greater than 31 bits
(V=‘1’) Indicates a possible corruption of
the sign bit in signed
numbers
Condition Flags

58.  set r1 0 X100, the instruction
 LDR r0,[r1] sets r0 to the value of memory location
0x100.
 Similarly, STR r0,[r1] would store the contents of r0 in
the memory location whose address is given in r1.

60. y =a ∗(b + c);
 ADR r4,b ; get address for b
 LDR r0,[r4] ; get value of b
 ADR r4,c ; get address for c
 LDR r1,[r4] ; get value of c
 ADD r2,r0,r1 ; compute partial result of y
 ADR r4,a ; get address for a
 LDR r0,[r4] ; get value of a
 MUL r2,r2,r0 ; compute final value of y
 ADR r4,y ; get address for y
 STR r2,[r4] ; store value of y at proper location

61. Flow of Control
 The B (branch) instruction is the basic mechanism
inARM for changing the flow of control.The address
that is the destination of the branch is often called the
branch target.
 The offset is in words, but because the ARM is
byteaddressable,the offset is multiplied by four
(shifted left two bits, actually) to form a byte address.
Thus, the instruction
 B #100
 will add 400 to the current PC value.

64. Introduction
Application programs are typically developed, compiled, and run on host system
Embedded programs are targeted to a target processor (different from the development/host
processor and operating environment) that drives a device or controls
What tools are needed to develop, test, and locate embedded software into the target processor
and its operating environment?
Distinction
Host: Where the embedded software is developed, compiled, tested, debugged, optimized, and
prior to its translation into target device. (Because the host has keyboards, editors,
monitors, printers, more memory, etc. for development, while the target may have not of
these capabilities for developing the software.)
Target: After development, the code is cross-compiled, translated – cross-assembled, linked
(into target processor instruction set) and located into the target

65. 9.1 Introduction – 1
Cross-Compilers –
Native tools are good for host, but to port/locate embedded code to target, the host must
have a tool-chain that includes a cross-compiler, one which runs on the host but produces
code for the target processor
Cross-compiling doesn’t guarantee correct target code due to (e.g., differences in word
sizes, instruction sizes, variable declarations, library functions)
Cross-Assemblers and Tool Chain
Host uses cross-assembler to assemble code in target’s instruction syntax for the target
Tool chain is a collection of compatible, translation tools, which are ‘pipelined’ to produce a
complete binary/machine code that can be linked and located into the target processor
(See Fig 9.1)

67. 9.2Linker/Locators for Embedded Software
Native linkers are different from cross-linkers (or locators) that perform additional tasks to locate
embedded binary code into target processors
Address Resolution –
Native Linker: produces host machine code on the hard-drive (in a named file), which the loader
loads into RAM, and then schedules (under the OS control) the program to go to the CPU.
In RAM, the application program/code’s logical addresses for, e.g., variable/operands and function
calls, are ordered or organized by the linker. The loader then maps the logical addresses into
physical addresses – a process called address resolution. The loader then loads the code accordingly
into RAM (see Fig 9.2). In the process the loader also resolves the addresses for calls to the native
OS routines
Locator: produces target machine code (which the locator glues into the RTOS) and the combined
code (called map) gets copied into the target ROM. The locator doesn’t stay in the target
environment, hence all addresses are resolved, guided by locating-tools and directives, prior to
running the code (See Fig 9.3 and Fig 9.4)

71. Locating Program Components – Segments
Unchanging embedded program (binary code) and constants must be
kept in ROM to be remembered even on power-off
Changing program segments (e.g., variables) must be kept in RAM
Chain tools separate program parts using segments concept
Chain tools (for embedded systems) also require a ‘start-up’ code to be
in a separate segment and ‘located’ at a microprocessor-defined
location where the program starts execution
Some cross-compilers have default or allow programmer to specify
segments for program parts, but cross-assemblers have no default
behavior and programmer must specify segments for program parts
(See Fig 9.5 - locating of object-code segments in ROM and RAM)

73. Locating Program Components – Segments – 1
Telling/directing the locator where (which segments) to place parts
E.g., Fig 9.6
The –Z tells which segments (list of segments) to use and the start-address of the first
segment
The first line tells which segments to use for the code parts, starting at address 0; and the
second line tells which segments to use for the data parts, starting at x8000
The proper names and address info for the directing the locator are usually in the cross-
compiler documentation
Other directives: range of RAM and ROM addresses, end of stack address (segment is
placed below this address for stack to grow towards the end)
Segments/parts can also be grouped, and the group is located as a unit

75. •Initialized Data and Constant Strings
Segments with initialized values in ROM are shadowed (or copied into RAM)
for correct reset of initialized variables, in RAM, each time the system comes
up (esp. for initial values that are take #define constants, and which can be
changed)
In C programs, a host compiler may set all uninitialized variable to zero or
null, but this is not generally the case for embedded software cross-compilers
(unless the startup code in ROM does so
If part(s) of a constant string is(are) expected to be changed during run-time,
the cross-compiler must generate a code to allow ‘shadowing’ of the string
from ROM

76. Locator Maps and Executing Out of RAM
Output file of locators are Maps – list addresses of all segments
Maps are useful for debugging
An ‘advanced’ locator is capable of running (albeit slowly) a
startup code in ROM, which (could decompress and) load the
embedded code from ROM into RAM to execute quickly since
RAM is faster, especially for RISC microprocessors
(See Fig 9.7 – Maps)

79. 9.3 Getting Embedded Software into Target System
Moving maps into ROM or PROM, is to create a ROM using hardware
tools or a PROM programmer (for small and changeable software, during
debugging)
If PROM programmer is used (for changing or debugging software),
place PROM in a socket (which makes it erasable – for EPROM, or
removable/replaceable) rather than ‘burnt’ into circuitry
PROM’s can be pushed into sockets by hand, and pulled using a chip
puller
The PROM programmer must be compatible with the format
(syntax/semantics) of the Map
(See Fig 9.8)

81. 9.3 Getting Embedded Software into Target System – 1
ROM Emulators – Another approach is using a ROM emulator
(hardware) which emulates the target system, has all the ROM
circuitry, and a serial or network interface to the host system. The
locator loads the Map into the emulator, especially, for debugging
purposes.
Software on the host that loads the Map file into the emulator must
understand (be compatible with) the Map’s syntax/semantics
(See Fig 9.9)

83. 9.3 Getting Embedded Software into Target System – 2
Using Flash Memory
For debugging, a flash memory can be loaded with target Map code using a software on
the host over a serial port or network connection (just like using an EPROM)
Advantages:
No need to pull the flash (unlike PROM) for debugging different embedded code
Transferring code into flash (over a network) is faster and hassle-free
New versions of embedded software (supplied by vendor) can be loaded into flash
memory by customers over a network - Requires a) protecting the flash programmer,
saving it in RAM and executing from there, and reloading into flash after new version is
written and b) the ability to complete loading new version even if there are crashes and
protecting the startup code as in (a)
Modifying and/or debugging the flash programming software requires moving it into
RAM, modify/debug, and reloading it into target flash memory using above methods

84. THANK YOU