1) Discuss in detail the 8051 instruction • Divide A by B and place quotient in A register &

set. remainder in B register.

Arithmetic instructions: Logical instructions in 8051:
 ADD
• 8-bit addition between the accumulator (A) and a  ANL : It performs AND logical operation between
second operand. two operands.
 Work on byte sized operands or the CY flag.
• The result is always in the accumulator. • ANL A, Rn
• The CY flag is set/reset appropriately. • ANL A, direct
 ADDC
• 8-bit addition between the accumulator, a second • ANL A, @Ri
operand and the previous value of the CY flag. • ANL A, #data
• Useful for 16-bit addition in two steps. • ANL direct, A
• The CY flag is set/reset appropriately. • ANL direct, #data
 DAA
• Decimal adjust the accumulator. • ANL C, bit

• Format the accumulator into a proper 2 digit packed • ANL C, /bit

BCD number.  ORL: It performs OR logical operation between two
operands.
• Operates only on the accumulator.  Work on byte sized operands or the CY flag.
• ORL A, Rn
• Works only after the ADD instruction.
 SUBB • ORL A, direct
• Subtract with Borrow.
• ORL A, @Ri
• Subtract an operand and the previous value of a
borrow (carry) flag from the accumulator. • ORL A, #data
• A  A - <operand> - CY.  XRL
 Works on bytes only.
• The result is always saved in the accumulator. • XRL A, Rn

• The CY flag is set/reset appropriately. • XRL A, direct

 INC  CPL / CLR
• Increment the operand by one.  Complement / Clear.

• The operand can be a register, a direct address, an  Work on the accumulator or a bit.
indirect address, the data pointer. • CLR P1.2
 DEC • CPL Rn
• Decrement the operand by one.
• The operand can be a register, a direct address, an  RL / RLC / RR / RRC
indirect address.  Rotate the accumulator.
 MUL AB / DIV AB • RL and RR without the carry
• Multiply A by B and place result in A and B registers. • RLC and RRC rotate through the carry
SWAP A: Swap the upper and lower nibbles of the
accumulator
Data transfer instructions  Push and Pop a data byte onto the stack.
 8-bit data transfer for internal RAM and the SFR.
• MOV A, Rn  The data byte is identified by a direct address from
the internal RAM locations.
• MOV A, direct • PUSH DPL
• MOV A, @Ri • POP 40H
 XCH
• MOV A, #data
 Exchange accumulator and a byte operand
• MOV Rn, A • XCH A, Rn

• MOV Rn, direct • XCH A, direct

• MOV Rn, #data • XCH A, @Ri

 XCHD
• MOV direct, A  Exchange lower digit of accumulator with the lower
• MOV direct, Rn digit of the memory location specified.
• XCHD A, @Ri
• MOV direct, direct
• The lower 4-bits of the accumulator are exchanged
• MOV direct, @Ri with the lower 4-bits of the internal memory location
identified indirectly by the index register.
• MOV direct, #data
• The upper 4-bits of each are not modified.
• MOV @Ri, A
• MOV @Ri, direct Boolean (or) Bit manipulation instructions in 8051.
 This group of instructions is associated with the
• MOV @Ri, #data single-bit operations of the 8051.
 MOV
 1-bit data transfer involving the CY flag  This group allows manipulating the individual bits
• MOV C, bit of bit addressable registers and memory locations as
well as the CY flag.
• MOV bit, C • The P, OV, and AC flags cannot be directly altered.
 MOV  This group includes:
 16-bit data transfer involving the DPTR • Set, clear, and, or complement, move.
• MOV DPTR, #data
 MOVC • Conditional jumps.
 Move Code Byte  CLR
• Load the accumulator with a byte from program Clear a bit or the CY flag.
memory.
• CLR P1.1
• Must use indexed addressing
• CLR C
• MOVC A, @A+DPTR  SETB
• Set a bit or the CY flag.
• MOVC A, @A+PC
 MOVX • SETB A.2
 Data transfer between the accumulator and a byte
• SETB C
from external data memory.
 CPL
• MOVX A, @Ri
• Complement a bit or the CY flag.
• MOVX A, @DPTR
• CPL 40H; Complement bit 40 of the bit addressable
• MOVX @Ri, A memory
 ORL / ANL
• MOVX @DPTR, A • OR / AND a bit with the CY flag.
 PUSH / POP
• ORL C, 20H; OR bit 20 of bit addressable memory  The 8051 provides 2 forms for the return instruction:
with the CY flag  Return from subroutine – RET
• Pop the return address from the stack and continue
• ANL C, 34H; AND bit 34 of bit addressable memory execution there.
with the CY flag.  Return from Interrupt Service Routine – RETI
 MOV • Pop the return address from the stack.
• Data transfer between a bit and the CY flag.
• Continue execution at the address retrieved from the
• MOV C, 3FH; Copy the CY flag to bit 3F of the bit stack.
addressable memory.
• The PSW is not automatically restored.
• MOV P1.2, C; Copy the CY flag to bit 2 of P1.  The 8051 supports 5 different conditional jump
 JC / JNC instructions.
• Jump to a relative address if CY is set / cleared.  ALL conditional jump instructions use an 8-bit
 JB / JNB signed offset.
• Jump to a relative address if a bit is set / cleared.
 Jump on Zero – JZ / JNZ
• JB ACC.2, <label> • Jump if the A == 0 / A != 0
 JBC - Jump to a relative address, if a bit is set and • The check is done at the time of the instruction
clear the bit. execution.
Branching instructions  Jump on Carry – JC / JNC
 The 8051 provides four different types of • Jump if the C flag is set / cleared.
unconditional jump instructions:  Jump on Bit – JB / JNB
 Short Jump – SJMP • Jump if the specified bit is set / cleared.
• Uses an 8-bit signed offset relative to the 1st byte of • Any addressable bit can be specified.
the next instruction.  Jump if the Bit is set then Clear the bit – JBC
• Long Jump – LJMP • Jump if the specified bit is set.

• Uses a 16-bit address. • Then clear the bit.

3 byte instruction capable of referencing any location  Compare and Jump if Not Equal – CJNE
in the entire 64K of program memory.  Compare the magnitude of the two operands and
 Absolute Jump – AJMP jump if they are not equal.
• Uses an 11-bit address. • The values are considered to be unsigned.

• 2 byte instruction • The Carry flag is set / cleared appropriately.

• The 11-bit address is substituted for the lower 11-bits • CJNE A, direct, rel
of the PC to calculate the 16-bit address of the target. • CJNE Rn, #data, rel
• The location referenced must be within the 2K Byte
memory. • CJNE @Ri, #data, rel
 Indirect Jump – JMP  Decrement and Jump if Not Zero – DJNZ
• JMP @A + DPTR  Decrement the first operand by 1 and jump to the
 The 8051 provides 2 forms for the CALL location identified by the second operand if the
instruction: resulting value is not zero.
 Absolute Call – ACALL • DJNZ Rn, rel
• Uses an 11-bit address similar to AJMP • DJNZ direct, rel
• The subroutine must be within the same 2K page.  NOP – No operation
 Long Call – LCALL
• Uses a 16-bit address similar to LJMP
• The subroutine can be anywhere.
 Both forms push the 16-bit address of the next
instruction on the stack and update the stack pointer.
 2) Write a program to generate a delay of 10ms.

MOV TMOD, #01 ;Timer 0, mode 1, 16-bitmode

HERE: MOV TL0, #00 ;TL0=0, the low byte
MOV TH0,#0DCH ;TH0=DC, the high byte
SETB TR0 ;Start timer 0
AGAIN: JNB TF0,AGAIN ;Monitor timer flag 0
CLR TR0 ;Stop the timer 0
CLR TF0 ;Clear timer 0 flag
3)Write a program for the 8051 to transfer “YES” serially at 9600 baud, 8-bit data, 1 stop bit do this
continuously.
Solution:
MOV TMOD, #20H ;timer 1, mode 2 (auto reload)
MOV TH1, #-3 ;9600 baud rate
MOV SCON, #50H ;8-bit, 1 stop, REN enabled
SETB TR1 ;start timer 1
AGAIN: MOV A, # “Y” ;transfer “Y”
ACALL TRANS
MOV A, # “E” ;transfer “E”
ACALL TRANS
MOV A, # “S” ;transfer “S”
ACALL TRANS
SJMP AGAIN ;keep doing it
;serial data transfer subroutine
TRANS: MOV SBUF, A ;load SBUF
HERE: JNB TI, HERE ;wait for the last bit
CLR TI ;get ready for next byte
RET

4) Explain Model Train Controller.

DESIGN EXAMPLE: MODEL TRAIN CONTROLLER
 In order to learn how to use UML to model systems, we will specify a simple system,
a model train controller. The user sends messages to the train with a control box
attached to the tracks.
 The control box may have familiar controls such as a throttle, emergency stop button,
and so on. Since the train receives its electrical power from the two rails of the track,
the control box can send signals to the train over the tracks by modulating the power
supply voltage. As shown in the figure, the control panel sends packets over the
tracks to the receiver on the train.
 The train includes analog electronics to sense the bits being transmitted and a
control system to set the train motor’s speed and direction based on those
commands.
 Each packet includes an address so that the console can control several trains on the
same track; the packet also includes an error correction code (ECC) to guard against
 transmission errors. This is a one-way communication system the model train cannot
send commands back to the user.
 We start by analyzing the requirements for the train control system.We will base our
system on a real standard developed for model trains.We then develop two
specifications: a simple, high- level specification and then a more detailed
specification.
Requirements
Before we can create a system specification, we have to understand the requirements. Here is a
basic set of requirements for the system:
 The console shall be able to control up to eight trains on a single track.
 The speed of each train shall be controllable by a throttle to at least 63 different levels in
each direction (forward and reverse).
 There shall be an inertia control that shall allow the user to adjust the responsiveness of
the train to commanded changes in speed.
 There shall be an emergency stop button.
 An error detection scheme will be used to transmit messages
 Higher inertia means that the train responds more slowly to a change in the throttle,
simulating the inertia of a large train. The inertia control will provide at least eight different
levels. Putting the requirements into chart format:

Name Model train controller

Purpose Control speed of up to eight model trains
Inputs Throttle, inertia setting, emergency stop, train
Outputs number Train control signals
Functions Set engine speed based upon inertia settings;
Performance respond to emergency stop ,Can update train
speed at least 10 times per second
Manufacturing cost $50
Power ,Physical size and weight 10W (plugs into wall)
Console should be comfortable for two hands,
approximate size of standard keyboard; weight<2
pounds
 Let’s consider the entries in the form: A Model train control system

Name: This is simple but helpful. Giving a name to the project not only simplifies
talking about it to other people but can also crystallize the purpose of the
machine.
Purpose: This should be a brief one- or two- line description of what the system is
supposed to do. If you can’t describe the essence of your system in one or two lines,
chances are that you don’t understand it well enough.
Inputs and outputs: These two entries are more complex than they seem. The
inputs and outputs to the system encompass a wealth of detail:
Types of data: Analog electronic signals? Digital data? Mechanical inputs?
Data characteristics: Periodically arriving data, such as digital audio samples?
Occasional user inputs? How many bits per data element?
Types of I/O devices: Buttons? Analog/digital converters? Video displays?
Functions: This is a more detailed description of what the system does. A good way
to approach this is to work from the inputs to the outputs

When the system receives an input, what does it do? How do user interface inputs affect these
functions? How do different functions interact?
□ Performance: Many embedded computing systems spend at least some time
controlling physical devices or processing data coming from the physical
world.
□ In most of these cases, the computations must be performed within a certain time frame. It
is essential that the performance requirements be identified early since they must be
carefully measured during implementation to ensure that the system works properly.
□ Manufacturing cost: This includes primarily the cost of the hardware components. Even
if you don’t know exactly how much you can afford to spend on system components, you
should have some idea of the eventual cost range. Cost has a substantial influence on
architecture.
□ A machine that is meant to sell at $10 most likely has a very different internal
structure than a $100 system.
□ Power: Similarly, you may have only a rough idea of how much power the system can
consume, but a little information can go a long way. Typically, the most important
decision is whether the machine will be battery powered or plugged into the wall. Battery-
powered machines must be much more careful about how they spend energy.
□ Physical size and weight: You should give some indication of the physical size of the
system to help guide certain architectural decisions. A desktop machine has much
more flexibility in the components used than, for example, a lapel mounted voice
recorder.
 DCC

□ The Digital Command Control (DCC) was created by the National Model Railroad
Association to support interoperable digitally-controlled model trains.
□ Hobbyists started building homebrew digital control systems in the 1970s
and Marklin developed its own digital control system in the 1980s.
□ DCC was created to provide a standard that could be built by any manufacturer
so that hobbyists could mix and match components from multiple vendors.
The DCC standard is given in two documents:
□ Standard S-9.1, the DCC Electrical Standard, defines how bits are
encoded on the rails for transmission.
□ Standard S-9.2, the DCC Communication Standard, defines the packets
that carry information.
□ Any DCC-conforming device must meet these specifications. DCC also provides
several recommended practices. These are not strictly required but they provide
some hints to manufacturers and users as to how to best use DCC.
□ The DCC standard does not specify many aspects of a DCC train system. It doesn’t
define the control panel, the type of microprocessor used, the programming
language to be used, or many other aspects of a real model train system.
□ The standard concentrates on those aspects of system design that are necessary for
interoperability.
□ Over standardization, or specifying elements that do not really need to be
standardized, only makes the standard less attractive and harder to
implement.
□ The Electrical Standard deals with voltages and currents on the track
□ The standard must be carefully designed because the main function of the track is to
carry power to the locomotives. The signal encoding system should not interfere with
power transmission either to DCC or non-DCC locomotives. A key requirement is
that the data signal should not change the DC value of the rails.
□ The data signal swings between two voltages around the power supply voltage. bits
are encoded in the time between transitions, not by voltage levels. A 0 is at least
100 ms while a 1 is nominally 58ms.
□ The durations of the high (above nominal voltage) and low (below nominal voltage)
parts of a bit are equal to keep the DC value constant. The specification also gives
the allowable variations in bit times that a conforming DCC receiver must be able to
tolerate.
□ The standard also describes other electrical properties of the system, such as
allowable transition times for signals.
□ The DCC Communication Standard describes how bits are combined into packets and
the meaning of some important packets.
□ Some packet types are left undefined in the standard but typical uses are given in
15
Recommended Practices documents.

16
 □ We can write the basic packet format as a regular expression:
PSA (sD) + E ( 1.1)

Bit encoding in DCC.

In this regular expression:

□ P is the preamble, which is a sequence of at least 10 1 bits. The command station

should send at least 14 of these 1 bits, some of which may be corrupted during
transmission.
□ S is the packet start bit. It is a 0 bit.
□ A is an address data byte that gives the address of the unit, with the most
significant bit of the address transmitted first. An address is eight bits long. The
addresses 00000000, 11111110, and 11111111 are reserved.
□ s is the data byte start bit, which, like the packet start bit, is a 0.
□ D is the data byte, which includes eight bits. A data byte may contain an address,
instruction, data, or error correction information.
□ E is a packet end bit, which is a 1 bit.
□ A packet includes one or more data byte start bit/data byte combinations. Note that
the address data byte is a specific type of data byte.
□ A baseline packet is the minimum packet that must be accepted by all DCC
implementations. More complex packets are given in a Recommended Practice
document.
□ A baseline packet has three data bytes: an address data byte that gives the intended
receiver of the packet; the instruction data byte provides a basic instruction; and an
error correction data byte is used to detect and correct transmission errors.
□ The instruction data byte carries several pieces of information. Bits 0–3 provide a
4- bit speed value.
□ Bit 4 has an additional speed bit, which is interpreted as the least significant speed
bit. Bit 5 gives direction, with 1 for forward and 0 for reverse. Bits 7–8 are set at 01
to indicate that this instruction provides speed and direction.
□ The error correction data byte is the bitwise exclusive OR of the address
and instruction data bytes.
□ The standard says that the command unit should send packets frequently since a
packet may be corrupted. Packets should be separated by at least 5 ms.

17
Conceptual Specification:
□ Digital Command Control specifies some important aspects of the system,
particularly those that allow equipment to interoperate. But DCC deliberately
does not specify everything about a model train control system.
□ A conceptual specification allows us to understand the system a little better. This
specification does not correspond to what any commercial DCC controllers do,
but is simple enough to allow us to cover some basic concepts in system design
□ A train control system turns commands into packets. A command comes from the
command unit while a packet is transmitted over the rails.
□ Commands and packets may not be generated in a 1-to-1 ratio. In fact, the DCC
standard says that command units should resend packets in case a packet is
dropped during transmission.
□ We now need to model the train control system itself. There are clearly two major
subsystems: the command unit and the train-board component. Each of these
subsystems has its own internal structure.
□ The command unit and receiver are each represented by objects; the command
unit sends a sequence of packets to the train’s receiver, as illustrated by the arrow.
□ The notation on the arrow provides both the type of message sent and its sequence
in a flow of messages; since the console sends all the messages, we have numbered
the arrow’s messages as 1..n. Those messages are of course carried over the track.
□ Since the track is not a computer component and is purely passive, it does not
appear in the diagram. However, it would be perfectly legitimate to model the
track in the collaboration diagram, and in some situations it may be wise to model
such nontraditional components in the specification diagrams. For example, if we
are worried about what happens when the track breaks, modeling the tracks would
help us identify failure modes and possible recovery mechanisms.
Class diagram for the train controller messages.

UML collaboration diagram for major subsystems of the train controller system.
 1

A UML class diagram for the train controller showing the composition of the subsystems.
□ Let’s break down the command unit and receiver into their major components. The
console needs to perform three functions: read the state of the front panel on the
command unit, format messages, and transmit messages. The train receiver must
also perform three major functions: receive the message, interpret the message.
□ It shows the console class using three classes, one for each of its major
components. These classes must define some behaviors, but for the moment we
will concentrate on the basic characteristics of these classes:
□ The Console class describes the command unit’s front panel, which contains
the analog knobs and hardware to interface to the digital parts of the system.
□ The Formatter class includes behaviors that know how to read the panel knobs
and creates a bit stream for the required message.
□ The Transmitter class interfaces to analog electronics to send the message along
the track.

□ There will be one instance of the Console class and one instance of each of the component
classes, as shown by the numeric values at each end of the relationship links. We have also
shown some special classes that represent analog components, ending the name of each with
an asterisk:
□ Knobs describes the actual analog knobs, buttons, and levers on the control panel.
□ Sender describes the analog electronics that send bits along the track.
□ Likewise, the Train makes use of three other classes that define its components:
□ The Receiver class knows how to turn the analog signals on the track into digital form.
□ The Controller class includes behaviors that interpret the commands and figures out how
to control the motor.
□ The Motor interface class defines how to generate the analog signals required to control the
motor.

We define two classes to represent analog components:

□ Detector detects analog signals on the track and converts them into digital
form.
□ Pulser turns digital commands into the analog signals required to
control the motor speed.
□ We have also defined a special class, Train set, to help us remember that the system
can handle multiple trains.
□ The values on the relationship edge show that one train set can have t trains. We would not
actually implement the train set class, but it does serve as useful
documentation of the existence of multiple receivers.
 1
5)Explain Designing with Computing platforms
THE EMBEDDED SYSTEM DESIGN PROCESS:  Once we know the components
The embedded system design process aimed at two we need, we can design those components,
objectives. including both software modules and any
 First, it will give us an introduction specialized hardware we need. Based on those
to the various steps in embedded components, we can finally build a complete
system design before we delve into system.
them in more detail. Second, it will
allow us to consider the design
methodology itself. 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. Developing
a single program that takes in a concept
for an embedded system and emits a
completed design would be a daunting
task, but by first breaking the process into
manageable steps, we can work on
automating the steps one at a time. Major levels of abstraction in the design process
 Third, a design
methodology makes it much easier The top–downdesign will begin with
for members of a design team to the most abstract description of the system
communicate. and conclude with concrete details. The
 By defining the overall process, team alternative is a bottom–up view in which
members can more easily understand what they are we start with components to build a
supposed to do, what they should receive from other system.
team members at certain times and what they are to hand Bottom–up design steps are shown
off when they complete their assigned steps. in the figure as dashed- line arrows. We
 Since most embedded systems are need bottom–up design because we do not
designed by teams, coordination is perhaps the most have perfect insight into how later stages of
important role of a well-defined design methodology. the design process will turn out.
 In this top–down view, we start with  Decisions at one stage of
the system requirements. In the next step, design are based upon estimates of what
 specification, we create a more detailed will happen later: How fast can we make a
description of what we want. particular function run? How much
 But the specification states only how memory will we need? How much system
the system behaves, not how it is built. bus capacity do we need? We also need to
 The details of the system’s consider the major goals of the design.
internals begin to take shape when we develop the  Manufacturing cost.
architecture, which gives the system structure in  Performance (both overall speed and
terms of large components. deadlines); and
 1
 Power consumption. can meet the
 We must also consider the Specifications.
tasks we need to perform at o We must then refine the design to add
every step in the design detail.
process. At each step in the o We must verify the design
design, we add detail: to ensure that it still meets
We must analyze the design at each all system goals, such as
step to determine how we cost, speed and so on.
o Requirements
Clearly, before we design a system, we must know what we are designing. The initial stages of the design
process capture this information for use in creating the architecture and components

 We generally proceed in two phases: First, we gather an informal description from the customers
known as requirements, and we refine the requirements into a specification that contains enough
information to begin designing the system architecture.
 Separating out requirements analysis and specification is often necessary because of the large gap
between what the customers can describe about the system they want and what the architects need
to design the system.
 Consumers of embedded systems are usually not themselves embedded system designers or even
product designers. Their understanding of the system is based on how they envision users’
interactions with the system. They may have unrealistic expectations as to what can be done within
their budgets; and they may also express their desires in a language very different from system
architects’ jargon.
 Capturing a consistent set of requirements from the customer and then massaging those requirements
into a more formal specification is a structured way to manage the process of translating from the
consumer’s language to the designer’s.
 Requirements may be functional or nonfunctional. We must of course capture the basic functions
of the embedded system, but functional description is often not sufficient.
 Typical nonfunctional requirements include:
 Performance: The speed of the system is often a major consideration both for the
usability of the system and for its ultimate cost. As we have noted, performance may
be a combination of soft performance metrics such as approximate time to perform a
user- level function and hard deadlines by which a particular operation must be
completed.
 Cost: The target cost or purchase price for the system is almost always a consideration. Cost
typically has two major components: manufacturing cost includes the cost of components and
assembly; nonrecurring engineering (NRE) costs include the personnel and other costs of
designing the system.
 Physical size and weight: The physical aspects of the final system can vary greatly depending upon
the application. An industrial control system for an assembly line may be designed to fit into a
standard-size rack with no strict limitations on weight. A handheld device typically has tight
requirements on both size and weight that can ripple through the entire system design.
 Power consumption: Power, of course, is important in battery-powered systems and is often
important in other applications as well. Power can be specified in the requirements stage in terms of
battery life—the customer is unlikely to be able to describe the allowable wattage.
 Validating a set of requirements is ultimately a psychological task since it requires understanding
both what people want and how they communicate those needs.
 1
One good way to refine at least the user interface portion of a system’s requirements is to build a

mock-up.
 The mock- up may use canned data to simulate functionality in a restricted
demonstration, and it may be executed on a PC or a workstation. But it should give the
customer a good idea of how the system will be used and how the user can react to it.
 Physical, nonfunctional models of devices can also give customers a better idea of
characteristics such as size and weight.
Sample requirements form.

Name
Purpose
Inputs
Outputs
Functions
Performance
Manufacturing cost
Power
Physical size and weight
 Requirements analysis for big systems can be complex and time consuming. However,
capturing a relatively small amount of information in a clear, simple format is a good
start toward understanding system requirements.
 To introduce the discipline of requirements analysis as part of system design, we will
use a simple requirements methodology.
We can use the requirement form as a checklist in considering the basic characteristics of the
system.
Name: This is simple but helpful. Giving a name to the project not only simplifies talking
about it to other people but can also crystallize the purpose of the machine.
Purpose: This should be a brief one- or two- line description of what the system is supposed to
do. If you can’t describe the essence of your system in one or two lines, chances are that you
don’t understand it well enough.

Inputs and outputs: These two entries are more complex than they seem. The inputs and
outputs to the system encompass a wealth of detail:
Types of data: Analog electronic signals? Digital data? Mechanical inputs?
Data characteristics: Periodically arriving data, such as digital audio samples? Occasional user
inputs? How many bits per data element?
Types of I/O devices: Buttons? Analog/digital converters? Video displays?
Functions: This is a more detailed description of what the system does. A good way to
approach this is to work from the inputs to the outputs: When the system receives an input, what
does it do? How do user interface inputs affect these functions? How do different functions
interact?
Performance: Many embedded computing systems spend at least some time controlling
physical devices or processing data coming from the physical world. In most of these cases,
the computations must be performed within a certain time frame. It is essential that the
 1
performance requirements be identified early since they must be carefully measured during
implementation to ensure that the system works properly.
Manufacturing cost: This includes primarily the cost of the hardware components. Even if
you don’t know exactly how much you can afford to spend on system components, you should
have some idea of the eventual cost range. Cost has a substantial influence on architecture: A
machine that is meant to sell at $10 most likely has a very different internal structure than a
$100 system.

Power: Similarly, you may have only a rough idea of how much power the system can
consume, but a little information can go a long way. Typically, the most important decision is
whether the machine will be battery powered or plugged into the wall. Battery-powered
machines must be much more careful about how they spend energy.
Physical size and weight:You should give some indication of the physical size of the
system to help guide certain architectural decisions. A desktop machine has much more
flexibility in the components used than, for example, a lapel mounted voice recorder.