EMBEDDED SYSTEMS

UNIT-1
EMBEDDED
ARCHITECTURE
 TOPICS COVERED
 Embedded Computers
 Characteristics of Embedded Computing Applications
 Challenges in Embedded System Design
 Embedded System Design Process –
Requirements,
Specification,
Architectural Design,
 Designing Hardware and Software Components,
System Integration.
 EMBEDDED COMPUTERS
Computers have been embedded into applications
since the earliest days of computing.
Eg : Whirlwind
A computer designed at MIT in the late 1940s and
early 1950s.
Support real-time operation
It has a mechanism for controlling an aircraft
simulator.
Extremely large physically when compared to
today’s computers (e.g., it contained over 4,000
vacuum tubes)
Computers were proposed to control chemical
processes in the late 1940s
A microprocessor is a single-chip CPU.
The first microprocessor, the Intel 4004,was
designed for an embedded application
Eg: Calculator.

The calculator is not a general-purpose computer it

provides basic arithmetic functions.
 Integrated circuit design are expensive and time
consuming process, the ability to reuse the
hardware design by changing the software was a
key breakthrough.
Microprocessors are classified based on their word size.
An 8-bit microcontroller is designed for low-cost
applications and includes on-board memory and I/O devices.

A 16-bit microcontroller is often used for applications that

require either longer word lengths or off-chip I/O and
memory.

32-bit RISC microprocessor offers very high performance

for computation-intensive applications.
• Microprocessor types

 Microwave oven -has one microprocessor to control oven

operation.
 Advanced thermostat systems- change the temperature
level at various times during the day.
 Modern camera –has powerful features that can be added
under microprocessor control.
 Digital television -uses embedded processors
 Characteristics of Embedded Computing
Applications

1.Complex algorithms: The operations performed by

the microprocessor may be very complex.

Eg: The microprocessor that controls an automobile

engine must performs filtering functions to optimize
the performance of the car while minimizing
pollution and fuel utilization.
2.User interface: Microprocessors are frequently
used to control complex user interfaces that may
include multiple menus and many options.
• Eg: Global Positioning System (GPS)
3.Real time: Many embedded computing systems have to
perform in real time.
• If the data is not ready by a certain deadline, the system
breaks.
• Missing deadlines in printers can result in scrambled pages.
4. Multirate: Several real-time activities run at the same
time. Simultaneously control some operations that run at
slow rates and others that run at high rates.
Eg: Multimedia applications
• The audio and video portions of a stream should be
synchronized. If failed entire presentation is spoiled.
5.Manufacturing cost: The total cost of building the system is
very important.
Manufacturing cost is determined by factors such as

 Type of microprocessor used

 The amount of memory required
 The types of I/O devices.
6.Power and energy: Power consumption directly
affects the cost of the hardware.
Energy consumption
• Affects battery life
• Heat consumption in desktop
 Challenges in Embedded Computing
System Design

1. How much hardware do we need?

 Apart from the type of microprocessor used, care should
be taken to select the amount of memory, the peripheral
devices etc.
 Both performance deadlines and manufacturing cost
constraints should be met .
 Too little hardware -system fails to meet its deadlines
 Too much hardware-it becomes too expensive.
• 2. How do we meet deadlines?

 The brute force way of meeting a deadline is to speed up

the hardware so that the program runs faster.

 It makes the system more expensive.

 Increasing the CPU clock rate may not make enough

difference to execution time, since the program’s speed
may be limited by the memory system.
•
• 3.How do we minimize power consumption?

 In battery-powered applications, power consumption is

extremely important.

 In non battery applications, excessive power consumption

can increase heat dissipation.

 One way to make a digital system consume less power is to

make it run more slowly, but slowing down the system can
obviously lead to
.
•
• 4.How do we design for upgradability?

 The hardware platform may be used over several product

generations , or for several different versions of a product
in the same generation, with few or no changes.
•
• 5. Does it really work?

 Reliability is always important when selling products—

customers rightly expect that products they buy will work.

 Reliability is especially important in some applications,

such as safety-critical systems.
• 5.1 Complex testing: Exercising an
• embedded system is generally more
difficult than typing in some data.

5.2 Limited observability and controllability: Embedded

computing systems usually do not come with keyboards
and screens. This makes it more difficult to see what is
going on and to affect the system’s operation.

5.3 Restricted development environments: The development

environments for embedded systems are often much more
limited than those available for PCs and workstations.
 THE EMBEDDED SYSTEM DESIGN PROCESS
• A design methodology is important for three reasons.

 First, it allows us to keep a scorecard on a design

Eg: Optimizing performance.
 Second, it allows us to develop computer-aided design
tools.
 Third, a design methodology makes it much easier for
members of a design team to communicate
Steps in Embedded design
Major goals of the design:

Manufacturing cost
Performance (both overall speed and deadlines)
 Power consumption.
Tasks to be performed at every
step in the design process.

 We must analyze the design at

each step to determine how we
can meet the specifications.

 We must then refine the design to add detail.

 We must verify the design to ensure that it still meets all

system goals, such as cost, speed, and so on.
 Requirements

 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.
 Two phases:
 First, we gather an informal description from the
customers known as requirements.
Second we refine the requirements into a specification that
contains enough information to begin designing the system
architecture.
• Requirements may be
functional or nonfunctional.

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

 Power consumption: Power can be

specified in the requirements stage in terms of battery life.
Sample requirements form
that can be filled out at the
start of the project.

We can use the form as a

checklist in considering the basic
characteristics of the system.

• Let’s consider the entries in the form:

a)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.
B)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.
c)Inputs and outputs:
These two entries are more complex .

The inputs and outputs to the system consists:

 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?
d) Functions:

 Detailed description of what the system does.

Start working 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?
e)Performance:

 Many embedded computing systems spend at least

some time controlling physical devices or processing data
coming from the physical world.

 The computations must be performed within a certain

time frame.

 Performance requirements must be identified early to

ensure that the system works properly.
f)Manufacturing cost:
 This includes primarily the cost of
the hardware components.

g)Power:

 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.
h)Physical size and weight:

 A desktop machine has much more flexibility in the

components used than a lapel mounted voice recorder.
 SPECIFICATION

 The specification is more precise.

 It serves as the contract between the customer and the
architects.
 Specification must be carefully written so that it accurately
reflects the customer’s requirements.
 The specification should be easily understandable.
 System requirements and overall expectations of the
customer should be met.
• A specification of the GPS system would include several
components:

 Data received from the GPS satellite constellation.

 Map data
 User interface.
 Operations that must be performed to satisfy customer
requests.
 Background actions required to keep the system running,
such as operating the GPS receiver
 ARCHITECTURE DESIGN

The architecture is a plan for the overall structure of

the system .

It will be used in later phase to design the

components that make up the architecture.

The creation of the architecture is the first phase.

• Below is the sample system architecture for moving map in
the form of a block diagram that shows major operations
and data flows among them
 After designing an initial architecture we
should refine the system block diagram into
two block diagrams:

 One for hardware

 Another for software.

 The hardware block diagram clearly shows that we have

one central CPU surrounded by memory and I/O devices.
Two memories are used:

 Frame buffer- for the pixels to be displayed.

 Separate program/data memory -for general use by the
CPU.
• The software block diagram closely
follows the system block diagram, with
additional features
• Timer to control when we read the buttons on the user
interface and render data onto the screen.
• We must meet cost, speed, power, and other nonfunctional
constraints.
 Designing Hardware and Software Components
The architectural description tells us what components we
need.
The components will in general include both hardware—
FPGAs, boards, and so on and software modules.

Some of the components will be ready-made.

 The CPU and memory chips are standard components.

In the moving map, the GPS receiver is a good example of a
specialized predesigned, standard component.
Standard software modules.

Eg: Topographic database.

Standard routines are used to access the topographic

database.
 It is highly compressed to save storage.
 Saves design time.
Faster implementation for specialized functions such as the
data decompression phase.
 SYSTEM INTEGRATION
 Interconnecting all the components and check whether
system is working properly.
Bugs are typically found during system integration.
Good planning can help us find the bugs quickly.
System is built into phases and compiled seperately,
which makes to identify bugs more easily.
Identify simple bugs at earlier stages so that the more
complex or obscure bugs that can be
identified by system a hard workout.
 System integration is difficult because it usually uncovers
problems.

 Careful attention to inserting appropriate debugging

facilities during design can help ease system integration
problems.

 The nature of embedded computing means that this phase

will always be a challenge.
 EMBEDDED SYSTEMS

UNIT-2
REAL TIME OPERATING SYSTEM
CONCEPTS
 TOPICS COVERED

 Desk Top OS versus RTOS

 Architecture of the Kernel-task
 Task scheduler
 Interrupt Service Routines
 Semaphores-Mutex
 Mailboxes
 Message Queues
 Event Registers-Pipes-Signals
 Timers-Memory Management
 Priority Inversion Problem
 Desktop OS versus RTOS

DESKTOP OS RTOS
1)General purpose operating system do not 1)Suitable for real time operating system.
perform real time task.

2)Synchronization is difficult to achieve. 2)Synchronization is must in RTOS.

3)Inter communication does not exist 3)Inter communication is achieved.
4)Focus on computing throughput. 4)Focus on very fast response time.
5)Uses time sharing design for multitasking. 5)Uses time sharing design or event driven
design.

6)Normal coding is allowed 6)Coding is very strict.

7)Used in wide variety of applications. 7)Embedded in devices that require real
time responses.
 ARCHITECTURE OF KERNEL
 The kernel is the central module of an operating
system (OS).
 It is the part of the operating system that loads first, and it
remains in main memory.
 Because it stays in memory, it is important for the kernel to
be as small as possible .
 Provides services to other parts of OS & applications.

 The kernel code is usually loaded into a protected area of

memory to prevent it from being overwritten by programs
or other parts of the operating system.
 Typically, the kernel is responsible for
memory management, process and task
management, and disk management.

 The kernel connects the system hardware to the

application software.

 Every operating system has a kernel.

 Eg: Linux, FreeBSD, Android and others.

KERNEL ARCHITECTURE
 Functions of KERNEL

a)The central processing unit (CPU)

 This is the central component of a computer system and is

responsible for running or executing programs.

 Decides which running programs should be allocated to

the processor or processors
•
• b) Random-access memory (RAM)

 Random-access memory is used to store both program

instructions and data.

 For a program to execute it should contain both

instructions and data.

 Multiple programs can access the memory.

 The kernel is responsible for allocating memory to each

process.
•
• c) Input/output (I/O) devices

• I/O devices include peripherals as keyboards, mouse, disk

drives, printers, USB devices, network adapters, and display
devices.

• The kernel allocates requests from applications to perform

I/O to an appropriate device and provides convenient
methods for using the device
•
• d) Resource Management

 Kernels also provide methods

for synchronization and inter-process communication (IPC).

 These implementations may be within the Kernel itself or

the kernel can also rely on other processes it is running.
 e)Memory management

 The kernel has full access to the system's memory.

 Virtual Addressing usually achieved

by paging and/or segmentation.

 Virtual addressing allows the kernel to make a given

physical address appear to be another address.
 f) Device management

1. On the hardware side:

 Interfacing directly.
 Using a high level interface (Video BIOS).
 Using a lower-level device driver .
 Simulating work with hardware, while doing something
entirely different.
 f) Device management

2. On the software side:

 Allowing the operating system direct access to hardware

resources.
 Implementing only primitives.
 Implementing an interface for non-driver software
(Example: TWAIN).
 Implementing a language, sometimes high-level
(Example PostScript)
 TASKS

The basic building block of software in RTOS is task

Tasks are very simple to write.

Under RTOS tasks are simply a subroutine.

Each tasks in an RTOS is always in one of three
states.

A)Running-Microprocessor is executing the

instructions .

B)Ready-Task waits in a queue and if

microprocessor is available it executes the task.

C)Blocked-this state does nothing. Tasks enter

into this state because they are waiting for
some external event.
 TASK SCHEDULER
The scheduler keeps track of state of each task and decides
which task enters into running state.
Scheduler in RTOS is very simple they work based on
priorities.
If the higher priority task runs in microprocessor for long
time and lower priority task are waiting in queue it is too
bad.
 Block-move to blocked state.
 Run-move into running state.
 Switch-change which task is in running state.
A task only block itself only when it run out of things to do.

Other tasks in scheduler cannot decide for aa task that it

needs to wait for something.

While a task is blocked, it never gets micro processor.

An interrupt in system should signal that particular task is

waiting otherwise task is blocked forever.

The shuffling of tasks between ready and running states is

entirely the work of scheduler.
Task states
 INTERRUPT SERVICE ROUTINES

Interrupt routines must follow 2 rules:

Rule-1:An interrupt routine must not call any RTOS function

that might block the caller.

Rule 2:An interrupt routine may not call any RTOS that
might cause the RTOS to switch takes unless the RTOS
knows that an interrupt routine and not a task,is executing.
 SEMAPHORE
 Definition: A signal between tasks/interrupts that does not
carry any additional data.
 The most common type of semaphore is a
binary semaphore, that triggers activation of a task.
 The typical design pattern is that a task contains a main
loop with an RTOS call to “take” the semaphore.
• Eg: Consider a situation where there are two person who
wants to share a bike. At one time only one person can use
the bike. The one who has the bike key will get the chance
to use it. And when this person gives the key to 2nd person,
then only 2nd person can use the bike
 Semaphore is just like this Key and the bike is the shared
resource.

 Whenever a task wants access to the shared resource, it must

acquire the semaphore first.

 The task should release the semaphore after it is done with the
shared resource.

 Till this time all other tasks have to wait if they need access to
shared resource as semaphore is not available.

 Even if the task trying to acquire the semaphore is of higher

priority than the task acquiring the semaphore, it will be in wait
state until semaphore is released by the lower priority task.
Uses of Semaphores
 Managing Shared Resource

 Task Synchronization

 Unilateral Rendezvous- This is one way synchronization

which uses a semaphore as a flag to signal another task.

 Bilateral Rendezvous-This is two way synchronization

performed using two semaphores. A bilateral rendezvous is
similar to a unilateral rendezvous, except both tasks must
synchronize with one another before proceeding
 Types of Semaphores
 Binary Semaphore
Binary semaphore is used when there is only one
shared resource.

 Counting Semaphore
To handle more then one shared resource of same
type, counting semaphore is used.

 Mutual Exclusion Semaphore or Mutex

To avoid extended priority inversion, mutexes can be
used.
Operations on Semaphore

Basically, there are 3 operations related to the

semaphore:

Create
Acquire
Release
Create a Semaphore
Acquire a Semaphore
Release a Semaphore
 MUTEX

 Mutex is a special type of binary semaphore used for

controlling access to the shared resource.

 It is used to avoid extended priority inversion using priority

inheritance technique.
 Priority inheritance can be implemented in two ways :

 Changing the priority of the task trying to access the mutex

to the priority equal to the priority of the task

acquiring the mutex
to the higher priority than the priority of the task
acquiring the mutex

 So that the task trying to access the mutex will immediately

get the mutex when other task releases the mutex.

 The first way as adopted in FreeRTOS

 Create Mutex alone differs from semaphore.
Acquire and release are same as semaphore. Below is Create
mutex
 Example for mutex

/* Task 1 */
mutexWait(mutex_mens_room); // Safely use shared
resource mutexRelease(mutex_mens_room); /*

/*Task 2 */
mutexWait(mutex_mens_room); // Safely use shared
resource mutexRelease(mutex_mens_room);/*
 Mailboxes
 One of the important Kernel services used to sent the
Messages to a task is the message mailbox.

 A Mailbox is basically a pointer size variable.

 Tasks or ISRs can deposit and receive messages (the

pointer) through the mailbox.
• A task looking for a message from an empty mailbox is
blocked and placed on waiting list for a time (time out
specified by the task) or until a message is received.

• When a message is sent to the mail box, the highest

priority task waiting for the message is given the
message in priority-based mailbox or the first task to
request the message is given the message in FIFO based
mailbox.
• The operation of a mailbox object is similar to our
postal mailbox. When someone posts a message in
our mailbox , we take out the message.
• To manage the mailbox object, the following function calls
are provided in the OS API:

 Create a mailbox
 Delete a mailbox
 Query a mailbox
 Post a message in a mailbox
 Read a message form a mailbox.
 Message Queues
• The Message Queues ,are used to send one or more
messages to a task .

• The message queues are used to establish the Inter task

communication.

• Basically Queue is an array of mailboxes.

• Tasks and ISRs can send and receive messages to the Queue
through services provided by the kernel.

• Extraction of messages from a queue follow FIFO or LIFO

structure.
• Applications of message queue are

 Taking the input from a keyboard

 To display output
 Reading voltages from sensors or transducers
 Data packet transmission in a network
• In each of these applications, a task or an ISR deposits the
message in the message queue.

• Based on our application, the highest priority task or the

first task waiting in the queue can take the message.

• At the time of creating a queue, the queue is given a name

or ID, queue length, sending task waiting list and receiving
task waiting list.
• To use a message queue ,first it must be created.

• The creation of a Queue return a queue ID .

• So,if any task wish to post some message to a task ,it

should use its queue ID.

• qid = queue_create( “MyQueue” , Queue_options);

//*Queue name and OS specification options*//

The following function calls are provided to manage message
queues

 Create a queue
 Delete a queue
 Flush a queue
 Post a message in queue
 Post a message in front of queue
 Read message from queue
 Broadcast a message
 Show queue information
 Show queue waiting list.
 Event Registers

 Kernels provide a special register as part of each tasks

control block .This register, called an event register.

 It consists of a group of binary event flags used to track the

occurrence of specific events.

 Depending on a given kernel’s implementation of this

mechanism, an event register can be 8 or 16 or 32 bits
wide, may be even more.
Event register
 Each bit in the event register treated like a binary flag and
can be either set or cleared.

 Through the event register, a task can check for the

presence of particular events that can control its execution.

 An external source, such as a task or an ISR, can set bits in

the event register to inform the task that a particular event
has occurred.
• For managing the event registers, the following function
calls are provided:

 Create an event register

 Delete an event register
 Query an event register
 Set an event register
 Clear an event flag
 PIPE
 Pipes are kernel objects that are used to exchange
unstructured data and facilitate synchronization among
tasks.
 In a traditional implementation, a pipe is a unidirectional
data exchange facility, as shown in below Figure.
 Two descriptors, one for each end of the pipe (one end for
reading and one for writing), are returned when the pipe is
created.

 Data is written via one descriptor and read via the other.

 The data remains in the pipe as an unstructured byte

stream.

 Data is read from the pipe in FIFO order.

 A pipe provides a simple data flow facility so that the

reader becomes blocked when the pipe is empty, and the
writer becomes blocked when the pipe is full.
Typically, a pipe is used to exchange data between a
data-producing task and a data-consuming task, as
shown in the below Figure.
It is also permissible to have several writers for the
pipe with multiple readers on it.
• The function calls in the OS API to manage the pipes
are:

 Create a pipe
 Open a pipe
 Close a pipe
 Read from the pipe
 Write to the pipe
 SIGNALS
 A signal is an event indicator.
 It is a software interrupt that is generated when an event
occurs.
 It diverts the signal receiver from its normal execution path
and triggers the associated asynchronous processing.
 Mainly the , signals notify tasks of events that occurred
during the execution of other tasks or ISRs.
 The difference between a signal and a normal interrupt is
that signals are so-called software interrupts, which are
generated via the execution of some software within the
system.
 By contrast, normal interrupts are usually generated by the
arrival of an interrupt signal on one of the CPU’s external
pins.
 They are generated by external devices.

 The number and type of signals defined is both system-

dependent and RTOS dependent.
 An easy way to understand signals is to remember that
each signal is associated with an event.

 The event can be either unintentional, such as an illegal
instruction encountered during program execution, or the
event may be intentional, such as a notification to one task
from another that it is about to terminate.
• While a task can specify the particular actions to undertake
when a signal arrives, the task has no control over when it
receives signals.
 When a signal arrives, the task is diverted from its normal
execution path, and the corresponding signal routine is
invoked.

 Each signal is identified by an integer value, which is the

signal number or vector number.
• The function calls to manage a signal are

 Install a signal handler

 Remove an installed signal handler
 Send a signal to another task
 Block a signal from being delivered
 Unblock a blocked signal
 Ignore a signal.
 TIMERS

 A timer is the scheduling of an event according to a

predefined time value in the future, like setting an alarm
clock.

 For instance, the kernel has to keep track of different

times.

 A particular task may need to be executed periodically, say,

every 10ms.

 A timer is used to keep track of this periodicity.

 A task may be waiting in a queue for an event to occur. If
the event does not occur for a specified time, it has to take
appropriate action.
 A task may be waiting in a queue for a shared resource.
 If the resource is not available for a specified time, an
appropriate action has to be taken.
 The following function calls are provided to manage the
timer:
 Get time
 Set time
 Time delay (in system clock ticks)
 Time delay (in seconds)
 Reset timer
 MEMORY MANAGEMENT
It is a service provided by a kernel which allots the memory
needed ,either static or dynamic for various processes.

 The manager optimizes the memory needs and memory

utilization.

The memory manager allocates memory to the processes

and manages it with appropriate protection.

There may be static and dynamic allocations of memory.

An RTOS may disable the support to the dynamic block
allocation, MMU support to the dynamic page allocation
and dynamic binding as this increases the latency of
servicing the tasks and ISRs

• An RTOS may or may not support memory protection in

order to reduce the latency and memory needs of the
processes.
• The API provides the following function calls to manage
memory

 Create a memory block

 Get data from memory
 Post data in the memory
 Query a memory block
 Free the memory block.
 PRIORITY INVERSION PROBLEM
• In any real time embedded system ,if a high priority task is
blocked or waiting and a low priority task is running or
under execution ,this situation is called Priority Inversion.
• This priority Inversion is shown in the diagram below
 In Scheduling, priority inversion is the scenario where a low
priority Task holds a shared resource that is required by a
high priority task.

 This causes the execution of the high priority task to be

blocked until the low priority task releases the resource,
effectively “inverting” the relative priorities of the two
tasks.

 Suppose some other medium priority task, one that does

not depend on the shared resource, attempts to run in the
interim, it will take precedence over both the low priority
task and the high priority task.
• The consequences of the priority Inversion are

 (i) Reduce the performance of the system

 (ii) May reduce the system responsiveness which
leads to the violation of response time guarantees
 (iii) Create problems in real-time systems.
• The Priority Inversion is avoided by using two
protocols.

(i).Priority Inheritance Protocol (PIP)

(ii) Priority Ceiling Protocol(PCP).
 The Priority Inheritance Protocol is a resource access
control protocol that raises the priority of a task, if that
task holds a resource being requested by a higher priority
task.

 The priority ceiling protocol is a synchronization protocol

for shared resources to avoid unbounded priority inversion
and mutual deadlock due to wrong nesting of critical
sections .
 In this protocol each resource is assigned a priority ceiling,
which is a priority equal to the highest priority of any task
which may lock the resource.
 UNIT-3
PROGRAMMING FOR EMBEDDED
SYSTEMS
 TOPICS COVERED
 Embedded Program
 Role of Infinite loop
 Compiling, linking and locating
 Downloading and debugging
 Emulators and Simulators processor
 Overview of Embedded C
 Programming and Assembly
 Register usage conventions
 Procedure call and return
 Parameter passing
 Retrieving parameters
 Temporary variables
 Role of Infinite loop

An infinite loop (sometimes called an endless loop ) is a

piece of coding that lacks a functional exit so that it repeats
indefinitely.

Intentional uses for infinite loops include programs that

are supposed to run continuously, such as product demo or
in programming for embedded system .
 In computer programming, a loop is a sequence
of instruction that is continually repeated until a certain
condition is reached.

 Typically, a certain process is done, such as getting an item

of data and changing it, and then some condition is
checked, such as whether a counter has reached a
prescribed number.

 Infinite Loops are those program constructs where in there

is no break statement so as to get out of the loop, it just
keeps looping over the statements within the block
defined.
• Usually, an infinite loop results from a programming
error
Eg: where the conditions for exit are incorrectly
written
Compiling, Linking, and Locating
 Compiling

• The job of a compiler is to translate programs written in

human-readable language into an equivalent set of
opcodes for a particular processor.

• Each processor has its own unique machine language, so

you need to choose a compiler that is capable of producing
programs for your specific target processor.

• In the embedded systems case, “this compiler” almost

always runs on the host computer
• A compiler such as this-that runs on one computer
platform and produces code for another-is called a cross-
compiler.

• The use of a cross-compiler is one of the defining features

of embedded software development.

• The GNU C/C++ compiler ( gcc ) and assembler (as ) can be

configured as either native compilers or cross-compilers.

• As cross-compilers these tools support an impressive set of

host-target combinations.
• Regardless of the input language (C/C++, assembly, or any
other), the output of the cross-compiler will be an object
file.
• This is a specially formatted binary file that contains the set
of instructions and data resulting from the language
translation process.
• The contents of an object file can be thought of as a very
large, flexible data structure.

• The structure of the file is usually defined by a standard

format like the
• Common Object File Format (COFF)
• Extended Linker Format (ELF).
• Most object files begin with a header that describes the
sections that follow.

• Each of these sections contains one or more blocks of code

or data that originated within the original source file.

• These blocks have been regrouped by the compiler into

related sections.

• For example:
 All of the code blocks are collected into a section called
text.
 Initialized global variables into a section called data.
 Uninitialized global variables into a section called bss.
  Linking

 The job of the linker is to combine the object files and, in

the process, to resolve all of the unresolved symbols.

 The output of the linker is a new object file that contains all
of the code and data from the input object files and is in
the same object file format.

 It does this by merging the text, data, and bss sections of

the input files.

 While the linker is in the process of merging the section

contents, it is also on the lookout for unresolved symbols.
• The GNU linker (ld ) runs on all of the same host platforms
as the GNU compiler.

• The GNU linker also has a scripting language that can be

used to exercise tighter control over the object file that is
output.

• If the same symbol is declared in more than one object

file, the linker is unable to proceed.

• After merging all of the code and data sections and

resolving all of the symbol references, the linker produces a
special "relocatable" copy of the program.
  Locating

• The tool that performs the conversion from relocatable

program to executable binary image is called a locator.

• The locator will use this information to assign physical

memory addresses to each of the code and data sections
within the relocatable program.

• It will then produce an output file that contains a binary

memory image that can be loaded into the target ROM.
• The locator is a separate development tool.

• The memory information required by the GNU linker can be

passed to it in the form of a linker script.

• The result of this final step of the build process is an

absolutely located binary image that can be downloaded to
the embedded system or programmed into a read-only
memory device.
 Downloading and Debugging
• When the executable binary image stored as a file on the
host computer, you can download that image to the
embedded system and execute it.

• The executable binary image is usually loaded into a

memory device on the target board and executed from
there.
 Emulators

 Remote debuggers are helpful for monitoring and

controlling the state of embedded software.

 In-circuit emulator (ICE) actually takes the place of-or

emulates-the processor on your target board.

 ICE are usually pretty expensive than the target hardware.

 ICE is a powerful tool, and in a tight debugging spot

• A debug monitor, an emulator uses a remote debugger for
its human interface.

• The emulator supports powerful debugging features as

hardware breakpoints and real-time tracing.

• With a debug monitor, you can set breakpoints in your

program.

• These software breakpoints are restricted to instruction

fetches-the equivalent of the command "stop execution if
this instruction is about to be fetched."
• Another useful feature of an in-circuit emulator is real-time
tracing.

• An emulator incorporates a large block of special-purpose

RAM that is dedicated to storing information about each of
the processor cycles that are executed.

• This feature allows you to see in exactly what order things

happened.

Eg:Did the timer interrupt occur before or after the variable?

ROM Emulators
 A ROM emulator is a device that emulates a read-only
memory device.

 Like an ICE, it is an embedded system that connects to the

target and communicates with the host.

 The target connection is via a ROM socket.

 To the embedded processor, it looks like any other read-

only memory device.

 But to the remote debugger, it looks like a debug monitor.

 Simulators
• A simulator is a completely host-based program that
simulates the functionality and instruction set of the target
processor.

• They are quite valuable in the earlier stages of a project

when there is not yet any actual hardware for the
programmers to experiment with.

• Once you have access to your target hardware and

especially during the hardware debugging-logic analyzers
and oscilloscopes can be indispensable debugging tools.
• A logic analyzer is a piece of laboratory equipment
that is designed specifically for troubleshooting
digital hardware.

• It can have dozens or even hundreds of inputs, each

capable of detecting only one thing:

• whether the electrical signal it is attached to is

currently at logic level 1 or 0.
• An oscilloscope is another piece of laboratory equipment
for hardware debugging.

• They are used to examine any electrical signal, analog or

digital, on any piece of hardware.

• Oscilloscopes are sometimes useful for quickly observing

the voltage on a particular pin or, in the absence of a logic
analyzer, for something slightly more complex.
Difference between C and Embedded C
 Programming and Assembly
Factors for Selecting the Programming Language
The following are few factors that are to be considered
while selecting the Programming Language for the
development of Embedded Systems.
 Size: The memory that the program occupies is very
important as Embedded Processors like Microcontrollers
have a very limited amount of ROM.
 Speed: The programs must be very fast i.e. they must run
as fast as possible. The hardware should not be slowed
down due to a slow running software.
 Portability: The same program can be compiled for
different processors.
 Ease of Implementation
 Ease of Maintenance
 Readability
 Assembly languages were developed to provide mnemonics or
symbols for the machine level code instructions.

 Assembly language programs should be translated into

machine code.

 A program that is responsible for this conversion is known

as assembler.

 Assembly language is often termed as a low-level language

because it directly works with the internal structure of the CPU.

 To program in assembly language, a programmer must know all

the registers of the CPU
• Structure of Assembly Language
 An assembly language program is a series of statements,
which are either assembly language instructions such as
ADD and MOV, or statements called directives.
 An instruction tells the CPU what to do, while
a directive gives instruction to the assembler.

 A program language instruction consists of the following

four fields −

[ label: ] mnemonics [ operands ] [;comment ]

• The label field allows the program to refer to a line of code
by name. The label fields cannot exceed a certain number
of characters.

• The mnemonics and operands fields together perform the

real work of the program and accomplish the tasks.

• The comment field begins with a semicolon which is a

comment indicator.
 Procedure Call And Return
• In computer programming , a subroutine is a sequence of
program instructions that performs a specific task,
packaged as a unit.

• This unit can then be used in programs wherever that

particular task should be performed.

• Subprograms may be defined within programs, or

separately in libraries that can be used by many programs.
• In different programming languages, a subroutine may be
called a procedure, a function, a routine, a method, or
a subprogram. The generic term callable unit is sometimes
used.
• Eg program for procedure and return
• When you call a function in Embedded C, you need
to ensure mainly 5 things:

 Store the returning address somewhere, so that we can

continue executing the current function after completion of
called function.
 Saving other information about current function.
 Providing the callee with the parameters.
 Providing called function some space to store its automatic
variables.
 Providing some mechanism to get return value from the
called function. It's implemented using EAX register. Called
function stores return callee in EAX.
 Parameter Passing
 Parameters are passed between functions via the stack.

 For example, if a function foo1() calls a function foo2() with

2 parameters (say characters x and y).

 Then before the control jumps to the starting of foo2(), two

bytes are filled with the values that need to be passed.

 Once control jumps to the new function foo2(), and you

use the values (passed as parameters) in the function, they
are retrieved from the stack and used.
• There are two parameter passing techniques in use,
 1. Pass by Value
 2. Pass by Reference

• Parameter passing techniques can also use

 right-to-left (C-style)
 left-to-right (Pascal style)
 Pass by Value.
• Pass by Value, means that a copy of the data is made and
stored by way of the name of the parameter.

• In this method, the value of each of the actual arguments

in the calling function is copied into corresponding formal
arguments of the called function.

• In pass by value, the changes made to formal arguments in

the called function have no effect on the values of actual
arguments in the calling function.
Sample program for swap using pass by value
#include <stdio.h>
void swap(int x, int y) {
int t;
t = x;
x = y;
y = t;
} int main() {
int m = 10, n = 20;
printf("Before executing swap m=%d n=%d\n", m, n);
swap(m, n);
printf("After executing swap m=%d n=%d\n", m, n);
return 0;}
Output:
Before executing swap m=10 n=20
After executing swap m=10 n=20
• Pass by Reference. A reference parameter "refers" to the
original data in the calling function.

• In this method, the addresses of actual arguments in the

calling function are copied into formal arguments of the
called function.
Sample program using pass by reference
#include <stdio.h>
/* function definition */
void swap(int *x, int *y) {
int t;
t = *x; /* assign the value at address x to t */
*x = *y; /* put the value at y into x */
*y = t; /* put the value at to y */
} int main() {
int m = 10, n = 20;
printf("Before executing swap m=%d n=%d\n", m, n);
swap(&m, &n);
printf("After executing swap m=%d n=%d\n", m, n);
return 0;}
Output:
Before executing swap m=10 n=20
After executing swap m=20 n=10
 Retrieving Parameters
All Embedded C functions can be called either with
arguments or without arguments .
 These functions may or may not return values to the
calling function.
 C function with arguments (parameters) and with return
value.
 C function with arguments (parameters) and without return
value.
 C function without arguments (parameters) and without
return value.
 C function without arguments (parameters) and with return
value.
 TEMPORARY VARIABLE

• In computer programming, a temporary variable is

a variable with short lifetime, usually to hold data that will
soon be discarded, or before it can be placed at a more
permanent memory location.

• Because it is short-lived, it is usually declared as a

local variable, i.e., a variable with local scope.
Sample program for temporary variable
#include<stdio.h>
int main() {
int x, y, temp;
printf("Enter the value of x and y: ");
scanf("%d %d", &x, &y);
printf("Before swapping x=%d, y=%d ", x, y); /*Swapping logic */
temp = x;
x = y;
y = temp;
printf("After swapping x=%d, b=%d", x, y);
return 0; }
OUTPUT
Enter the value of x and y:10 30
Before swapping x=10,y=30
After swapping x=30.y=10
EMBEDDED SYSTEMS

UNIT-4
NETWORKS
 TOPICS COVERED

Distributed Embedded Architecture

Hardware and Software Architectures
 Networks for embedded systems
I2C
CAN Bus
SHARC link ports
 Ethernet
 Internet
Design Example: Elevator Controller.
 Distributed Embedded Architecture

• Basic units in distributed system architecture are the PE

and the network.
A PE may be an instruction set processor
such as a DSP, CPU, or microcontroller.

A nonprogrammable unit such as the ASIC used to

implement PE 4.

 An I/O device such as PE 1 - sensor or actuator,

depending on whether it provides input or output.

 The network used is a bus, but other network

topologies are also possible.
It is also possible that the system can use more than one
network.

The connection between PEs provided by the network as

a communication link.

The system of PEs and networks forms the hardware

platform on which the application runs.
 Hardware and Software Architectures
A point-to-point link establishes a connection between
exactly two PEs.

Point to-point links are simple to design because they deal

with only two components.
The figure given below is a simple example of a distributed
embedded system built from point-to-point links.
 The input signal is sampled by the input device and passed
to the first digital filter, F1, over a point-to-point link.

 The results of that filter are sent through a second point-to-

point link to filter F2.

 The results in turn are sent to the output device over a

third point-to-point link.

 A digital filtering system requires that its outputs arrive at

strict intervals, which means that the filters must process
their inputs in a timely fashion.
 Using point-to-point connections allows both F1 and F2 to
receive a new sample and send a new output at the same
time without worrying about collisions on the
communications network.

 It is possible to build a full-duplex, point-to-point

connection that can be used for simultaneous
communication in both directions between the two PEs.

 A bus is a more general form of network since it allows

multiple devices to be connected to it.
 Communications on the bus generally take the form of
packets.

 A packet contains an address for the destination and the

data to be delivered.
 Distributed system buses must be arbitrated to control
simultaneous access, just as with microprocessor buses.

 Arbitration scheme types are summarized below.

Fixed-priority arbitration always gives priority to

competing devices in the same way.
 If a high-priority and a low-priority device both have long
data transmissions ready at the same time, it is quite
possible that the low-priority device will not be able to
transmit anything until the high-priority device has sent all
its data packets.
 Fair arbitration schemes make sure that no device is
starved.

 Round-robin arbitration is the most commonly used of the

fair arbitration schemes.

 The PCI bus requires that the arbitration scheme used on

the bus must be fair, although it does not specify a
particular arbitration scheme.

 Most implementations of PCI use round-robin arbitration.

 NETWORKS FOR EMBEDDED SYSTEMS

• Networks for embedded computing span a broad range of

requirements.

• Some networks are used in safety-critical applications, such

as automotive control.

• Some networks, such as those used in consumer

electronics systems, must be very inexpensive.

• Other networks, such as industrial control networks,must

be extremely rugged and reliable.
• Several interconnect networks have been developed
especially for distributed embedded computing:

The I2C bus is used in microcontroller-based systems.

The Controller Area Network (CAN) bus was developed for

automotive electronics. It provides megabit rates and can
handle large numbers of devices.

Ethernet and variations of standard Ethernet are used for a

variety of control applications.
 I 2C bus
 The I 2C bus is a well-known bus commonly used to link
microcontrollers into systems.
 It has even been used for the command interface in an
MPEG-2 video chip.
 I2C is designed to be low cost, easy to implement, and of
moderate speed.
 It uses only two lines:

 The serial data line (SDL) for data

The serial clock line (SCL), which indicates when valid
data are on the data line.
 Every node in the network is connected to both SCL and
SDL.
 Some nodes may be able to act as bus masters and the bus
may have more than one master.

 Other nodes may act as slaves that only respond to

requests from masters.
 The figure depicts the structure of a typical I2C bus system.
• The basic electrical interface to the bus is shown in Figure

• The bus does not define particular voltages to be used for

high or low so that either bipolar or MOS circuits can be
connected to the bus.
 Both bus signals use open collector/open drain circuits.

 A pull-up resistor keeps the default state of the signal high,

and transistors are used in each bus device to pull down
the signal when a 0 is to be transmitted.

 Open collector/open drain signaling allows several devices

to simultaneously write the bus without causing electrical
damage.

 The master is responsible for generating the SCL clock.

 The I2C bus is designed as a multimaster bus—any one of
several different devices may act as the master at various
times.

 As a result, there is no global master to generate the clock

signal on SCL.

 Instead, a master drives both SCL and SDL when it is

sending data.

 When the bus is idle, both SCL and SDL remain high
A bus transaction is initiated by a start signal and
completed with an end signal as follows:

 A start is signaled by leaving the SCL high and sending

a 1 to 0 transition on SDL.
 A stop is signaled by setting the SCL high and sending
a 0 to 1 transition on SDL.
 CAN Bus

 CAN is very widely used in cars as well as in other

applications.

 The CAN bus uses bit-serial transmission.

 CAN runs at rates of 1 MB/s over a twisted pair connection

of 40 m.

 An optical link can also be used.

 The bus protocol supports multiple masters on the bus.

 As shown in Figure each node in the CAN bus has its own
electrical drivers and receivers that connect the node to the
bus in wired-AND fashion.
 In CAN terminology,
 logical 1 -recessive
 logical 0 - dominant.

 The driving circuits on the bus cause the bus to be pulled

down to 0 if any node on the bus pulls the bus down.

 When all nodes are transmitting 1s, the bus is in the

recessive state

 When a node transmits a 0, the bus is in the dominant

state.
 Data are sent on the network in packets known as data
frames.
 The format of a CAN data frame is shown in Figure.

 A data frame starts with a 1 and ends with a string of seven

zeroes.

 The first field in the packet contains the packet’s

destination address and is known as the arbitration field.
 The destination identifier is 11 bits long.
 The trailing remote transmission request (RTR) bit is set to
0 if the data frame is used to request data from the device
specified by the identifier.
 When RTR1, the packet is used to write data to the
destination identifier.

 The control field provides an identifier extension and a 4-

bit length for the data field with a 1 in between.

 The data field is from 0 to 64 bytes, depending on the

value given in the control field.

 A cyclic redundancy check (CRC) is sent after the data field

for error detection.
 The acknowledge field is used to let the identifier signal
whether the frame was correctly received.

 The sender puts a recessive bit (1) in the ACK slot of the
acknowledge field.

 If the receiver detected an error, it forces the value

to a dominant (0) value.

 If the sender sees a 0 on the bus in the ACK slot, it knows

that it must retransmit.

 The ACK slot is followed by a single bit delimiter followed

by the end-of-frame field.
 Internet

 The Internet Protocol (IP) is the fundamental protocol on

the Internet.

 It provides connectionless, packet-based communication.

Eg: Industrial automation

 Internet protocol is an internetworking standard.

 Internet packets are assumed to be carried by some other

network, such as an Ethernet.
 The relationship between IP and individual networks is
illustrated in Figure .

 IP works at the network layer.

 When node A wants to send data to node B, the

application’s data pass through several layers of the
protocol stack to send to the IP.
 IP creates packets for routing to the destination, which are
then sent to the data link and physical layers.

 A node that transmits data among different types of

networks is known as a router.

 At the destination, the IP layer provides data to the

transport layer and ultimately the receiving application.

 As the data pass through several layers of the protocol

stack, the IP packet data are encapsulated in packet
formats appropriate to each layer.
IP PACKET STRUCTURE
 The header and data payload are both of variable length.

 The maximum total length of the header and data payload

is 65,535 bytes.

 An Internet address is a number.

 The IP address is typically written in the form xxx.xx.xx.xx.

 Best Effort routing-The fact that IP works at the network

layer tells us that it does not guarantee that a packet is
delivered to its destination.
 The Internet also provides higher-level services built on top
of IP.
Eg: Transmission Control Protocol (TCP)

 It provides a connection oriented service that ensures that

data arrive in the appropriate order.

 It uses an acknowledgment protocol to ensure that

packets arrive.

 Because many higher level services are built on top of TCP,

the basic protocol is often referred to as TCP/IP.
• TCP is used to provide

File Transport Protocol-for batch file transfers

Hypertext Transport Protocol (HTTP) –for World Wide Web

service

 Simple Mail Transfer Protocol -for email, and Telnet for

virtual terminals.

User Datagram Protocol- is used for Simple Network

Management Protocol.
 Ethernet

 Ethernet is very widely used as a local area network for

general-purpose computing.

 The physical organization of an Ethernet is very simple.

 The network is a bus with a single signal path; the Ethernet

standard allows for several different implementations such
as twisted pair and coaxial cable.
 The Ethernet arbitration scheme is known as Carrier
Sense Multiple Access with Collision Detection (CSMA/CD).

 A node that has a message waits for the bus to become

silent and then starts transmitting.

 It simultaneously listens, and if it hears another

transmission that interferes with its transmission, it stops
transmitting and waits to retransmit.

 The maximum length of an Ethernet is determined by the

nodes’ ability to detect collisions.
CSMA/CD algorithm
 Figure below shows the basic format of an Ethernet packet.

 It provides addresses of both the destination and the

source.

 It also provides for a variable-length data payload.

 DESIGN EXAMPLE-ELEVATOR CONTROLLER

• The components are physically distributed among

the elevators and floors of the building, and the
system must meet both hard and soft.

• The configuration of a bank of elevators is shown in

Figure
 The elevator car is the unit that runs up and down the
hoistway carrying passengers.
 N represents the number of hoistways.
 Each car runs in a hoistway and can stop at any of F floors.
 Every elevator car has a car control panel that allows the
passengers to select floors to stop at.
 Each floor has a single floor control panel that calls for an
elevator.
 Each floor also has a set of displays to show the current
state of the elevator systems.
 The user interface consists of the elevator control panels,
floor control panels, and displays.
 The car control panels have F buttons to request the floors
plus an emergency stop button.
 Each floor control panel has an up button and a down
button that request an elevator going in the chosen
direction.
• The elevator control system consists of two types of
components.

1)a single master controller governs the overall behavior

of all elevators.
2)on each elevator a car controller runs everything that
must be done within the car.

• The car controller must of course sense button presses on

the car control panel, but it must also sense the current
position of the elevator.
 The coarse indicators run the entire length of the hoistway
and a sensor determines when the elevator passes each
one.

 Fine indicators are located only around the stopping point

for each floor.

 The elevator’s movement is controlled by two motor

control inputs:
one for up and one for down.

 When both are disabled, the elevator does not move.

Basic Requirement
Unit-5
CASE STUDY
 TOPICS COVERED
Data Compressor
Alarm clock
Cell phones
Audio player
Software Modem
Digital still camera
Telephone answering machine
Engine control unit
• Common topics under each case study

 Requirements
 Specification
 Class diagram
 System Architecture
 Component design and testing
 System integration and testing
 DATA COMPRESSOR
 Definition:
 A data compressor that takes in data with a constant
number of bits per data element and puts out a
compressed data stream in which the data is encoded in
variable-length symbols.

 Requirements and Algorithm

 We use the Huffman coding technique.

 The data compressor takes in a sequence of input symbols
and then produces a stream of output symbols.
Eg: If the input symbols are one byte in length. The output
symbols are variable length
 Choose a format in which to deliver the output data.
 Bit-by-bit delivery is almost certainly too slow.
 No one-to-one relationship between the input and output
symbols
 We may have to wait for several input symbols before a
packed output word comes out.
 Huffman coding for text compression

 Aims at statistical reductions in the volume of data.

 Commonly used compression algorithm is Huffman coding

 It uses information on the frequency of characters to

assign variable-length codes to characters.

 If shorter bit sequences are used to identify more frequent

characters, then the length of the total sequence will be
reduced.
 REQUIREMENTS
 SPECIFICATION

• For a fully functional system, we have to provide the

following additional behavior.

 Provide the compressor with a new symbol table.

 Flush the symbol buffer to cause the system to release all

pending symbols that have been partially packed.
 Class Diagram:

 A class description for this refined understanding of the

requirements on the module is shown in Figure
 The class’s buffer and current-bit behavior keep track of
the state of the encoding.
 The table attribute provides the current symbol table.
 The class has three methods as follows:

1) Encode:
 Performs the basic encoding function.
 It takes in a 1-byte input symbol and returns two values:

 A boolean showing whether it is returning a full buffer

 If the boolean is true, the full buffer itself.
2)New-symbol-table installs a new symbol table into the
object and throws away the current contents of the internal
buffer.

3) Flush returns the current state of the buffer, including the

number of valid bits in the buffer.

Additional class definition for the data compressor

 The data-buffer holds both packed symbols and unpacked
ones.

 The longest Huffman code for an eight-bit input symbol is

256 bits.

 The insert function packs a new symbol into the upper bits
of the buffer.

 The Symbol-table class indexes the encoded version of each

symbol.
 The class defines an access behavior for the table.
 Load behavior is used to create a new
symbol table.
State diagram for encode behavior
State diagram for insert behavior
 ALARM CLOCK

• In alarm clock microprocessor is used to read the clock’s

buttons and update the time display.
• Figure given below illustrates the front panel design for the
alarm clock.
REQUIREMENTS
 Specification
• Figure below shows the basic classes for the alarm clock.
We have three classes that represent physical elements:
 Lights-for all the digits and lights
 Buttons -for all the buttons
 Speaker-for the sound output.
 1)The Buzzer* class allows the buzzer to be
turned off.

2)The Buttons* class provides read-only access to the current

state of the buttons.

3)The Lights* class allows us to drive the lights.

 However, to save pins on the display, Lights* provides

signals for only one digit, along with a set of signals to
indicate which digit is currently being addressed.
 System Architecture
• The following are two major software components:

1) An interrupt-driven routine

 It updates the current time.

 The current time will be kept in a variable in memory.
 A timer can be used to interrupt periodically and update
the time.
 The display must be sent the new value when the minute
value changes.
 This routine can also maintain the PM indicator.
•
• 2) A foreground program can poll the buttons and
execute their commands.

• The foreground program will read the button values and

then use simple conditional tests to implement the
commands, including setting the current time, setting the
alarm,and turning off the alarm.

• Another routine called by the foreground program will turn

the buzzer on and off based on the alarm time.
 Component Design and Testing
 The two major software components, the interrupt handler
and the foreground code, can be implemented relatively
straightforwardly.

 The functionality of the interrupt handler is in the

interruption process itself, that code is best tested on the
microprocessor platform.
 The foreground code can be more easily tested on the PC
or workstation used for code development.

 We can create a testbench for this code that generates

button depressions to exercise the state machine.
 System Integration and Testing

 System has a small number of components, system

integration is relatively easy.
 The software must be checked to ensure that debugging
code has been turned off.
 Three types of tests can be performed.
 First, the clock’s accuracy can be checked against a
reference clock.
 Second, the commands can be exercised from the
buttons.
 Finally, the buzzer’s functionality should be
verified.
 AUDIO PLAYERS
 Audio players are often called MP3 players after the
popular audio data format.
 The earliest portable MP3 players were based on compact
disc mechanisms.
 Modern MP3 players use either flash memory or disk
drives to store music.

 An MP3 player performs three basic functions:

 Audio storage
 Audio decompression
 User interface.
 Audio compression is computationally intensive, audio
decompression is relatively lightweight.

 The incoming bit stream has been encoded using a

Huffman-style code, which must be decoded.

 The audio data itself is applied to a reconstruction filter,

along with a few other parameters.

 Eg: MP3 decoding can be executed using only 10% of an

ARM7 CPU.
 The user interface of an MP3 player is usually kept simple
to minimize both the physical size and power
consumption of the device.

 Many players provide only a simple display and a few

buttons.
 The file system of the player generally must be compatible
with PCs.
 CD/MP3 players used compact discs that had been created
on PCs.
 Today’s players can be plugged into USB ports and treated
as disk drives on the host processor.
Architecture of Cirrcus audio processor for
CD/MP3 players
 The Cirrus CS7410 is an audio controller designed for
CD/MP3 players.

 The audio controller includes two processors.

 The 32-bit RISC processor is used to perform system

control and audio decoding.
 The 16-bit DSP is used to perform audio effects such as
equalization.
• The memory controller has several different types of
memory:
 Flash memory can be used for data or code storage
 DRAM can be used as a buffer to handle temporary
disruptions of the CD data stream.

• The audio interface unit puts out audio in formats that can
be used by A/D converters.

• General-purpose I/O pins can be used to decode buttons,

run displays, etc.
 SOFTWARE MODEM

• Low-cost modems generally use specialized chips.

• Theory of Operation and Requirements:
• The modem will use frequency-shift keying (FSK),a
technique used in 1200-baud modems.
• The FSK scheme transmits sinusoidal tones, with 0 and 1
assigned to different frequencies.
 The scheme used to translate the audio input into a bit
stream is illustrated in Figure.
 The analog input is sampled and the resulting stream is
sent to two digital filters .

 One filter passes frequencies in the range that represents a

0 and rejects the 1-band frequencies, and the other filter
does the converse.
• The outputs of the filters are sent to detectors, which
compute the average value of the signal over the past n
samples.

• When the energy goes above a threshold value, the

appropriate bit is detected.
REQUIREMENTS
 System Architecture:
 The modem consists of one small subsystem and two major
subsystems (transmitter and receiver).

 Two sample interrupt handlers are required, one for input

and another for output, but they are very simple.

 The transmitter is simpler.

 The best way to generate waveforms that retain the proper

shape over long intervals is table lookup.

 Software oscillators can be used to generate periodic

signals.
• Component Design and Testing:

• The transmitter and receiver can be tested relatively

thoroughly on the host platform since the timing-critical
code only delivers data samples.

• If a DSP library for the target processor is used to

implement the filters, then a substitute must be found or
built for the host processor testing.
 System Integration and Testing:
 There are two ways to test the modem system:
1)The modem’s transmitter send bits to its receiver
2) By connecting two different modems.
 Single-unit testing, called loop-back testing in the
telecommunications industry, is simpler and a good first
step.

 Loop-back can be performed in two ways.

 First, a shared variable can be used to directly pass

data from the transmitter to the receiver.
 Second, an audio cable can be used to plug the analog
output to the analog input
 DIGITAL STILL CAMERAS
 The digital still camera not only captures images, it also
performs a processing of images that formerly was done by
photofinishers.

 Digital image processing allows us to fundamentally rethink

the camera.

 A simple example is digital zoom, which is used to extend

or replace optical zoom.
 Many cell phones include digital cameras, creating a hybrid
imaging/communication device.
Digital still cameras must perform many functions:

 It must determine the proper exposure for the photo.

 It must display a preview of the picture for framing.
 It must capture the image from the image sensor.
 It must transform the image into usable form.
 It must convert the image into a usable format, such as
JPEG, and store the image in a file system.
REQUIREMENTS
• System Architecture:
 Typical hardware architecture for a digital still camera is
shown in Figure .
 Most cameras use two processors.
 The controller sequences operations on the camera and
performs operations like file system management.
• The DSP concentrates on image processing.

• The DSP may be either a programmable processor or a set

of hardwired accelerators.

• Accelerators are often used to minimize power

consumption.

• The picture taking process can be divided into three main

phases:
 Composition
 Capture
 Storage.
 When the camera is turned on, it must start to display the
image on the camera’s screen.
 That imagery comes from the camera’s image sensor.
 To provide a reasonable image, it must adjust the image
exposure.

 The camera mechanism provides two basic exposure

controls:
 Shutter speed
 Aperture.

 The camera also displays what is seen through the lens on

the camera’s display.
When the user depresses the shutter button, a number of
steps occur.

 Before the image is captured, the final exposure must be

determined.

 Exposure is computed by analyzing the image

characteristics; histograms of the distribution of pixel
brightness are often used to determine focus.

The camera must also determine white balance.

 Different sources of light, such as sunlight and incandescent
lamps, provide light of different colors.

 The eye naturally compensates for the color of incident

light.

 The camera must perform comparable processing to avoid

giving the picture a color cast.

 White balance algorithms generally use color histograms to

determine the range of colors and re-weigh colors to
reduce casts.
• A commonly used pattern is the Bayer pattern shown in
Figure .
• This pattern uses two greens for every red and blue pixel
since the human eye is most sensitive to green.
• The camera must interpolate colors so that every pixel has
red, green, and blue values.
 Telephone Answering Machine

 The system will store messages in digital form rather than

on an analog tape.
 Simple algorithm is used to compress the voice data so
that we can make more efficient use of the limited amount
of available memory.

Theory of Operation and Requirements

 The compression scheme used is ADAPTIVE DIFFERENTIAL
PULSE CODE MODULATION (ADPCM).
• Specification
 We use classes to describe the incoming and OGMs.

 The major operational classes—Controls, Record, and

Playback.

 The Controls class provides an operate () behavior that

over sees the user-level operations.
 The Record and Playback classes provide behaviors that
handle writing and reading sample sequences
 REFERENCES
1 Wayne Wolf, “Computers as Components - Principles of Embedded
Computing System Design”,Morgan Kaufman Publishers, First Indian
Reprint, 2001.
2 Marilyn Wolf, “Computers as Components - Principles of Embedded
Computing System Design”, Morgan Kaufman Publishers, Third
edition, 2012.
3 K.V.K.K.Prasad ,“Embedded /Real-Time Systems: Concepts, Design and
programming” Dreamtech, Wiley 2003.
4. Dr.Y.Narasimha Murthy.Ph.D yayavaram@yahoo.com “REALTIME
OPERATING SYSTEMS AND CONCEPTS”140319131338.