Session-1’s Topics

 Introduction to Embedded System

 Life cycle of an Embedded System
 Host-Target Development Tools
 Embedded Software Development Process
 Linking Embedded Systems
 Debugging Embedded Software
 Binary formats
 Cyclic redundancy check

1
Introduction to Embedded System

Definition:

 An embedded system is a special-purpose

computer system, which is completely
encapsulated by the device it controls.
 An embedded system has specific requirements
and performs pre-defined tasks, unlike a
general-purpose personal computer.

2
Introduction to Embedded System
Example Embedded System

3
 Introduction to Embedded System

Examples of the embedded systems

 Automatic Teller Machines (ATMs).

 Avionics, such as inertial guidance systems, flight control
hardware/software and other integrated systems in aircraft
and missiles.
 Cellular telephones and telephone switches.
 Engine controllers for automobiles.
 Home automation products, like thermostats, air conditioners,
sprinklers, and security monitoring systems.
 Medical equipment.
 Handheld computers.
 Even computer peripherals themselves such as routers and
printers have embedded processors.

4
 Introduction to Embedded System

Design Requirements

 Embedded computers typically have tight

constraints on both functionality and
implementation.
 They must guarantee real time operation
reactive to external events, conform to size and
weight limits, budget power and cooling
consumption, satisfy safety and reliability
requirements, and meet tight cost targets.

5
 Introduction to Embedded System

Design challenges:

 Small size, low weight

 Safe and reliable
 Harsh environment
 Cost sensitivity
 Power management

6
Life cycle of an Embedded System

7
Life cycle of an Embedded System-
Need/opportunity
 The launch of new product starts with study of
market and determining the needs and
opportunities available.
 The Embedded products are more often the not
are demand driven.

8
Life cycle of an Embedded System-
Concept development
 The toughest part in embedded product
development is developing of concept for a
saleable product.
 The concept should take into account the
requirements of the market.
 The concept should also look into cost and
feasibility considerations.

9
 Life cycle of an Embedded System-
Product/Process Design
 Product Design can be defined as the idea generation,
concept development, testing and manufacturing or
implementation of a physical object or service.
 Aesthetics is considered important in Product Design but
designers also deal with important aspects including
technology, ergonomics, usability, human factors and
material technology
 Process design: Involves specifying all practices needed,
flowcharting, rationalisation and error prevention.

10
Life cycle of an Embedded System-
Production
 Production is the application of tools and a
processing medium to the transformation of
raw materials into finished goods for sale. This
effort includes all intermediate processes
required for the production and integration of a
product's components.

11
Life cycle of an Embedded System-
Deployment
 The deployment of a mechanical device,
electrical system, computer program, etc. is its
assembly from a packaged form to an
operational state.
 Deployment should be interpreted as a general
process that has to be customized according to
specific requirements or characteristics

12
Life cycle of an Embedded System-
Maintenance/support
 Maintenance is the process of enhancing and
optimizing deployed software (software
release), as well as remedying defects.
 With the release of the product, other,
undocumented defects and deficiencies will be
discovered by the users of the software. As
these issues are reported into the development
organization, they will be entered into the defect
tracking system.

13
Life cycle of an Embedded System-
Upgrades
 Upgrades are provided to add newer features to
the existing products.
 Upgrades are also provided to sustain the
product a bit longer in market.

14
Life cycle of an Embedded System-
Retirement/disposal
 Once the product is no longer sustainable, it is
finally disposed.
 Then the company moves on to new product.

15
Host-Target Development Tools

 Embedded Systems Programming requires a

more complex software build process
 Target hardware platform consists of
 Target hardware (processor, memory, I/O)
 Runtime environment (Operating
System/Kernel)
 Target hardware platform contains only what is
needed for final deployment

16
Host-Target Development Tools
 Target hardware platform does not contain
development tools (editor, compiler, debugger).
 Target hardware platform is different from
development platform.
 Development platform, called the Host
Computer, is typically a general purpose
computer.
 Host computer runs compiler, assembler, linker,
locator to create a binary image that will run on
the Target embedded system.

17
 Embedded Software Development
Process
 Software Development is performed on a Host
computer
 Compiler, Assembler, Linker, Locator, Debugger
 Produces executable binary image that will run
on Target Embedded System

18
 Embedded Software Development
Process
 To develop software for a General Purpose
Computer.

 Create source file

 Type in C code

 Build: compile and link

 Execute: load and run

19
 Embedded Software Development
Process
 To develop software for an embedded system
 Create source file (on Host)
 Type in C code (on Host)
 Compile/Assemble: translate into machine code
(on Host)
 Link: combine all object files and libraries, resolve
all symbols (on Host)
 Locate: assign memory addresses to code and data
(on Host)
 Download: copy executable image into Target
processor memory
 Execute: reset Target processor

20
 Embedded Software Development
Process
 Compiler translates program written in human-
readable language into machine language
 Source Code --> Object file
 Object file is binary file that contains set of
machine-language instructions (opcodes) and
data resulting from language translation process

21
 Embedded Software Development
Process
 Machine-language instructions are specific to a
particular processor
 Can the host computer's compiler be used to
compile a program to run on the target
computer?
 A Native-compiler runs on a computer platform
and produces code for that same computer
platform
 A Cross-compiler runs on one computer platform
and produces code for another computer platform

22
 Embedded Software Development
Process
In some cases, a compiler is not used
 Assembler performs one-to-one translation from
human-readable assembly language mnemonics
to equivalent machine-language opcodes
 Interpreter constantly runs and interprets source
code as a set of directives
• Performs syntax checking as program is typed in.
• Result is slow performance - can be ~1000x slower
than an equivalent compiled language.
• Interactive capability provides more feedback --
easier to learn.

23
 Linking Embedded Systems
 The Linker combines object files (from compiler)
and resolves variable and function references
 Source code may be contained in >1 file, which
must be combined. Resolve variables which may
be referenced in one file and defined in another
file
 Resolve calls to library functions, like sqrt

 May include operating system

 Linker creates a .relocatable. version of the

program
 Program is complete, except no memory
addresses assigned

24
 Locating Embedded Systems

 A Locator is the tool that performs the

conversion from relocatable program to
executable binary image
 The Locator assigns physical memory addresses
to code and data sections within the relocatable
program
 The Locator produces a binary memory image
that can be loaded into the target ROM
 In contrast, On General Purpose Computers, the
operating system assigns the addresses at load
time
25
 Downloading and Executing Your
Program
 Once a program has been successfully compiled,
linked, and located, it must be moved to the target
platform
 Download the binary image to the embedded
system
 Executable binary image is transferred and loaded
into a memory device on target board
 Can be loaded into ROM via a device
programmer, which burns. a chip that is then re-
inserted into the embedded system
 Your program will then execute when you reset
the processor, or apply power to the embedded
system
26
 Debugging Embedded Software
 Now that the software has been downloaded to
the target processor, how do we know if it is
working?
 Run-time errors are not as obvious
 Most embedded systems do not have a .screen.
 When a program fails, usually causes the
processor to crash or lock-up
 Logic errors
 If program runs, is it performing the correct
steps?

27
Debugging Tools

28
 Debugging with Simulators

 Simulator is host-based program that simulates

functionality and instruction set of target
processor
 Front-end has text or GUI-based windows for
source code, register contents, etc
 Valuable during early stages of development

 Disadvantage: only simulates processor, not

peripherals

29
Debugging with Remote Debuggers

 Remote Debuggers used to monitor/control

embedded SW
 Used to download, execute and debug embedded
software over communications link (e.g., serial
port)
 Front-end has text or GUI-based windows for
source code, register contents, etc
 Backend provides low-level control of target
processor, runs on target processor and
communicates to front-end over comm-link .
Debugger and software being debugged are
executing on two different computer systems

30
 Debugging with Remote Debuggers

 Supports higher level of interaction between

host and target
 Allows start/restart/kill, and stepping through
program
 Software breakpoints (.stop execution if
instruction X is fetched.)
 Read/write registers or data at specified address

 Disadvantage: Requires target processor to run

more than final software package

31
 Debugging with In-Circuit
Emulators
In-Circuit Emulators (ICE)
 Take the place of (i.e., emulates) target
processor
 Contains copy of target processor, plus RAM,
ROM, and its own embedded software
 Allows you to examine state of processor while
program is running
 Uses Remote debugger for human interface

32
 Debugging with In-Circuit
Emulators
 Has more capability than target processor
 Supports software and hardware breakpoints
(stop execution on memory and I/O read/write,
interrupts) .Stop on write to variable num.
 Real-time tracing

 Stores information about each processor cycle

that is executed
 Allows you to see what order things happened

 Disadvantage: Expensive!

33
 Binary formats
 A format for representing data used by some
applications.
 The other main formats for storing data are text
formats (such as ASCII and EBCDIC), in which
each character of data is assigned a specific code
number.
 Binary formats are used for executable
programs and numeric data, whereas text
formats are used for textual data.
 Examples :
 Motorola s-format
 Intel HEX format.

34
 Motorola S-record

DESCRIPTION
 An S-record file consists of a sequence of
specially formatted ASCII character strings. An
S-record will be less than or equal to 78 bytes in
length. The order of S-records within a file is of
no significance and no particular order may be
assumed.
 The general format of an S-record follows:

35
 Motorola S-record

 type -- A char[2] field. These characters describe

the type of record (S0, S1, S2, S3, S5, S7, S8, or
S9).
 count -- A char[2] field. These characters when
paired and interpreted as a hexadecimal value,
display the count of remaining character pairs
in the record.

36
 Motorola S-record

 address -- A char[4,6, or 8] field.

 These characters grouped and interpreted as a
hexadecimal value, display the address at which
the data field is to be loaded into memory.
 The length of the field depends on the number
of bytes necessary to hold the address.
 A 2-byte address uses 4 characters, a 3-byte
address uses 6 characters, and a 4-byte address
uses 8 characters.

37
 Motorola S-record
 data -- A char [0-64] field.
 These characters when paired and interpreted
as hexadecimal values represent the memory
loadable data or descriptive information.
 checksum -- A char[2] field.
 These characters when paired and interpreted
as a hexadecimal value display the least
significant byte of the ones complement of the
sum of the byte values represented by the pairs
of characters making up the count, the address,
and the data fields.

38
 Motorola S-record
 Each record is terminated with a line feed. If any
additional or different record terminator(s) or delay
characters are needed during transmission to the target
system it is the responsibility of the transmitting
program to provide them.
 S0 Record. The type of record is 'S0' (0x5330). The
address field is unused and will be filled with zeros
(0x0000). The code/data field contains descriptive
information identifying the following block of S-records.
 S1 Record. The type of record field is 'S1' (0x5331). The
address field is interpreted as a 2-byte address. The data
field is composed of memory loadable data.

39
 Motorola S-record
 S2 Record. The type of record field is 'S2' (0x5332).
The address field is interpreted as a 3-byte
address. The data field is composed of memory
loadable data.
 S3 Record. The type of record field is 'S3' (0x5333).
The address field is interpreted as a 4-byte
address. The data field is composed of memory
loadable data.
 S5 Record. The type of record field is 'S5' (0x5335).
The address field is interpreted as a 2-byte value
and contains the count of S1, S2, and S3 records
previously transmitted. There is no data field.

40
 Motorola S-record
 S7 Record. The type of record field is 'S7' (0x5337).
The address field contains the starting execution
address and is interpreted as 4-byte address.
There is no data field.
 S8 Record. The type of record field is 'S8' (0x5338).
The address field contains the starting execution
address and is interpreted as 3-byte address.
There is no data field. (EASy68K always uses this
termination record type.)
 S9 Record. The type of record field is 'S9' (0x5339).
The address field contains the starting execution
address and is interpreted as 2-byte address.
There is no data field.
41
 Intel HEX File Format

 The "Intel-Standard" HEX file is one of the most

popular and commonly used formats in the
8052 world.
 The standard is used to burn the 8052 program
into an EPROM, PROM, etc.
 For example, an 8052 assembler will usually
generate an Intel Standard HEX file which can
then be loaded into an EPROM programmer
and burned into the chip.

42
 Intel HEX File Format

 An Intel Standard HEX file is an ASCII file with

one "record" per line. Each line has the
following format:

43
Intel HEX File Format

44
 Intel HEX File Format
Calculating the Checksum
 The checksum is calculated by summing the value of the
data on the line, excluding the leading colon and
checksum byte itself, and taking its two's complement.
 For example, the line:
:0300300002337A1E

 Breaking this line into it's components we have:

 Record Length: 03 (3 bytes of data)
 Address: 0030 (the 3 bytes will be stored at 0030, 0031, and
0032)
 Record Type: 00 (normal data)
 Data: 02, 33, 7A
 Checksum: 1E

45
 Cyclic redundancy check
 The CRC is a very powerful but easily implemented
technique to obtain data reliability.
 The CRC technique is used to protect blocks of data
called Frames.
 Using this technique, the transmitter appends an extra n-
bit sequence to every frame called Frame Check Sequence
(FCS).
 The FCS holds redundant information about the frame
that helps the transmitter detect errors in the frame.
 The CRC is one of the most used techniques for error
detection in data communications.
The technique gained its popularity because it combines
three advantages:
 Extreme error detection capabilities.
 Little overhead.
 Ease of implementation.
46
 Cyclic redundancy check
 The CRC algorithm works above the binary
field.
 The algorithm treats all bit streams as binary
polynomials.
 Given the original frame, the transmitter
generates the FCS for that frame.
 The FCS is generated so that the resulting frame
(the cascade of the original frame and the FCS),
is exactly devisable by some pre-defined
polynomial.
 This pre-defined polynomial is called the
devisor or CRC Polynomial.

47
 Cyclic redundancy check
For the formal explanation we will define the
following :

 M - The original frame to be transmitted, before

adding the FCS. It is k bits long.
 F - The resulting FCS to be added to M. It is n
bits long.
 T - The cascading of M and F. This is the
resulting frame that will be transmitted. It is
k+n bits long.
 P - The pre-defined CRC Polynomial. A pattern
of n+1 bits.

48
In Session-1 we have covered
 Introduction to Embedded System
 Life cycle of an Embedded System
 Host-Target Development Tools
 Embedded Software Development Process
 Linking Embedded Systems
 Debugging Embedded Software
 Binary formats
 Cyclic redundancy check

49