MAHARAJA INSTITUTE OF TECHNOLOGY THANDAVAPUR

(Approved by AICTE, New Delhi and Affiliated to VTU, Belagavi)

Department of AI and ML
Subject Name
Introduction to Embedded System
Sub code: BETCK205J

Prepared by
Prof. Poornima H
Module -3
Hardware Software Co design and Program Modelling
Fundamental Issues in Hardware Software Co-Design
The following section illustrates some of the fundamental issues in hardware software co-
design.
1. Selecting the model: In hardware software co-design, models are used for capturing and
describing the system characteristics. A model is a formal system consisting of objects and
composition rules. It is hard to make a decision on which model should be followed in a
particular system design. Most often designers switch between a variety of models from the
requirements specification to the implementation aspect of the system design. The reason
being, the objective varies with each phase.
2. Selecting the Architecture: The architecture specifies how a system is going to implement in
terms of the number and types of different components and the interconnection among them.
Controller Architecture, Datapath Architecture, Complex Instruction Set Computing (CISC),
Reduced Instruction Set Computing (RISC), Very Long Instruction Word Computing (VLIW),
Single Instruction Multiple Data (SIMD), Multiple Instruction Multiple Data (MIMD), etc. are
the commonly used architectures in system design. Some of them fall into Application Specific
Architecture Class (like Controller Architecture), while others fall into either general purpose
architecture class (CISC, RISC, etc.) or Parallel processing class (like VLIW, SIMD, MIMD,
etc.).
 The Controller Architecture implements: the finite state machine model (which we will
discuss in a later section) using a state register and two combinational circuits (we will discuss
about combinational circuits in a later chapter). The state register holds the present state and
the combinational circuits implement the logic for next state and output.
 The Datapath Architecture is best suited for implementing the data flow graph model where
the output is generated as a result of a set of predefined computations on the input data. A
datapath represents a channel between the input and output and in datapath architecture the
datapath may contain registers, counters, register files, memories and ports along with high
speed arithmetic units. Ports connect the datapath to multiple buses.
 The Finite State Machine Datapath (FSMD) architecture combines the controller architecture
with datapath architecture. It implements a controller with datapath. The controller generates
the control input whereas the datapath processes the data. The datapath contains two types of
I/O ports, out of which one acts as the control port for receiving/sending the control signals
from/to the controller unit and the second I/O port interfaces the datapath with external world
for data input and data output. Normally the datapath is implemented in a chip and the I/O pins
of the chip acts as the data input output ports for the chip resident data path.
 The Complex Instruction Set Computing (CISC) architecture uses an instruction set
representing complex operations. It is possible for a CISC instruction set to perform a large
complex operation (e.g. Reading a register value and comparing it with a given value and then
transfer the program execution to a new address location (The CJNE instruction for 8051 ISA))
with a single instruction. The use of a single complex instruction in place of multiple simple
instructions greatly reduces the program memory access and program memory size
requirement. However it requires additional silicon for implementing microcode decoder for
decoding the CISC instruction. The datapath for the CISC processor is complex. On the other
hand, Reduced Instruction Set Computing (RISC) architecture uses instruction set representing
simple operations and it requires the execution of multiple RISC instructions to perform a
complex operation.

MIT Thandavapura
  The Very Long Instruction Word ( VLIW) architecture implements multiple functional units
(ALUs, multipliers, etc.) in the datapath. The VLIW instruction packages one standard
instruction per functional unit of the datapath.
 Parallel processing architecture implements multiple concurrent Processing Elements (PEs)
and each processing element may associate a datapath containing register and local memory.
Single Instruction Multiple Data ( SIMD) and Multiple Instruction Multiple Data ( MIMD)
architectures are examples for parallel processing architecture.
3. Selecting the language: A programming language captures a ‘Computational Model’ and
maps it into architecture. A model can be captured using multiple programming languages like
C, C++, C#, Java, etc. for software implementations and languages like VHDL, System C,
Verilog, etc. for hardware implementations. On the other hand, a single language can be used
for capturing a variety of models. Certain languages are good in capturing certain
computational model. For example, C++ is a good candidate for capturing an object oriented
model. The only pre-requisite in selecting a programming language for capturing a model is
that the language should capture the model easily.
4. Partitioning System Requirements into hardware and so ware So far we discussed about the
models for capturing the system requirements and the architecture for implementing the
system. It may be possible to implement the system requirements in either hardware or software
(firmware). It is a tough decision making task to figure out which one to opt. Various hardware
software trade-offs are used for making a decision on the hardware-software partitioning.

COMPUTATIONAL MODELS IN EMBEDDED DESIGN

7.2.1 Data Flow Graph/Diagram (DFG) Model

 The Data Flow Graph (DFG) model translates the data processing requirements into a
data flow graph.
 The Data Flow Graph (DFG) model is a data driven model in which the program
execution is determined by data.
 This model emphasises on the data and operations on the data which transforms the
input data to output data. Indeed Data Flow Graph (DFG) is a visual model in which
the operation on the data (process) is represented sing a block (circle) and data flow is
represented using arrows.
 An inward arrow to the process (circle) represents input data and an outward arrow
from the process (circle) represents output data in DFG notation. Embedded
applications which are computational intensive and data driven are modeled using the
DFG model.
 DSP applications are typical examples for it. Now let’s have a look at the
implementation of a DFG. Suppose one of the functions in our application contains the
computational requirement x = a + b; and y = x – c. Figure 7.1 illustrates the

MIT Thandavapura
 implementation of a DFG model for implementing these requirements. In a DFG model,
a data path is the data flow path from input to output.
 A DFG model is said to be acyclic DFG (ADFG) if it doesn’t contain multiple values
for the input variable and multiple output values for a given set of input(s). Feedback
inputs (Output is fed back to Input), events, etc. are examples for non-acyclic inputs. A
DFG model translates the program as a single sequential process execution.

7.2.2 Control Data Flow Graph/Diagram (CDFG):



We have seen that the DFG model is a data driven model in which the execution is controlled
by data and it doesn’t involve any control operations (conditionals).
 The Control DFG ( CDFG) model is used for modelling applications involving conditional
program execution.
 CDFG models contains both data operations and control operations.
 The CDFG uses Data Flow Graph (DFG) as element and conditional (constructs) as decision
makers. CDFG contains both data flow nodes and decision nodes, whereas DFG contains only
data flow nodes.
 Let us have a look at the implementation of the CDFG for the following requirement. If flag =
1, x = a + b; else y = a – b; this requirement contains a decision making process. The CDFG
model for the same is given in Fig. 7.2.
 The control node is represented by a ‘Diamond’ block which is the decision making element
in a normal flow chart based design. CDFG translates the requirement, which is modeled to a
concurrent process model. The decision on which process is to be executed is determined by
the control node.
 A real world example for modelling the embedded application using CDFG is the capturing
and saving of the image to a format set by the user in a digital still camera where everything is
data driven starting from the Analog Front End which converts the CCD sensor generated
analog signal to Digital Signal and the task which stores the data from ADC to a frame buffer
for the use of a media processor which performs various operations like, auto correction, white
balance adjusting, etc. The decision on, in which format the image is stored (formats like JPEG,
TIFF, BMP, etc.) is controlled by the camera settings, configured by the user.

MIT Thandavapura
7.2.3 State Machine Model:
The State Machine model is used for modelling reactive or event-driven embedded systems whose
processing behaviour are dependent on state transitions. Embedded systems used in the control and
industrial applications are typical examples for event driven systems. The State Machine model
describes the system behaviour with ‘States’, ‘Events’, ‘Actions’ and ‘Transitions’. State is a
representation of a current situation. An event is an input to the state. The event acts as stimuli for state
transition. Transition is the movement from one state to another. Action is an activity to be performed
by the state machine. A Finite State Machine (FSM) model is one in which the number of states are
finite. In other words the system is described using a finite number of possible states. As an example
let us consider the design of an embedded system for driver/passenger ‘Seat Belt Warning’ in an
automotive using the FSM model. The system requirements are captured as.

1. When the vehicle ignition is turned on and the seat belt is not fastened within 10 seconds of ignition
ON, the system generates an alarm signal for 5 seconds.
2. The Alarm is turned off when the alarm time (5 seconds) expires or if the driver/passenger fastens
the belt or if the ignition switch is turned off, whichever happens first. Here the states are ‘Alarm Off’,
‘Waiting’ and ‘Alarm On’ and the events are ‘Ignition Key ON’,
‘Ignition Key OFF’, ‘Timer Expire’, ‘Alarm Time Expire’ and ‘Seat Belt ON’. Using the FSM, the
system requirements can be modelled as given in Fig. 7.3. The ‘Ignition Key ON’ event triggers the
10 second timer and transitions the state to ‘Waiting’. If a ‘Seat Belt ON’ or ‘Ignition Key OFF’ event
occurs during the wait state, the state transitions into ‘Alarm Off. When the wait timer expires in the
waiting state, the event ‘Timer Expire’ is generated and it transitions the state to ‘Alarm On’ from the
‘Waiting’ state. The ‘Alarm On’ state continues until a ‘Seat Belt ON’ or ‘Ignition Key OFF’ event or
‘Alarm Time Expire’ event, whichever occurs first.

MIT Thandavapura
The occurrence of any of these events transitions the state to ‘Alarm Off’. The wait state is
implemented using a timer. The timer also has certain set of states and events for state transitions.
Using the FSM model, the timer can be modelled as shown in Fig. 7.4.
As seen from the FSM, the timer state can be either ‘IDLE’ or ‘READY’ or ‘RUNNING’. During the
normal condition when the timer is not running, it is said to be in the ‘IDLE’ state. The timer is said
to be in the ‘READY’ state when the timer is loaded with the count corresponding to the required time
delay. The timer remains in the ‘READY’ state until a ‘Start Timer’ event occurs. The timer changes
its state to ‘RUNNING’ from the ‘READY’ state on receiving a ‘Start Timer’ event and remains in
the ‘RUNNING’ state until the timer count expires or a ‘Stop Timer’ even occurs. The timer state
changes to ‘IDLE’ from ‘RUNNING’ on receiving a ‘Stop Timer’ or ‘Timer Expire’ event.

Example 1
Design an automatic tea/coffee vending machine based on FSM model for the following requirement.
The tea/coffee vending is initiated by user inserting a 5 rupee coin. After inserting the coin, the user
can either select ‘Coffee’ or ‘Tea’ or press ‘Cancel’ to cancel the order and take back the coin. The
FSM representation for the above requirement is given in Fig. 7.5.

In its simplest representation, it contains four states namely; ‘Wait for coin’ ‘Wait for User Input’,
‘Dispense Tea’ and ‘Dispense Coffee’. The event ‘Insert Coin’ (5 rupee coin insertion), transitions the
state to ‘Wait for User Input’. The system stays in this state until a user input is received from the
buttons ‘Cancel’, ‘Tea’ or ‘Coffee’ (Tea and Coffee are the drink select button). If the event triggered
in ‘Wait State’ is ‘Cancel’ button press, the coin is pushed out and the state transitions to ‘Wait for
Coin’. If the event received in the ‘Wait State’ is either ‘Tea’ button press, or ‘Coffee’ button press,
the state changes to ‘Dispense Tea’ and ‘Dispense Coffee’ respectively. Once the coffee/tea vending
is over, the respective states transitions back to the ‘Wait for Coin’ state. A few modifications like
adding a timeout for the ‘Wait State’ (Currently the ‘Wait State’ is infinite; it can be re-designed to a
timeout based ‘Wait State’. If no user input is received within the timeout period, the coin is returned
back and the state automatically transitions to ‘Wait for Coin’ on the timeout event) and capturing
another events like, ‘Water not available’, ‘Tea/Coffee Mix not available’ and changing the state to an
‘Error State’ can be added to enhance this design. It is left to the readers as exercise.
Example 2
Design a coin operated public telephone unit based on FSM model for the following requirements.
1. The calling process is initiated by lifting the receiver (off-hook) of the telephone unit

MIT Thandavapura
2. After lifting the phone the user needs to insert a 1 rupee coin to make the call.
3. If the line is busy, the coin is returned on placing the receiver back on the hook (on-hook)
4. If the line is through, the user is allowed to talk till 60 seconds and at the end of 45th second, prompt
for inserting another 1 rupee coin for continuing the call is initiated
5. If the user doesn’t insert another 1 rupee coin, the call is terminated on completing the 60 seconds
time slot.
6. The system is ready to accept new call request when the receiver is placed back on the hook (on-
hook)
7. The system goes to the ‘Out of Order’ state when there is a line fault.
The FSM model shown in Fig. 7.6, is a simple representation and it doesn’t take care of scenarios like,
user doesn’t insert a coin within the specified time after lifting the receiver, user inserts coins other
than a one rupee etc. Handling these scenarios is left to the readers as exercise. Most of the time state
machine model translates the requirements into sequence driven program and it is difficult to
implement concurrent processing with FSM. This limitation is addressed by the Hierarchical/
Concurrent Finite State Machine model (HCFSM). The HCFSM is an extension of the FSM for
supporting concurrency and hierarchy. HCFSM extends the conventional state diagrams by the AND,
OR decomposition of States together with inter level transitions and a broadcast mechanism for
communicating between concurrent processes. HCFSM uses state charts for capturing the states,
transitions, events and actions. The Harel State chart, UML State diagram, etc. are examples for
popular state charts used for the HCFSM modelling of embedded systems. In state charts, the state is
usually represented using geometric shapes like rounded rectangle, rectangle, ellipse, circle, etc. The
Harel Statechart uses a rounded rectangle for representing state. Arrows are used for representing the
state transition and they are marked with the event associated with the state transition. Sometimes an
optional parenthesised condition is also labelled with the arrow. The condition specifies on what basis
the state transition happens at the occurrence of the specified event. Lots of design tools are available
for state machine and statechart based system modelling.

MIT Thandavapura
7.2.4 Sequential Program Model
In the sequential programming Model, the functions or processing requirements are executed in
sequence. It is same as the conventional procedural programming. Here the program instructions are
iterated and executed conditionally and the data gets transformed through a series of operations. FSMs
are good choice for sequential program modelling. Another important tool used for modelling
sequential program is Flow Charts. The FSM approach represents the states, events, transitions and
actions, whereas the Flow Chart models the execution flow. The execution of functions in a sequential
program model for the ‘Seat Belt Warning’ system is illustrated below.
Figure 7.7 illustrates the flow chart approach for modelling the ‘Seat Belt Warning’ system explained
in the FSM modelling section.

7.2.5 Concurrent/Communicating Process Model

The concurrent or communicating process model models concurrently executing tasks/processes. So
far we discussed about the sequential execution of software programs. It is easier to implement certain
requirements in concurrent processing model than the conventional sequential execution. Sequential
execution leads to a single sequential execution of task and thereby leads to poor processor utilisation,
when the task involves I/O waiting, sleeping for specifi ed duration etc. If the task is split into multiple
subtasks, it is possible to tackle the CPU usage effectively, when the subtask under execution goes to
a wait or sleep mode, by switching the task execution. However, concurrent processing model requires

MIT Thandavapura
additional overheads in task scheduling, task synchronisation and communication. As an example for
the concurrent processing model let us examine how we can implement the ‘Seat Belt Warning’ system
in concurrent processing model. We can split the tasks into:
1. Timer task for waiting 10 seconds (wait timer task)
2. Task for checking the ignition key status (ignition key status monitoring task)
3. Task for checking the seat belt status (seat belt status monitoring task)
4. Task for starting and stopping the alarm (alarm control task)
5. Alarm timer task for waiting 5 seconds (alarm timer task)
We have fi ve tasks here and we cannot execute them randomly or sequentially. We need to
synchronise their execution through some mechanism. We need to start the alarm only after the
expiration of the 10 seconds wait timer and that too only if the seat belt is OFF and the ignition key is
ON. Hence the alarm control task is executed only when the wait timer is expired and if the ignition
key is in the ON state and seat belt is in the OFF state. Here we will use events to indicate these
scenarios. The wait_timer_expire event is associated with the timer task event and it will be in the reset
state initially and it is set when the timer expires. Similarly, events ignition_on and ignition_off are
associated with the task ignition key status monitoring and the events seat_belt_on and seat_belt_off
are associated with the task seat belt status morning. The events ignition_off and ignition_on are set
and reset respectively when the ignition key status is OFF and reset and set respectively when the
ignition key status is ON, by the ignition key status monitoring task. Similarly the events seat_belt_off
and seat_belt_on are set and reset respectively when the seat belt status is OFF and reset and set
respectively when the seat belt status is ON, by the seat belt status monitoring task. The events
alarm_timer_start and alarm_timer_expire are associated with the alarm timer task. The
alarm_timer_start event will be in the reset state initially and it is set by the alarm control task when
the alarm is started. The alarm_timer_expire event will be in the reset state initially and it is set when
the alarm timer expires.

MIT Thandavapura
The alarm control task waits for the signaling of the event wait_timer_expire and starts the alarm timer
and alarm if both the events ignition_on and seat_belt_off are in the set state when the event
wait_timer_expire signals. If not the alarm control task simply completes its execution and returns. In
case the alarm is started, the alarm control task waits for the signalling of any one of the events
alarm_timer_expire or ignition_off or seat_belt_on. Upon signalling any one of these events, the alarm
is stopped and the alarm control task simply completes its execution and returns. Figure 7.8 illustrates
the same.
It should be noted that the method explained here is just one way of implementing a concurrent
model for the ‘Seat Belt Warning’ system. The intention is just to make the readers familiar with the
concept of multi tasking and task communication/synchronisation. There may be other ways to model
the same requirements. It is left to the readers as exercise. The concurrent processing model is
commonly used for the modelling of ‘Real Time’ systems. Various techniques like ‘Shared memory’,
‘Message Passing’, ‘Events’, etc. are used for communication and synchronising between concurrently
executing processes. We will discuss these techniques in a later chapter.

7.2.6 Object-Oriented Model

The object-oriented model is an object based model for modelling system requirements. It
disseminates a complex software requirement into simple well defined pieces called objects. Object-
oriented model brings re-usability, maintainability and productivity in system design. In the object-
oriented modelling, object is an entity used for representing or modelling a particular piece of the
system. Each object is characterised by a set of unique behaviour and state. A class is an abstract
description of a set of objects and it can be considered as a ‘blueprint’ of an object. A class represents
the state of an object through member variables and object behaviour through member functions. The
member variables and member functions of a class can be private, public or protected. Private member
variables and functions are accessible only within the class, whereas public variables and functions are
accessible within the class as well as outside the class. The protected variables and functions are
protected from external access. However classes derived from a parent class can also access the
protected member functions and variables. The concept of object and class brings abstraction, hiding
and protection.

MIT Thandavapura
 Embedded Hardware Design and Development
8.1 Analog Electronic Components
Resistors, capacitors, diodes, inductors, operational amplifiers (OpAmps), transistors, etc. are the
commonly used analog electronic components in embedded hardware design.
Resistors:
 A resistor limits the current flowing through a circuit. Interfacing of LEDs, buzzer, etc. with
the port pins of microcontroller through current limiting resistors is a typical example for the
usage of resistors in embedded application.

Capacitors and inductors:

 Capacitors and inductors are used in signal filtering and resonating circuits. Reset circuit
implementation, matching circuits for RF designs, power supply decoupling, etc. are examples
for the usage of capacitors in embedded hardware circuit. Electrolytic capacitors, ceramic
capacitors, tantalum capacitors, etc. are the commonly used capacitors in embedded hardware
design. Inductors are widely used for filtering the power supply from ripples and noise signals.
Inductors with inductance value in the microhenry (μH) range are commonly used in embedded
applications for filter and matching circuit implementation.

Diode:
 P-N Junction diode, Schottky diode, Zener diode, etc. are the commonly used diodes in
embedded hardware circuits. A schottky diode is same as a P-N junction diode except that its
forward voltage drop (voltage drop across diode when conducting) is very low (of the order of
0.15V to 0.45) when compare dto ordinary P-N junction diode (of the order of 0.7V to 1.7V).
Also the current switching time of schottky diode is very small compared to the ordinary P-N
junction diode. A zener diode acts as normal P-N junction diode when forward biased. It also
permits current flow in the reverse direction, if the voltage is greater than the junction
breakdown voltage. It is normally used for voltage clamping applications. Reverse polarity

MIT Thandavapura
 protection, voltage rectification (AC-DC converters), freewheeling of current produced in
inductive circuits, clamping of voltages to a desired level (e.g., Brown-out protection circuit
implementation using Zener diode), etc. are examples for the usage of diodes in embedded
applications.

Transistors
 Transistors in embedded applications are used for either switching or amplification purpose. In
switching application, the transistor is in either ON or OFF state. In amplification operation,
the transistor is always in the ON state (partially ON). The current is below saturation current
value and the current through the transistor is variable. The common emitter configuration of
NPN transistor is widely used in switching and driving circuits in embedded applications.
Relay, buzzer and stepper motor driving circuits are examples for common emitter
configuration based driver circuit implementation using transistor.

8.2 Digital Electronic Components

Digital electronics deal with digital or discrete signals. Microprocessors, Microcontrollers, and
System on Chips (SoCs) work on digital principles. They interact with the rest of the world through
digital I/O interfaces and process digital data. Embedded systems employ various digital electronic
circuits for ‘Glue logic’ implementation. ‘Glue logic’ is the custom digital electronic circuitry
required to achieve compatible interface between two different integrated circuit chips. Address
decoders, latches, encoders/decoders, etc. are examples for glue logic circuits. Transistor
Transistor Logic (TTL), Complementary Metal Oxide Semiconductor (CMOS) logic etc are some
of the standards describing the electrical characteristics of digital signals in a digital system.

8.2.1 Open Collector and Tri-State Output

Open collector is an I/O interface standard in digital system design. The term ‘open collector’
is commonly used in conjunction with the output of an Integrated Circuit (IC) chip. It facilitates the
interfacing of IC output to other systems which operate at different voltage levels. In the open collector
configuration, the output line from an IC circuit is connected to the base of an NPN transistor. The
collector of the transistor is left unconnected (floating) and the emitter is internally connected to the
ground signal of IC. Figure 8.1 illustrates an open collector output configuration.

For the output pin to function properly, the output pin should be pulled, to the desired voltage for the
o/p device, through a pull-up resistor. The output signal of the IC is fed to the base of an open collector
transistor. When the base drive to the transistor is ON and the collector is in open state, the o/p pin
floats. This state is also known as ‘high impedance’ state. Here the output is neither driven to logic

MIT Thandavapura
‘high’ nor logic ‘low’. If a pull-up resistor is connected to the o/p pin, when the base drive is ON, the
o/p pin becomes at logic 0 (0V). With a pull-up resistor, if the base driver is 0, the o/p will be at logic
high (Voltage = Vcc). The advantage of open collector output in embedded system design is listed
below.
(1) It facilitates the interfacing of devices, operating at a voltage different from the IC, with the IC.
Thereby, it eliminates the need for additional interface circuits for connecting devices at different
voltage levels.
(2) An open collector configuration supports multi-drop connection, i.e., connecting more than one
open collector output to a single line. It is a common requirement in modern embedded systems
supporting communication interfaces like I2C, 1-Wire, etc. Please refer to the various interfaces
described in Chapter 2 under the section ‘Onboard Communication Interfaces’.
(3) It is easy to build ‘Wired AND’ and ‘Wired OR’ configuration using open collector output lines.
The output of a standard logic device has two states, namely ‘Logic 0 (LOW)’ and ‘Logic 1 (HIGH),
and the output will be at any one of these states at a given point of time, whereas tri-state devices have
three states for the output, namely, ‘Logic 0 (LOW)’, ‘Logic 1 (HIGH) and ‘High Impedance
(FLOAT)’. A tristate logic device contains a device activation line called ‘Device Enable’. When the
‘Device Enable’ line is activated (set at ‘Logic 1’ for an active ‘HIGH’ enable input and at ‘Logic 0’
for an active ‘LOW’ enable input), the device acts like a normal logic device and the output will be in
any one of the logic conditions, ‘Logic 0 (LOW)’ or ‘Logic 1 (HIGH)’. When the ‘Device Enable’ line
is de-activated (set at ‘Logic 0’ for an active ‘HIGH’ enable input and at ‘Logic 1’ for an active ‘LOW’
enable input), the output of the logic device enters in a high impedance state and the device is said to
be in the floating state. The tri-stated output condition produces the effect of ‘removing’ the device
from a circuit and allows more than one devices to share a common bus. With multiple ‘tri-stated’
devices share a common bus, only one ‘device’ is allowed to drive the bus (drive the bus to either
‘Logic 0’ or ‘Logic 1’) at any given point of time and rest of the devices should be in the ‘tri-stated’
condition.

8.2.2 Logic Gates:

Logic gates are the building blocks of digital circuits. Logic gates control the flow of digital
information by performing a logical operation of the input signals. Depending on the logical operation,
the logic gates used in digital design are classified into–AND, OR, XOR, NOT, NAND, NOR and
XNOR. The logical relationship between the output signal and the input signals for a logic gate is
represented using a truth table. Figure 8.2 illustrates the truth table and symbolic representation of each
logic gate.

8.2.3 Buffer
A buffer circuit is a logic circuit for amplifying the current or power. It increases the driving
capability of a logic circuit. A tri-state buffer is a buffer with Output Enable control. When the Output
Enable control is active (Low for Active low enable and High for Active high enable), the tri-state
buffer functions as a buffer. If the Output Enable is not active, the output of the buffer remains at high
impedance state (Tri-stated). Tristate buffers are commonly used as drivers for address bus and to
select the required device among multiple devices connected to a shared data bus. Tri-state buffers are
available as either unidirectional or bi-directional buffers. 74LS244/74HC244 is an example of
unidirectional octal buffer. It contains 8 individual buffers which are grouped into two. Each buffer
group has its own output enable line. Figure 8.3 illustrates the 74LS244 buffer device.

IC 74LS245 is an example of bi-directional tri-state buffer. It allows data flow in both directions, one
at a time. The data flow direction can be set by the direction control line. One buffer is allocated for

MIT Thandavapura
the data line associated with each direction. Figure 8.4 illustrates the 74LS245 octal bi-directional
buffer.

8.2.4 Latch:
A latch is used for storing binary data. It contains an input data line, clock or gating control
line for triggering the latching operation and an output line. The gating signal can be either a positive
edge (raising edge) or a negative edge (falling edge). Whenever a latch trigger happens, the data present
on the input line is latched. The latched data is available on the output line of the latch until the next
trigger. D flip flop is a typical example of a latch (refer to your Digital Electronics course material—
there exist different types of latches namely S-R, J-K, D, T, etc.). In electronic circuits, latches are
commonly used for latching data, which is available only for a short duration. A typical example is the
lower order address information in a multiplexed address-data bus system. Latches are available as
integrated circuits, IC 74LS373 being a typical example. It contains 8 individual D latches.
The 74LS373 latch IC (Fig. 8.5) is commonly used for latching the lower order address byte in a
multiplexed address data bus system. The Address Latch Enable (ALE) pulse generated by the
processor, when the Address bits are available on the multiplexed bus, is used as the latch trigger.
Figure 8.6 illustrates the usage of latches in address latching.

MIT Thandavapura
8.2.5 Decoder
A decoder is a logic circuit which generates all the possible combinations of the input signals.
Decoders are named with their input line numbers and the possible combinations of the input as output.
Examples are 2 to 4 decoder, 3 to 8 decoder and 4 to 16 decoder. The 3 to 8 decoder contains 3 input
signal lines and it is possible to have 8 different configurations with the 3 lines (000 to 111 in the input
line corresponds to 0 to 7 in the output line). Depending on the input signal, the corresponding output
line is asserted. For example, for the input state 001, the output line 2 is asserted. Decoders are mainly
used for address decoding and chip select signal generation in electronic circuits and are available as
integrated circuits. 74LS138/74AHC138 is an example for 3 to 8 decoder IC. Figure 8.7 illustrates the
74AHC138 decoder and the function table for it.
The decoder output is enabled only when the ‘Output Enable’ signal lines E1\, E2\ and E3 are at logic
levels 0, 0 and 1 respectively. If the output-enable signals are not at the required logic state, all the
output lines are forced to the inactive (High) state. The output line corresponding to the input state is
asserted ‘Low’ when the ‘Output Enable’ signal lines are at the required logic state (Here E1\=E2\=0

MIT Thandavapura
and E3 =1). The output line can be directly connected to the chip select pin of a device, if the chip
select logic of the device is active low.

8.2.6 Encoder
An encoder performs the reverse operation of decoder. The encoder encodes the corresponding
input state to a particular output format. The binary encoder encodes the input to the corresponding
binary format. Encoders are named with their input line numbers and the encoder output format.
Examples are 4 to 2 encoder, 8 to 3 encoder and 16 to 4 encoder. The 8 to 3 encoder contains 8 input
signal lines and it is possible to generate a 3 bit binary output corresponding to the input (e.g. inputs 0
to 7 are encoded to binary 111 to 000 in the output lines). The corresponding output line is asserted in
accordance with the input signals. For example, if the input line 1 is asserted, the output lines A0, A1
and A2 are asserted as 0, 1 and 1 respectively. Encoders are mainly used for address decoding and chip
select signal generation in electronic circuits and are available as integrated circuits. 74F148/74LS148
is an example of 8 to 3 encoder IC. Figure 8.8 illustrates the 74F148/74LS148 encoder and the function
table for it. The encoder output is enabled only when the ‘Enable Input (EI)’ signal line is at logic 0.
A ‘High’ on the Enable Input (EI) forces all outputs to the inactive (High) state and allows new data
to settle without producing erroneous information at the outputs. The group signal (GS) is active-Low
when any input is Low: this indicates when any input is active. The Enable Output (EO) is active-Low
when all inputs are at logic ‘High’. 74LS148/74F148 is a priority encoder and it provides priority
encoding of the inputs to ensure that only the highest order data line is encoded when multiple data
lines are asserted (e.g., when both input lines 1 and 6 are asserted, only 6 is encoded and the output
will be 001. It should be noted that the encoded output is an inverted value of the corresponding binary
data. (e.g., the output lines A2, A1 and A0 will be at logic levels 000 when the input 7 is asserted).
Encoding of keypress in a keyboard is a typical example for an application requiring encoder. The
encoder converts each keypress to a binary code.

MIT Thandavapura
8.2.7 Multiplexer (MUX)
A multiplexer (MUX) can be considered as a digital switch which connects one input line from
a set of input lines, to an output line at a given point of time. It contains multiple input lines and a
single output line. The inputs of a MUX are said to be multiplexed. It is possible to connect one input
with the output line at a time. The input line is selected through the MUX control lines. 74S151 is an
example for 8 to 1 multiplexer IC. Figure 8.9 illustrates the 74S151 multiplexer and the function table
for it.

The multiplexer is enabled only when the ‘Enable signal (EN)’ line is at logic 0. A ‘High’ on the EN
line forces the output to the inactive (Low) state. The input signal is switched to the output line through
the channel select control lines A2, A1 and A0. In order to select a particular input line, apply its binary
equivalent to the channel select lines A0, A1 and A2 (e.g. set A2A1A0 as 000 for selecting Input D0,
and as 001 for selecting channel D1, etc.).

8.2.8 De-multiplexer (D-MUX)

A de-multiplexer performs the reverse operation of multiplexer. De-multiplexer switches the
input signal to the selected output line among a number of output lines. The output line to which the
input is to be switched is selected by the output selector control lines. The 1 to 2 de-multiplexer,
NL7SZ18 is a typical example for 1 to 2 de-multiplexer IC. It contains a single input line and two
output lines to switch the input line. The output switching is controlled by the output selector control.
Figure 8.10 illustrates the NL7SZ18 de-multiplexer and the function table for it. When one output line
is selected by the output selector control (S), the other output line remains in the High impedance state.

MIT Thandavapura
8.2.9 Combinational Circuits
 In digital system design, a combinational circuit is a combination of the logic gates. The output
of the combinational circuit, at a given point of time, is dependent only on the state of the inputs
at the given point of time. Encoders, decoders, multiplexers, de-multiplexers, adder circuits,
comparators, multiple input gates, etc. are examples of digital combinational circuits. The
design requirements for a combinational circuit are expressed as ‘A set of statements’ or ‘Truth
Table’ or ‘Boolean Expressions’.
 The combinational circuit can be implemented either by simplifying the Boolean
expression/Truth table and realising the simplified expression using logic gates or by directly
implementing the logic expressions using an ‘Off-the-shelf’ Medium Scale Integrated Circuit
Chip.
 Various logic simplify cation techniques like ‘Karnaugh Map (K Map)’, ‘Algebraic method’,
‘Variable Entered Mapping (VEP)’ and ‘Quine-McCluskey method,’ etc. are used for the
Simplification of logic expressions. In digital system design, logical functions representing a
combinational circuit are expressed as either ‘Sum of Products (SOP)’ or ‘Product of Sums
(POS)’ form. The SOP form represents the logic as the sum of the products of the logical
variables whereas the POS form represents the logic as the product of sums of the logical
variable.
 The expression is an example for SOP form representation of the logical
function. Here Y is the output signal and A, B and C are the input signals.
 The expression Y = (A+B) (B+C) (A+C) is an example for POS form representation of the
logical function. Here Y is the output signal and A, B and C are the input signals.
 ‘Karnaugh map’ or K-map is the easiest logic simplification technique for arriving at the logic
expression when the ‘Truth Table’ of the combinational circuit is given. Depending on the
number of input signal variables, K-maps are named as 2-variable, 3-variable, 4-variable, etc.
K-map is the most suitable candidate for handling input variables up to 6. Now let us try to
implement a 2 input half adder combinational circuit, for adding two one-bit numbers, using
the K-map technique. The ‘Truth Table’ and the corresponding K-map drawing* for the 2 input
‘half adder’ circuit is given below.

MIT Thandavapura
Hence, the half adder circuit can be realised using an XOR and an AND gate. The circuit
implementation is shown in Fig. 8.13.

8.2.10 Sequential Circuits

 Digital logic circuit, whose output at any given point of time depends on both the present and
past inputs, is known as sequential circuits. Hence, sequential circuits contain a memory
element for holding the previous input states.
 In general, a sequential circuit can be visualised as a combinational circuit with memory
elements. Flip-flops act as the basic building blocks of sequential circuits. Sequential circuits
are of two types, namely–synchronous (clocked) sequential circuits and asynchronous
sequential circuits.
 The operation of a synchronous sequential circuit is synchronised to a clock signal, whereas an
asynchronous sequential circuit does not require a clock for operation. For an asynchronous
sequential circuit, the response depends upon the sequence in which the input signal changes.
The memory capability to asynchronous sequential circuit is provided through feedback.
Register, synchronous counters, etc. are examples of synchronous serial circuits, whereas ripple
or asynchronous counter is an example for asynchronous sequential circuits.
 Now let us have a look at how a fl0ip-flop circuit acts as a memory storage element. The name
flip-flop is conveying its intended purpose. It tumbles the output based on the input and other
controlling signals. As a starting point on the discussion of flip-flops, let us talk about Set Reset
(S-R) flip-flop. The logic circuit and the I/O states for an S-R flip-flop are given in Fig. 8.15.

MIT Thandavapura
The S-R flip-flop is built using 2 NOR gates. The output of each NOR gate is fed back as input to the
other NOR gate. This ensures that if the output of one NOR gate is at logic 1, the output of the other
NOR gate will be at logic 0. The S-R flip-flop works in the following way.
(1) If the Set input (S) is at logic high and Reset input (R) is at logic low, the output remains at logic
high regardless of the previous output state.
(2) If the Set input (S) is at logic low and Reset input (R) is at logic high, the output remains at logic
low regardless of the previous output state.
(3) If both the Set input (S) and Reset input (R) are at logic low, the output remains at the previous
logic state.
(4) The condition Set input (S) = Reset input (R) = Logic high (1) will lead to race condition and the
state of the circuit becomes undefined or indeterminate (x). A clock signal can be used for triggering
the state change of flip-flops.
The clock signal can be either level triggered or edge triggered. For level triggered flip-flops, the
output responds to any changes in input signal, if the clock signal is active (i.e., if the clock signal is
at logic 1 for ‘HIGH’ level triggered and at logic 0 for ‘LOW’ level triggered clock signal). For edge
triggered flip-flops, the output state changes only when a clock trigger happens regardless of the
changes in the input signal state. The clock trigger signal can be either a positive edge (A 0 to 1
transition) or a negative edge (A 1 to 0 transition). Figure 8.16 illustrates the implementation of an
edge triggered S-R flip-flop. The clocked S-R flip-flop functions in the same way as that of S-R flip-
flop. The only difference is that the output state changes only with a clock trigger. Even though there
is a change in the input state, the output remains unchanged until the next clock trigger. When a clock
trigger occurs, the output state changes in accordance with the values of S and R at the time of the
clock trigger. We have seen that the input condition S=R= 1 is undefined in an S-R flip-flop. The J-K
flip-flop augments the behaviour of S-R flip by interpreting the input state S=R=1 as a toggle
command. The logic circuit and the I/O states for a J-K flip-flop are given in Fig.

MIT Thandavapura
From the circuit implementation, it is clear that for a J-K fl ip-fl op, S = JQ\ and R = KQ. The J-K flip-
flop
operates in the following way:
(1) When J = 1 and K = 0, the output remains in the set state.
(2) When J = 0 and K = 1, the output remains in the reset state.
(3) When J = K = 0, the output remains at the previous logic state.
(4) When J = 1 and K = 1, the output toggles its state.
A D-type (Delay) flip-flop is formed by connecting a NOT gate in between the S and R inputs of an
S-R
flip-flop or by connecting a NOT gate between the J and K inputs of a J-K flip-flop. Figure 8.18
illustrates a
D-type flip-flop and its I/O states.

This flip-flop is known with the so-called name ‘Delay’ flip-flop for the following reason–the input to
the Flip-flop appears at the output at the end of the clock pulse (for falling edge triggering).
A Toggle flip-flop or T flip-flop is formed by combining the J and K inputs of a J-K flip-flop. Figure
8.19 illustrates a T flip-flop and its I/O states.

MIT Thandavapura
When the ‘T’ input is held at logic 1, the T flip-flop toggles the output with each clock signal. An S-R
flip-flop cannot be converted to a ‘T’ flip flop by combining the inputs S and R. The logic state S=R=1
is not defined in the S-R flip-flop. However, an S-R flip-flop can be configured for toggling the output
with the circuit configuration shown in Fig. 8.20.

The synchronous sequential circuit uses clocked flip-flops (S-R, J-K, D, T etc.) as memory elements
and a ‘state’ change occurs only in response to a synchronising clock signal. The clock signal is
common to all flip-flops and the clock pulse is applied simultaneously to all flip-flops. As an
illustrative example for synchronous sequential circuit, let us consider the design of a synchronous 3-
bit binary counter. The counting sequence for a 3-bit binary counter is given below.

From the count sequence, it is clear that the LS bit (Q0) of the binary counter toggles on each count
and the next LS bit (Q1) toggles only when the LS bit (Q0) makes a transition from 1 to 0. The Bit
(Q2) of the binary counter toggles its state only when the Q1 bit and Q0 bits are at logic 1. This logic
circuit can be realised with 3 T flip-flops satisfying the following criteria:
(1) All the T flip-flops are driven simultaneously by a single clock (synchronous design).

MIT Thandavapura
(2) The output of the T flip-flop representing the Q0 bit is initially set at 0. The input line of Q0 flip-
flop is connected to logic 1 to ensure toggling of the output with input clock signal.
(3) Since Q1 bit changes only when Q0 makes a transition from 1 to 0, the output of the T flip-flop
representing Q0 is fed as input to the T flip-flop representing the Q1 bit.
(4) The output bit Q2 changes only when Q0 = Q1 = 1. Hence the input to the flip-flop representing
bit Q2 is fed by logically ANDing Q0 and Q1.
The circuit realisation of 3-bit binary counter using 3 T flip-flops is given in Fig. 8.21.

The Preset line is used for setting the output of flip-flop, whereas the Clear line is used for resetting
the output of flip-flops. The counter changes in accordance with the count pulses.
Another example for synchronous sequential circuit is ‘register’. A register can be considered as a
group of bits holding information. A D flip-flop can be used for holding a ‘bit’ information. An 8 bit

MIT Thandavapura
wide register can be visualised as the combination of 8 D flip-flops. The bit storing operation is
controlled by the signal associated with a latch write (like a write to latch pulse). The figure given
below illustrates the implementation the state of an asynchronous sequential circuit changes
instantaneously with changes in input signal state. The asynchronous sequential circuit does not require
a synchronising clock signal for its operation.
The memory element of an asynchronous sequential circuit can be either an un-clocked flip-flop or
logical gate circuits with feedback loops for latching the state. As an illustrative example, let us explore
how we can implement the above 3-bit binary counter using an asynchronous sequential circuit. From
the count sequence of the 3-bit binary counter, it is clear that the least significant (LS) bit (Q0) of the
binary counter toggles on each count and the next LS bit (Q1) toggles only when the LS bit (Q0) makes
a transition from 1 to 0. The most significant (MS) Bit (Q2) of the binary counter toggles its state only
when the Q1 bit makes a transition from 1 to 0. This logic circuit can be realised with 3 T flip-flops
satisfying the following criteria:
(1) The T input of all flip-flops are connected to logic high (it is essential for the toggling condition of
the
T Flip-flop).
(2) The pulse for counting is applied to the clock input of the first T flip-flop representing the LS bit
Q0.
(3) The clock to the T flip-flop representing bit Q1 is supplied by the output of the T flip-flop
representing bit Q0. This ensures that the output of Q1 toggles only when the output of Q0 transitions
from 1 to 0.
(4) The clock to the T flip-flop representing bit Q2 is supplied by the output of the T flip-flop
representing bit Q1. This ensures that the output of Q2 toggles only when the output of Q1 transitions
from 1 to 0.
The circuit realisation of the 3-bit binary counter using 3 T flip-flops in an asynchronous sequential
circuit is given below.

The Preset line is used for setting the output of flip-flop, whereas the Clear line is used for resetting
the output of flip-flops. Here the input line (T) of all flip-flops is tied to logic 1 permanently. Hence,
the clock signal to each flip-flop can be treated as the input to the flip-flop, instead of treating it as a
clock pulse. The table given below summarises the characteristics, pros and cons of synchronous and
asynchronous sequential circuits.

MIT Thandavapura
8.3 VLSI AND INTEGRATED CIRCUIT DESIGN
1. An Integrated Circuit (IC) is a miniaturised form of an electronic circuit containing transistors
and other passive electronic components. In an IC, the circuits, required for building the
functionality (say Processing logic: CPU), are built on the surface of a thin silicon wafer. The
first integrated circuit was designed in the 1950s.
2. Depending on the number of integrated components, the degree of integration within an
integrated circuit (IC) is known as:
3. Small-Scale Integration (SSI): Integrates one or two logic gate(s) per IC, e.g. LS7400
4. Medium-Scale Integration (MSI): Integrates up to 100 logic gates in an IC. The decade
Counter 7490 is an example for MSI device
5. Large-Scale Integration (LSI): Integrates more than 1000 logic gates in an IC
6. Very Large-Scale Integration (VLSI): Integrates millions of logic gates in an IC. Pentium
processor is an example of a VLSI Device. The IC design methodology has evolved over the
years from the first generation design, SSI to designs with millions of logic gates. The gate
count is a measure of the complexity of the IC. In today’s world almost all IC designs fall under
the category VLSI and it is a common practice to term IC design as VLSI design. Depending
on the type of circuits integrated in the IC,
the IC design is categorized as:
 Digital Design: Deals with the design of integrated circuits handling digital signals and data.
The I/O requirement for such an IC is always digital. Microprocessor/microcontroller,
memory, etc. are examples of digital design.
 Analog Design Deals with the design of integrated circuits handling analog signals and data.
Analog design gives more emphasis to the physics aspects of semiconductor devices such as
gain, power dissipation, resistance, etc. RF IC design, Op-Amp design, voltage regulator IC
design, etc. are examples for Analog IC Design.
 Mixed Signal Design: In today’s world, most of the applications require the co-existence of
digital signals and analog signals for functioning. Mixed signal design involves design of ICs,
which handle both digital and analog signals as well as data. Design of an analog-to-digital
converter is an example for mixed signal IC design. Integrated circuit design or VLSI design
involves a number of steps namely, system specification, functional or architectural design,
functional simulation, logic synthesis, physical layout (placement and routing) and timing
simulation. As in the case of any other system design, VLSI design also starts with the system
specification in which the requirements of the chip under development are listed out. The

MIT Thandavapura
 functional design or architectural design involves identifying the various functional modules
in the design and their interconnections. It represents an abstraction of the chip under
development. Computer aided design (CAD) tools are available for architectural design. The
functional aspects of a chip can be captured using CAD tools with various methods like block
diagrams, truth tables, fl ow charts, state diagrams, schematic diagrams and Hardware
Description Language (HDL). This process of entering the system description into the CAD
tool is known as Design Entry. The truth table based design entry uses the truth table of a logic
function. This method is suitable for the realisation of logic function implementation involving
lesser number of logic variables.

VHDL for VLSI Design

• Very High Speed Integrated Circuit HDL or VHDL is a hardware description language used in
VLSI design.
• VHDL is a technology independent description, which enables creation of designs targeted for
a chosen technology (like CPLD, FPGA, etc.) using synthesis tools.
• This enables one keep up with the fast development of semiconductor technology.
• VHDL can be used for describing the functionality and behaviour of the system (Behavioural
representation), or describing the actual gate and register levels of the system [ Register
Transfer Level ( RTL) representation].
• VHDL supports concurrent, sequential, hierarchical and timing modelling.
• The concurrent modelling describes the activities happening in parallel, whereas sequential
modelling describes the activities in a serial fashion one after another.
• Hierarchical model describes the structural aspects, and timing model models the timing
requirements of the design.
• The basic structure of a VHDL design consists of an entity, architecture and signals. The entity
declaration defines the name of the function being modelled and its interface ports to the
outside world, their direction and type. The basic syntax for an entity declaration is given
below.

 The architecture describes the internal structure and behaviour of the model. Architecture can
define a circuit structure using individually connected modules or model its behaviour using
suitable statements. The basic syntax of architecture body is given below

MIT Thandavapura
Figure 8.25 illustrates the various steps involved in a HDL based design.

8.4 ELECTRONIC DESIGN AUTOMATION (EDA) TOOLS

 Early embedded products were built around the old transistor and vacuum tube technologies,
where the designers built the PCB with their hands, oil paper, pencil, pen, ruler and copper
plates.
 The process of building a PCB was a tedious and time consuming process in ancient times
where the designers sketch the required connections using pen, pencil and ruler on papers and
the finished sketch was used for etching the connections on a copper plate and it took weeks
and months’ time to finish a PCB.
 The more the inter connections involved in the hardware, the more difficult was the process.
The accuracy and finishing of the PCB was highly dependent on the artistic skills of the
designer. Today the scenario is totally changed.
 Advances in computer technology and IT brought out highly sophisticated and automated tools
for PCB design and fabrication. The process of manual sketching the PCB has given way to
software packages that gives an automatic routing and layout for your product in a few seconds.
These software packages are widely known as Electronic Design Automation ( EDA) tools and
various manufactures offer these tools for different operating systems (Windows, UNIX, Linux
etc).
 EDA tool is a set of Computer Aided Design/Manufacturing (CAD/CAM) software packages
which helps in designing and manufacturing the electronic hardware like integrated circuits,
printed circuit board, etc. The key players of the EDA tool industry are Cadence, Protel, Altium,

MIT Thandavapura
 Cadsoft, Zuken, Mentor, etc. OrCAD, Cadstar, Protel, Eagle, etc. are the popular EDA tool
packages available in the market for PCB design. Of these, I feel Cadence OrCAD as the most
flexible and user friendly tool.

MIT Thandavapura
 MODULE 4
Embedded Firmware Design and Development

9.1 EMBEDDED FIRMWARE DESIGN APPROACHES

The firmware design approaches for embedded product is purely dependent on the complexity
of the functions to be performed, the speed of operation required, etc. Two basic approaches are used
for Embedded firmware design. They are ‘Conventional Procedural Based Firmware Design’ and
‘Embedded Operating System (OS) Based Design’. The conventional procedural based design is also
known as ‘Super Loop Model’. We will discuss each of them in detail in the following sections.

9.1.1 The Super Loop Based Approach

The Super Loop based firmware development approach is adopted for applications that are not time
critical and where the response time is not so important (embedded systems where missing deadlines
are acceptable). It is very similar to a conventional procedural programming where the code is executed
task by task. The task listed at the top of the program code is executed first and the tasks just below
the top are executed after completing the first task. This is a true procedural one. In a multiple task
based system, each task is executed in serial in this approach. The firmware execution fl ow for this
will be
1. Configure the common parameters and perform initialisation for various hardware components
memory,
registers, etc.
2. Start the first task and execute it
3. Execute the second task
4. Execute the next task
5. :
6. :
7. Execute the last defined task
8. Jump back to the first task and follow the same flow
From the firmware execution sequence, it is obvious that the order in which the tasks to be executed
are fixed and they are hard coded in the code itself. Also the operation is an infinite loop based
approach. We can visualise the operational sequence listed above in terms of a ‘C’ program code as

Almost all tasks in embedded applications are non-ending and are repeated infinitely throughout the
operation. From the above ‘C’ code you can see that the tasks 1 to n are performed one after another
and when the last task (nth task) is executed, the firmware execution is again re-directed to Task 1 and

MIT Thandavapura
it is repeated forever in the loop. This repetition is achieved by using an infinite loop. Here the while
(1) { } loop. This approach is also referred as ‘Super loop based Approach’.
 Since the tasks are running inside an infinite loop, the only way to come out of the loop is either
a hardware reset or an interrupt assertion.
 A hardware reset brings the program execution back to the main loop. Whereas an interrupt
request suspends the task execution temporarily and performs the corresponding interrupt
routine and on completion of the interrupt routine it restarts the task execution from the point
where it got interrupted.
 The ‘Super loop based design’ doesn’t require an operating system, since there is no need for
scheduling which task is to be executed and assigning priority to each task. In a super loop
based design, the priorities are fixed and the order in which the tasks to be executed are also
fixed. Hence the code for performing these tasks will be residing in the code memory without
an operating system image.
 This type of design is deployed in low-cost embedded products and products where response
time is not time critical. Some embedded products demands this type of approach if some tasks
itself are sequential. For example, reading/writing data to and from a card using a card reader
requires a sequence of operations like checking the presence of card, authenticating the
operation, reading/writing, etc.
 A typical example of a ‘Super loop based’ product is an electronic video game toy containing
keypad and display unit. The program running inside the product may be designed in such a
way that it reads the keys to detect whether the user has given any input and if any key press is
detected the graphic display is updated. The keyboard scanning and display updating happens
at a reasonably high rate. Even if the application misses a key press, it won’t create any critical
issues; rather it will be treated as a bug in the firmware.
 It is not economical to embed an OS into low cost products and it is an utter waste to do so if
the response requirements are not crucial.
 The ‘Super loop based design’ is simple and straight forward without any OS related overheads.
 The major drawback of this approach is that any failure in any part of a single task may affect
the total system.
 If the program hangs up at some point while executing a task, it may remain there forever and
ultimately the product stops functioning. There are remedial measures for overcoming this.
 Use of Hardware and software Watch Dog Timers (WDTs) helps in coming out from the loop
when an unexpected failure occurs or when the processor hangs up. This, in turn, may cause
additional hardware cost and firmware overheads.
 Another major drawback of the ‘Super loop’ design approach is the lack of real timeliness. If
the number of tasks to be executed within an application increases, the time at which each task
is repeated also increases. This brings the probability of missing out some events.
 For example in a system with Keypads, according to the ‘Super loop design’, there will be a
task for monitoring the keypad connected I/O lines and this need not be the task running while
you press the keys (That is key pressing event may not be in sync with the keypad press
monitoring task within the firmware). In order to identify the key press, you may have to press
the keys for a sufficiently long time till the keypad status monitoring task is executed internally
by the firmware. This will really lead to the lack of real timeliness.

9.1.2 The Embedded Operating System (OS) Based Approach

 The Operating System (OS) based approach contains operating systems, which can be either a
General Purpose Operating System (GPOS) or a Real Time Operating System (RTOS) to host
the user written application firmware.

MIT Thandavapura
  The General Purpose OS (GPOS) based design is very similar to a conventional PC based
application development where the device contains an operating system (Windows/Unix/
Linux, etc. for Desktop PCs) and you will be creating and running user applications on top of
it. Example of a GPOS used in embedded product development is Microsoft® Windows
Embedded 8.1 which offers customisation to use with a range of industry devices like
Handhelds, Point of Sale Terminals, Patient Monitoring Systems, etc.
 Use of GPOS in embedded products merges the demarcation of Embedded Systems and general
computing systems in terms of OS. For Developing applications on top of the OS, the OS
supported APIs are used. Similar to the different hardware specific drivers, OS based
applications also require ‘Driver software’ for different hardware present on the board to
communicate with them. Real Time Operating System (RTOS) based design approach is
employed in embedded products demanding Real-time response. RTOS respond in a timely
and predictable manner to events.
 Real Time operating system contains a Real Time kernel responsible for performing pre-
emptive multitasking, scheduler for scheduling tasks, multiple threads, etc. A Real Time
Operating System (RTOS) allows flexible scheduling of system resources like the CPU and
memory and offers some way to communicate between tasks. We will discuss the basics of
RTOS based system design in a later chapter titled ‘Designing with Real Time Operating
Systems (RTOS)’. ‘Windows Embedded Compact’, ‘pSOS’, ‘VxWorks’, ‘ThreadX’,
‘MicroC/OS-III’, ‘Embedded Linux’, ‘Symbian’ etc are examples of RTOS employed in
embedded product development.

9.2 EMBEDDED FIRMWARE DEVELOPMENT LANGUAGES

As mentioned in Chapter 2, you can use either a target processor/controller specific language
(Generally known as Assembly language or low level language) or a target processor/controller
independent language (Like C, C++, JAVA, etc. commonly known as High Level Language) or a
combination of Assembly and High level Language. We will discuss where each of the approach is
used and the relative merits and de-merits of each, in the following sections.

9.2.1 Assembly Language based Development

 ‘ Assembly language’ is the human readable notation of ‘ machine language’, whereas
‘machine language’ is a processor understandable language.
 Processors deal only with binaries (1s and 0s). Machine language is a binary representation
and it consists of 1s and 0s. Machine language is made readable by using specific symbols
called ‘ mnemonics’.
 Hence machine language can be considered as an interface between processor and programmer.
Assembly language and machine languages are processor/controller dependent and an
assembly program written for one processor/controller family will not work with others.
Assembly language programming is the task of writing processor specific machine code in
mnemonic form, converting the mnemonics into actual processor instructions (machine
language) and associated data using an assembler.
 Assembly Language program was the most common type of programming adopted in the
beginning of software revolution. If we look back to the history of programming, we can see
that a large number of programs were written entirely in assembly language.
 Even in the 1990s, the majority of console video games were written in assembly language,
including most popular games written for the Sega Genesis and the Super Nintendo
Entertainment System. The popular arcade game NBA Jam released in 1993 was also coded
entirely using the assembly language. Even today also almost all low level, system related,

MIT Thandavapura
 programming is carried out using assembly language. Some Operating System dependent tasks
require low-level languages. In particular, assembly language is often used in writing the low
level interaction between the operating system and the hardware, for instance in device drivers.
 The general format of an assembly language instruction is an Opcode followed by Operands.
The Opcode tells the processor/controller what to do and the Operands provide the data and
information required to perform the action specified by the opcode. It is not necessary that all
opcode should have Operands following them. Some of the Opcode implicitly contains the
operand and in such situation no operand is required. The operand may be a single operand,
dual operand or more. We will analyse each of them with the 8051 ASM instructions as an
example.

This instruction mnemonic moves decimal value 30 to the 8051 Accumulator register. Here MOV A
is the Opcode and 30 is the operand (single operand). The same instruction when written in machine
language will look like
01110100 00011110
where the first 8 bit binary value 01110100 represents the opcode MOV A and the second 8 bit binary
value
00011110 represents the operand 30.
Assembly language instructions are written one per line. A machine code program thus consists of a
Sequence of assembly language instructions, where each statement contains a mnemonic (Opcode +
Operand).
Each line of an assembly language program is split into four fields as given below
LABEL OPCODE OPERAND COMMENTS

LABEL is an optional field. A ‘LABEL’ is an identifier used extensively in programs to reduce the
reliance on programmers for remembering where data or code is located. LABEL is commonly used
for representing a memory location, address of a program, sub-routine, code portion, etc.
The maximum length of a label differs between assemblers. Assemblers insist strict formats for
labelling. Labels are always suffixed by a colon and begin with a valid character. Labels can contain
number from 0 to 9 and special character _ (underscore).
Labels are used for representing subroutine names and jump locations in Assembly language
programming. It is to be noted that ‘LABEL’ is not a mandatory field; it is optional only.
The statement ORG 0100H in the above example is not an assembly language instruction; it is an
assembler directive instruction. It tells the assembler that the Instructions from here onward should be
placed at location starting from 0100H. The Assembler directive instructions are known as ‘pseudo-
ops’. They are used for
1. Determining the start address of the program (e.g. ORG 0000H)
2. Determining the entry address of the program (e.g. ORG 0100H)
3. Reserving memory for data variables, arrays and structures (e.g. var EQU 70H
4. Initialising variable values (e.g. val DATA 12H)
The EQU directive is used for allocating memory to a variable and DATA directive is used for
initialising a variable with data. No machine codes are generated for the ‘pseudo-ops’.
Till now we discussed about Assembly language and how it is used for writing programs. Now let us
have a look at how assembly programs are organised and how they are translated into machine readable
codes.

MIT Thandavapura
9.2.1.1 Source File to Object File Translation
 Translation of assembly code to machine code is performed by assembler. The assemblers for
different target machines are different and it is common that assemblers from multiple vendors
are available in the market for the same target machines.
 Some target processor’s/controller’s assembler may be proprietary and is supplied by a single
vendor only. Some assemblers are freely available in the internet for downloading. Some
assemblers are commercial and requires licence from the vendor. A51 Macro Assembler from
Keil software is a popular assembler for the 8051 family microcontroller. The various steps
involved in the conversion of a program written in assembly language to corresponding binary
fi le/machine language is illustrated in Fig. 9.1.

 Each source module is written in Assembly and is stored as .src file or .asm fi le. Each fi le can
be assembled separately to examine the syntax errors and incorrect assembly instructions. On
successful assembling of each .src/.asm fi le a corresponding object fi le is created with
extension ‘.obj’.
 The object fi le does not contain the absolute address of where the generated code needs to be
placed on the program memory and hence it is called a re-locatable segment. It can be placed
at any code memory location and it is the responsibility of the linker/locator to assign absolute
address for this module. Absolute address allocation is done at the absolute object fi le creation
stage. Each module can share variables and subroutines (functions) among them. Exporting a
variable/function from a module (making a variable/function from a module available to all
other modules) is done by declaring that variable/function as PUBLIC in the source module.

9.2.1.2 Library File Creation and Usage

 Libraries are specially formatted, ordered program collections of object modules that may be
used by the linker at a later time.

MIT Thandavapura
  When the linker processes a library, only those object modules in the library that are necessary
to create the program are used. Library fi les are generated with extension ‘.lib’. Library fi le
is some kind of source code hiding technique.

9.2.1.3 Linker and Locator

 Linker and Locator is another software utility responsible for “linking the various object
modules in a multimodule project and assigning absolute address to each module”.
 Linker generates an absolute object module by extracting the object modules from the library,
if any and those obj files created by the assembler, which is generated by assembling the
individual modules of a project.
 It is the responsibility of the linker to link any external dependent variables or functions
declared on various modules and resolve the external dependencies among the modules.

9.2.1.4 Object to Hex File Converter

 This is the final stage in the conversion of Assembly language (mnemonics) to machine
understandable language (machine code).
 Hex File is the representation of the machine code and the hex file is dumped into the code
memory of the processor/controller. The hex fi le representation varies depending on the target
processor/controller make.

9.2.1.5 Advantages of Assembly Language Based Development

 Assembly Language based development was (is) the most common technique adopted from
the beginning of embedded technology development. Thorough understanding of the processor
architecture, memory organisation, register sets and mnemonics is very essential for Assembly
Language based development.
 You master one processor architecture and its assembly instructions, you can make the
processor as flexible as a gymnast. The major advantages of Assembly Language based
development is listed below. Efficient Code Memory and Data Memory Usage (Memory
Opmisa on) since the developer is well versed with the target processor architecture and
memory organisation, optimised code can be written for performing operations.
 This leads to less utilisation of code memory and efficient utilisation of data memory.
Remember memory is a primary concern in any embedded product (Though silicon is cheaper
and new memory techniques make memory less costly, external memory operations impact
directly on system performance).
 High Performance Optimised code not only improves the code memory usage but also
improves the total system performance. Through effective assembly coding, optimum
performance can be achieved for a target application.
 Low Level Hardware Access Most of the code for low level programming like accessing
external device specific registers from the operating system kernel, device drivers, and low
level interrupt routines, etc. are making use of direct assembly coding since low level device
specific operation support is not commonly available with most of the high-level language
cross compilers.
 Code Reverse Engineering Reverse engineering is the process of understanding the technology
behind a product by extracting the information from a finished product. Reverse engineering
is performed by ‘hackers’ to reveal the technology behind ‘Proprietary Products’.
 Though most of the products employ code memory protection, if it may be possible to break
the memory protection and read the code memory, it can easily be converted into assembly
code using a dis-assembler program for the target machine.

MIT Thandavapura
9.2.1.6 Drawbacks of Assembly Language Based Development
 High Development Time Assembly language is much harder to program than high level
languages.
 The developer must pay attention to more details and must have thorough knowledge of the
architecture, memory organisation and register details of the target processor in use.
 Learning the inner details of the processor and its assembly instructions is highly time
consuming and it creates a delay impact in product development. One probable solution for
this is use a readily available developer who is well versed in the target processor architecture
assembly instructions.
 Also more lines of assembly code are required for performing an action which can be done
with a single instruction in a high-level language like ‘C’.
 Developer Dependency There is no common written rule for developing assembly language
based applications whereas all high level languages instruct certain set of rules for application
development.
 In assembly language programming, the developers will have the freedom to choose the
different memory location and registers. Also the programming approach varies from
developer to developer depending on his/ her taste. For example moving data from a memory
location to accumulator can be achieved through different approaches.
 If the approach done by a developer is not documented properly at the development stage, he/
she may not be able to recollect why this approach is followed at a later stage or when a new
developer is instructed to analyse this code, he/she also may not be able to understand what is
done and why it is done.
 Hence upgrading an assembly program or modifying it on a later stage is very difficult. Well
documenting the assembly code is a solution for reducing the developer dependency in
assembly language programming.
 If the code is too large and complex, documenting all lines of code may not be productive.
Non-Portable Target applications written in assembly instructions are valid only for that
particular family of processors (e.g. Application written for Intel x86 family of processors) and
cannot be re-used for another target processors/controllers (Say ARM Cortex M family of
processors).
 If the target processor/controller changes, a complete re-writing of the application using the
assembly instructions for the new target processor/ controller is required. This is the major
drawback of assembly language programming and it makes the assembly language applications
non-portable.

9.2.2 High Level Language Based Development

 As we have seen in the earlier section, Assembly language based programming is highly time
consuming, tedious and requires skilled programmers with sound knowledge of the target
processor architecture.
 Also applications developed in Assembly language are non-portable. Here comes the role of
high level languages. Any high level language (like C, C++ or Java) with a supported cross
compiler (for converting the application developed in high level language to target processor
specific assembly code – We will discuss cross-compilers in detail in a later section) for the
target processor can be used for embedded firmware development.
 The most commonly used high level language for embedded firmware application development
is ‘C’. You may be thinking why ‘C’ is used as the popular embedded fimware development
language.

MIT Thandavapura
  The answer is “C is the well-defined, easy to use high level language with extensive cross
platform development tool support”. Nowadays Cross-compilers for C++ is also emerging out
and embedded developers are making use of C++ for embedded application development.
 The various steps involved in high level language based embedded firmware development is
same as that of assembly language based development except that the conversion of source file
written in high level language to object fi le is done by a cross-compiler, whereas in Assembly
language based development it is carried out by an assembler.
 The various steps involved in the conversion of a program written in high level language to
corresponding binary fi le/machine language is illustrated in Fig. 9.2. The program written in
any of the high level language is saved with the corresponding language extension (.c for C,
.cpp for C++, etc).
 Any text editor like ‘notepad’ or ‘WordPad’ from Microsoft® or the text editor provided by an
Integrated Development (IDE) tool supporting the high level language in use can be used for
writing the program. Most of the high level languages support modular programming approach
and hence you can have multiple source files called modules written in corresponding high
level language.
 The source files corresponding to each module is represented by a fi le with corresponding
language extension. Translation of high level source code to executable object code is done by
a cross-compiler.
 The crosscompilers for different high level languages for the same target processor are
different. It should be noted that each high level language should have a cross-compiler for
converting the high level source code into the target processor machine code. Without cross-
compiler support a high level language cannot be used for embedded firmware development.
C51 Cross-compiler from Keil software is an example for Crosscompiler. C51 is a popular
cross-compiler available for ‘C’ language for the 8051 family of micro controller. Conversion
of each module’s source code to corresponding object fi le is performed by the cross compiler.
 Rest of the steps involved in the conversion of high level language to target processor’s
machine code are same as that of the steps involved in assembly language based development.

MIT Thandavapura
9.2.2.1 Advantages of High Level Language Based Development

Reduced Development Time Developer requires less or little knowledge on the internal hardware
details and architecture of the target processor/controller. Bare minimal knowledge of the memory
organisation and register details of the target processor in use and syntax of the high level language
are the only pre-requisites for high level language based firmware development. Rest of the things will
be taken care of by the cross compiler used for the high level language. Thus the ramp up time required
by the developer in understanding the target hardware and target machine’s assembly instructions is
waived off by the cross compiler and it reduces the development time by significant reduction in
developer effort. High level language based development also refines the scope of embedded firmware
development from a team of specialised architects to anyone knowing the syntax of the language and
willing to put little effort on understanding the minimal hardware details. With high level language,
each task can be accomplished by lesser number of lines of code compared to the target
processor/controller specific Assembly language based development. Developer Independency The
syntax used by most of the high level languages are universal and a program written in the high level
language can easily be understood by a second person knowing the syntax of the language. Certain
instructions may require little knowledge of the target hardware details like register set, memory map
etc. Apart from these, the high level language based firmware development makes the firmware,
developer independent. High level languages always instruct certain set of rules for writing the code
and commenting the piece of code. If the developer strictly adheres to the rules, the firmware will be
100% developer independent. Portability Target applications written in high level languages are
converted to target processor/controller understandable format (machine codes) by a cross-compiler.
An application written in high level language for a particular target processor can easily be converted
to another target processor/controller specific application, with little or less effort by simply re-
compiling/little code modification followed by re-compiling the application for the required target
processor/controller.

9.2.2.2 Limitations of High Level Language Based Development

The merits offered by high level language based design take advantage over its limitations. Some cross
compilers available for high level languages may not be so efficient in generating optimised target
processor specific instructions. Target images created by such compilers may be messy and non-
optimised in terms of performance as well as code size. For example, the task achieved by cross-
compiler generated machine instructions from a high level language may be achieved through a lesser
number of instructions if the same task is hand coded using target processor specific machine codes.
The time required to execute a task also increases with the number of instructions. However modern
cross-compilers are tending to adopt designs incorporating optimisation techniques for both code size
and performance. High level language based code snippets may not be efficient in accessing low level
hardware where hardware access timing is critical (of the order of nano or micro seconds).
The investment required for high level language based development tools (Integrated Development
Environment incorporating cross-compiler) is high compared to Assembly Language based firmware
Development tools.

9.2.3 Mixing Assembly and High Level Language

Certain embedded firmware development situations may demand the mixing of high level language
with Assembly and vice versa. High level language and assembly languages are usually mixed in three
ways; namely, mixing Assembly Language with High Level Language, mixing High Level Language
with Assembly and In-line Assembly programming.

MIT Thandavapura
9.2.3.1 Mixing Assembly with High level language (e.g. Assembly Language with
‘C’)
Assembly routines are mixed with ‘C’ in situations where the entire program is written in ‘C’ and the
cross compiler in use do not have a built in support for implementing certain features like Interrupt
Service Routine functions (ISR) or if the programmer wants to take advantage of the speed and
optimised code offered by machine code generated by hand written assembly rather than cross
compiler generated machine code. When accessing certain low level hardware, the timing
specifications may be very critical and a cross compiler generated binary may not be able to offer the
required time specifications accurately. Writing the hardware/peripheral access routine in
processor/controller specific Assembly language and invoking it from ‘C’ is the most advised method
to handle such situations. Mixing ‘C’ and Assembly is little complicated in the sense—the programmer
must be aware of how parameters are passed from the ‘C’ routine to Assembly and values are returned
from assembly routine to ‘C’ and how ‘Assembly routine’ is invoked from the ‘C’ code.
Passing parameter to the assembly routine and returning values from the assembly routine to the caller
‘C’ function and the method of invoking the assembly routine from ‘C’ code is cross compiler
dependent. There is no universal written rule for this. You must get these information from the
documentation of the cross compiler you are using. Different cross compilers implement these features
in different ways depending on the general purpose registers and the memory supported by the target
processor/controller. Let’s examine this by taking Keil C51 cross compiler for 8051 controller. The
objective of this example is to give an idea on how C51 cross compiler performs the mixing of
Assembly code with ‘C’.

9.2.3.2 Mixing High Level Language with Assembly (e.g. ‘C’ with Assembly
Language)
Mixing the code written in a high level language like ‘C’ and Assembly language is useful in the
following scenarios:
1. The source code is already available in Assembly language and a routine written in a high level
language like ‘C’ needs to be included to the existing code.
2. The entire source code is planned in Assembly code for various reasons like optimised code, optimal
performance, efficient code memory utilisation and proven expertise in handling the Assembly, etc.
But some portions of the code may be very difficult and tedious to code in Assembly. For example
16bit multiplication and division in 8051 Assembly Language.
3. To include built in library functions written in ‘C’ language provided by the cross compiler. For
example Built in Graphics library functions and String operations supported by ‘C’.

9.2.3.3 Inline Assembly

Inline assembly is another technique for inserting target processor/controller specific Assembly
instructions at any location of a source code written in high level language ‘C’. This avoids the delay
in calling an assembly routine from a ‘C’ code (If the Assembly instructions to be inserted are put in
a subroutine as mentioned in the section mixing assembly with ‘C’). Special keywords are used to
indicate that the start and end of Assembly instructions. The keywords are cross-compiler specific.

MIT Thandavapura
C51 uses the keywords #pragma asm and #pragma endasm to indicate a block of code written in
assembly.

Embedded System Development Environments

13.2 TYPES OF FILES GENERATED ON CROSS-COMPILATION
Cross-compilation is the process of converting a source code written in high level language (like
‘Embedded C’) to a target processor/ controller understandable machine code (e.g. ARM processor or
8051 microcontroller specific machine code). The conversion of the code is done by software running
on a processor/controller (e.g. x86 processor based PC) which is different from the target processor.
The software performing this operation is referred as the ‘Cross-compiler’. In a single word cross-
compilation is the process of cross platform software/firmware development. Cross assembling is
similar to cross-compiling; the only difference is that the code written in a target processor/controller
specific Assembly code is converted into its corresponding machine code. The application converting
Assembly instruction to target processor/controller specific machine code is known as cross-
assembler. Cross-compilation/cross-assembling is carried out in different steps and the process
generates various types of intermediate fi les. Almost all compilers provide the option to select
whatever
Intermediate fi les needs to be retained after cross-compilation. The various fi les generated during the
cross compilation/ cross-assembling process are: List File (.lst), Hex File (.hex), Pre-processor Output
file, Map File (File extension linker dependent),
Object File (.obj)

13.2.1 List File (.LST File)

Listing fi le is generated during the cross-compilation process and it contains an abundance of
information about the cross compilation process, like cross compiler details, formatted source text (‘C’
code), assembly code generated from the source fi le, symbol tables, errors and warnings detected
during the cross-compilation process. The type of information contained in the list fi le is cross-
compiler specific. As an example let’s consider the cross-compilation process of the fi le sample.c
given as the fi rst illustrative embedded C program under Keil μVision5 IDE discussion. The ‘list fi
le’ generated contains the following sections.
Page Header: A header on each page of the listing fi le which indicates the compiler version number,
source file name, date, time, and page number

Command Line: Represents the entire command line that was used for invoking the compiler.

Source Code: The source code listing outputs the line number as well as the source code on that line.
Special cross compiler directives can be used to include or exclude the conditional codes (code in #if
blocks) in the source code listings. Apart from the source code lines, the list fi le will include the
comments in the source file and depending on the list fi le generation settings the entire contents of all

MIT Thandavapura
include files may also be included. Special cross compiler directives can be used to include the entire
contents of the include fi le in the list file.

Assembly Listing: Assembly listing contains the assembly code generated by the cross compiler for
the ‘C’ source code. Assembly code generated can be excluded from the list fi le by using special
compiler directives.

MIT Thandavapura
Symbol Listing: The symbol listing contains symbolic information about the various symbols present
in the cross compiled source fi le. Symbol listing contains the sections symbol name (NAME) symbol
classification
(CLASS (Special Function Register (SFR), structure, type def, static, public, auto, extern, etc.)),
memory space (MSPACE (code memory or data memory)), data type (TYPE (int, char, Procedure call,
etc.)), offset ((OFFSET from code memory start address)) and size in bytes (SIZE). Symbol listing in
list file output can be turned on or off by cross-compiler directives.

Module Information: The module information provides the size of initialised and un-initialised
memory areas defined by the source file

Warnings and Errors Warnings and Errors section of list fi le records the errors encountered or any
statement that may create issues in application (warnings), during cross compilation. The warning
levels can be configured before cross compilation. You can ignore certain warnings, e.g. a local
variable is declared within a function and it is not used anywhere in the program. Certain warnings
require prompt attention.

13.2.2 Preprocessor Output File

The preprocessor output file generated during cross-compilation contains the preprocessor
output for the preprocessor instructions used in the source fi le. Preprocessor output fi le is used for
verifying the operation of macros and conditional preprocessor directives. The preprocessor output fi
le is a valid C source file. File extension of preprocessor output file is cross compiler dependent.

13.2.3 Object File (.OBJ File)

Cross-compiling/assembling each source module (written in C/Assembly) converts the various
Embedded C/Assembly instructions and other directives present in the module to an object (.OBJ) file.
The format (internal representation) of the .OBJ fi le is cross compiler dependent. OMF51 or OMF2
are the two objects file formats supported by C51 cross compiler. The object fi le is a specially
formatted fi le with data records for symbolic information, object code, debugging information, library
references, etc. The list of some of the details stored in an object fi le is given below.
1. Reserved memory for global variables.
2. Public symbol (variable and function) names.
3. External symbol (variable and function) references.
4. Library fi les with which to link.
5. Debugging information to help synchronise source lines with object code.

MIT Thandavapura
The object code present in the object fi le are not absolute, meaning, the code is not allocated fixed
memory location in code memory. It is the responsibility of the linker/locater to assign an absolute
memory location to the object code. During cross-compilation process, the cross compiler sets the
address of references to external variables and functions as 0. The external references are resolved by
the linker during the linking process. Hence it is obvious that the code generated by the cross-compiler
is not executable without linking it for resolving external references.

13.2.4 Map File (.MAP)

As mentioned above, the cross-compiler converts each source code module into a re-locatable
object (OBJ) file. Cross-compiling each source code module generates its own list fi le. In a project
with multiple source files, the cross-compilation of each module generates a corresponding object fi
le. The object files so created are re-locatable codes, meaning their location in the code memory is not
fi xed. It is the responsibility of a linker to link all these object fi les. The locater is responsible for
locating absolute address to each module in the code memory. Linking and locating of re-locatable
object fi les will also generate a list fi le called ‘linker list file’ or ‘map fi le’. Map fi le contains
information about the link/locate process and is composed of a number of sections. The different
sections listed in a map file are cross compiler dependent. The information generally held by map fi
les is listed below. It is not necessary that the map fi les generated by all linkers/ locaters should contain
all these information. Some may contain less information compared to this or others may contain more
information than given in this. It all depends on the linker/locater. Page Header A header on each page
of the linker listing (MAP) fi le which indicates the linker version number, date, time, and page
number.

Symbol Table: It contains the value, type and name for all symbols from the different input modules
Inter Module Cross Reference The cross reference listing includes the section name, memory type and
the name of the modules in which it is defined and all modules in which it is accessed.
Program Size: Program size information contain the size of various memory areas as well as constant
and code space for the entire application
e.g. Program Size: data=30.1 xdata=0 code=1078

MIT Thandavapura
Warnings and Errors Errors and warnings generated while linking a program are written to this section.
It is very useful in debugging link errors.

13.2.5 HEX File (.HEX)

Hex fi le is the binary executable fi le created from the source code. The absolute object fi le
created by the linker/locater is converted into processor understandable binary code. The utility used
for converting an object file to a hex fi le is known as Object to Hex fi le converter. Hex fi les embed
the machine code in a particular format. The format of Hex fi le varies across the family of
processors/controllers. Intel HEX and Motorola HEX are the two commonly used hex fi le formats in
embedded applications. Intel HEX fi le is an ASCII text fi le in which the HEX data is represented in
ASCII format in lines. The lines in an Intel HEX file are corresponding to a HEX Record. Each record
is made up of hexadecimal numbers that represent machine-language code and/or constant data.
Individual records are terminated with a carriage return and a linefeed. Intel HEX fi le is used for
transferring the program and data to a ROM or EPROM which is used as code memory storage.

13.2.5.1 Intel HEX File Format

As mentioned, Intel HEX fi le is composed of a number of HEX records. Each record is made up of
five fields arranged in the following format:
:llaaaattdd...cc

13.2.5.2 Motorola HEX File Format

Similar to the Intel HEX fi le, Motorola HEX fi le is also an ASCII text fi le where the HEX data is
represented in ASCII format in lines. The lines in Motorola HEX fi le represent a HEX Record. Each
record is made up of hexadecimal numbers that represent machine-language code and/or constant data.
The general form of
Motorola Hex record is given below.

13.3 DISASSEMBLER/DECOMPILER
Disassembler is a utility program which converts machine codes into target processor specific
Assembly codes/instructions. The process of converting machine codes into Assembly code is known
as ‘Disassembling’. In operation, disassembling is complementary to assembling/crossassembling.
Decompiler is the utility program for translating machine codes into corresponding high level language
instructions. Decompiler performs the reverse operation of compiler/cross-compiler. The
disassemblers/ decompilers for different family of processors/controllers are different.
Disassemblers/Decompilers are deployed in reverse engineering. Reverse engineering is the process
of revealing the technology behind the working of a product. Reverse engineering in Embedded
Product development is employed to fi nd out the secret behind the working of popular proprietary
products. Disassemblers/decompilers help the reverse-engineering process by translating the
embedded fi rmware into Assembly/high level language instructions. Disassemblers/ Decompilers are
powerful tools for analysing the presence of malicious codes (virus information) in an executable
image. Disassemblers/Decompilers are available as either freeware tools readily available for free
download from internet or as commercial tools. It is not possible for a disassembler/decompiler to
generate an exact replica of the original assembly code/high level source code in terms of the symbolic
constants and comments used. However disassemblers/decompilers generate a source code which is
somewhat matching to the original source code from which the binary code is generated.

MIT Thandavapura
13.4 SIMULATORS, EMULATORS AND DEBUGGING
Simulators and emulators are two important tools used in embedded system development. Both
the terms sound alike and are little confusing. Simulator is a software tool used for simulating the
various conditions for checking the functionality of the application firmware. The Integrated
Development
Environment (IDE) itself will be providing simulator support and they help in debugging the firmware
for checking its required functionality. In certain scenarios, simulator refers to a soft model (GUI
model) of the embedded product. For example, if the product under development is a handheld device,
to test the functionalities of the various menu and user interfaces, a soft form model of the product
with all UI as given in the end product can be developed in software. Soft phone is an example for
such a simulator. Emulator is hardware device which emulates the functionalities of the target device
and allows real time debugging of the embedded firmware in a hardware environment.

13.4.1 Simulators
discussed about simulators for embedded firmware debugging. Simulators simulate the target
hardware and the firmware execution can be inspected using simulators. The features of simulator
based debugging are listed below.
1. Purely software based
2. Doesn’t require a real target system
3. Very primitive (Lack of featured I/O support. Everything is a simulated one)
4. Lack of Real-time behaviour

13.4.1.1 Advantages of Simulator Based Debugging

Simulator based debugging techniques are simple and straightforward. The major advantages
of simulator based firmware debugging techniques are explained below. No Need for Original Target
Board Simulator based debugging technique is purely software oriented. IDE’s software support
simulates the CPU of the target board. User only needs to know about the memory map of various
devices within the target board and the firmware should be written on the basis of it. Since the real
hardware is not required, firmware development can start well in advance immediately after the device
interface and memory maps are finalised. This saves development time. Simulate I/O Peripherals
Simulator provides the option to simulate various I/O peripherals. Using simulators
I/O support you can edit the values for I/O registers and can be used as the input/output value in the
firmware execution. Hence it eliminates the need for connecting I/O devices for debugging the
firmware. Simulates Abnormal Conditions With simulator’s simulation support you can input any
desired value for any parameter during debugging the firmware and can observe the control flow of
firmware. It really helps the developer in simulating abnormal operational environment for firmware
and helps the firmware developer to study the behaviour of the firmware under abnormal input
conditions.

13.4.1.2 Limitations of Simulator based Debugging

Though simulation based firmware debugging technique is very helpful in embedded
applications, they possess certain limitations and we cannot fully rely upon the simulator-based
firmware debugging. Some of the limitations of simulator-based debugging are explained below.
Devia on from Real Behaviour Simulation-based firmware debugging is always carried out in a
development environment where the developer may not be able to debug the firmware under all
possible combinations of input. Under certain operating conditions we may get some particular result
and it need not be the same when the firmware runs in a production environment. Lack of Real
Timeliness The major limitation of simulator based debugging is that it is not real-time in behaviour.
The debugging is developer driven and it is no way capable of creating a real time behaviour. Moreover

MIT Thandavapura
in a real application the I/O condition may be varying or unpredictable. Simulation goes for simulating
those conditions for known values.

13.4.2 Emulators and Debuggers

What is debugging and why debugging is required? Debugging in embedded application is the
process of diagnosing the firmware execution, monitoring the target processor’s registers and memory
while the firmware is running and checking the signals from various buses of the embedded hardware.
Debugging process in embedded application is broadly classified into two, namely; hardware
debugging and firmware debugging. Hardware debugging deals with the monitoring of various bus
signals and checking the status lines of the target hardware. The various tools used for hardware
debugging will be explaining in detail in a later section of this chapter. Firmware debugging deals with
examining the firmware execution, execution flow, changes to various CPU registers and status
registers on execution of the firmware to ensure that the firmware is running as per the design. This
section deals with the debugging of firmware. Why is debugging required? Well the counter question
why you go for diagnosis when you are ill answers this query. Firmware debugging is performed to
figure out the bug or the error in the firmware which creates the unexpected behaviour. Firmware is
analogous to the human body in the sense it is widespread and/or modular. Any abnormalities in any
area of the body may lead to sickness. How is the region causing illness identified correctly when you
are sick? If we look back to the 1900s, where no sophisticated diagnostic techniques were available,
only a skilled doctor was capable of identifying the root cause of illness, that too with his solid
experience. Now, with latest technologies, the scenario is totally changed. Sophisticated diagnostic
techniques provide offline diagnosis like Computerised Tomography (CT), MRI and ultrasound scans
and online diagnosis like micro camera based imaging techniques. With the intrusion of a micro camera
into the body, the doctors can view the internals of the body in real time. During the early days of
embedded system development, there were no debug tools available and the only way was “Burn the
code in an EEPROM and pray for its proper functioning”. If the firmware does not crash, the product
works fi ne. If the product crashes, the developer is unlucky and he needs to sit back and rework on
the firmware till the product functions in the expected way. Most of the time the developer had to seek
the help of an expert to figure out the exact problem creator. As technology has achieved a new
dimension from the early days of embedded system development, various types of debugging
techniques are available today. The following section describes the improvements over firmware
debugging starting from the most primitive type of debugging to the most sophisticated On Chip
Debugging (OCD).

13.4.2.1 Incremental EEPROM Burning Technique

This is the most primitive type of firmware debugging technique where the code is separated
into different functional code units. Instead of burning the entire code into the EEPROM chip at once,
the code is burned in incremental order, where the code corresponding to all functionalities are
separately coded, cross-compiled and burned into the chip one by one. The code will incorporate some
indication support like lighting up an “LED (every embedded product contains at least one LED). If
not, you should include provision for at least one LED in the target board at the hardware design time
such that it can be used for debugging purpose)” or activate a “BUZZER (In a system with BUZZER
support)” if the code is functioning in the expected way. If the first functionality is found working
perfectly on the target board with the corresponding code burned into the EEPROM, go for burning
the code corresponding to the next functionality and check whether it is working. Repeat this process
till all functionalities are covered. Please ensure that before entering into one level up, the previous
level has delivered a correct result. If the code corresponding to any functionality is found not giving
the expected result, fi x it by modifying the code and then only go for adding the next functionality for
burning into the EEPROM. After you found all functionalities working properly, combine the entire
source for all functionalities together, re-compile and burn the code for the total system functioning.

MIT Thandavapura
13.4.2.2 Inline Breakpoint Based Firmware Debugging
Inline breakpoint based debugging is another primitive method of firmware debugging. Within
the firmware where you want to ensure that firmware execution is reaching up to a specified point,
insert an inline debug code immediately after the point. The debug code is a printf() function which
prints a string given as per the firmware. You can insert debug codes (printf()) commands at each point
where you want to ensure the firmware execution is covering that point. Cross-compile the source code
with the debug codes embedded within it. Burn the corresponding hex fi le into the EEPROM. You
can view the printf() generated data on the a ‘Terminal Program’ like PUTTy or TeraTerm. Confi gure
the serial communication settings of the ‘Terminal Program’ connection to the same as that of the
serial communication settings configured in the firmware (Say Baudrate = 9600; Parity = None; Stop
Bit = 1; Flow Control = None); Connect the target board’s serial port
(COM) to the development PC’s COM Port using an RS232 Cable. Power up the target board.
Depending on the execution flow of firmware and the inline debug codes inserted in the firmware, you
can view the debug information on the ‘Terminal Program’.
Monitor program based firmware debugging is the first adopted invasive method for firmware
debugging (Fig. 13.39). In this approach a monitor program which acts as a supervisor is developed.
The monitor program controls the downloading of user code into the code memory, inspects and
modifies register/memory locations; allows single stepping of source code, etc. The monitor program
implements the debug functions as per a pre-defined command set from the debug application
interface. The monitor program always listens
to the serial port of the target device and according to the command received from the serial interface
it performs command specific actions like firmware downloading, memory inspection/modifi cation,
firmware single stepping and sends the debug information (various register and memory contents) back
to the main debug program running on the development PC, etc. The fi rst step in any monitor program
development is determining a set of commands for performing various operations like fi rmware
downloading, memory/ register inspection/modifi cation, single stepping, etc. Once the commands for
each operation is fixed, write the code for performing the actions corresponding to these commands.
As mentioned earlier, the commands may be received through any of the external interface of the target
processor (e.g. RS-232C serial interface/ parallel interface/USB, etc.). The monitor program should
query this interface to get commands or should handle the command reception if the data reception is
implemented through interrupts. On receiving a command, examine it and perform the action
corresponding to it. The entire code stuff handling the command reception and corresponding action
implementation is known as the “monitor program”. The most common type of interface used between
target board and debug application is RS-232/USB Serial interface. After the successful completion of
the ‘monitor program’ development, it is compiled and burned into the FLASH memory or ROM of
the target board. The code memory containing the monitor program is known as the ‘ Monitor ROM’.

MIT Thandavapura
The monitor program contains the following set of minimal features.
1. Command set interface to establish communication with the debugging application
2. Firmware download option to code memory
3. Examine and modify processor registers and working memory (RAM)
4. Single step program execution
5. Set breakpoints in firmware execution
6. Send debug information to debug application running on host machine

13.4.2.4 In Circuit Emulator ( ICE) Based Firmware Debugging

 The terms ‘Simulator’ and ‘Emulator’ are little bit confusing and sounds similar.
 Though their basic functionality is the same – “Debug the target firmware”, the way in which
they achieve this functionality is totally different. As mentioned before, ‘Simulator’ is a
software application that precisely duplicates (mimics) the target CPU and simulates the
various features and instructions supported by the target CPU, whereas an ‘Emulator’ is a self-
contained hardware device which emulates the target CPU. The emulator hardware contains
necessary emulation logic and it is hooked to the debugging application running on the
development PC on one end and connects to the target board through some interface on the
other end. In summary, the simulator ‘simulates’ the target board CPU and the emulator
‘emulates’ the target board CPU. There is a scope change that has happened to the definition
of an emulator.
 In olden days emulators were defined as special hardware devices used for emulating the
functionality of a processor/controller and performing various debug operations like halt
firmware execution, set breakpoints, get or set internal RAM/CPU register, etc. Nowadays pure
software applications which perform the functioning of a hardware The Embedded System
Development Environment 613 emulator is also called as ‘Emulators’ (though they are
‘Simulators’ in operation).
 The emulator application for emulating the operation of a PDA phone for application
development is an example of a ‘Software Emulator’. A hardware emulator is controlled by a
debugger application running on the development PC. The debugger application may be part
of the Integrated Development Environment (IDE) or a third party supplied tool. Most of the
IDEs incorporate debugger support for some of the emulators commonly available in the
market. The emulators for different families of processors/controllers are different. Figure
13.40 illustrates the different subsystems and interfaces of an ‘Emulator’ device.
 Emulation Device Emulation device is a replica of the target CPU which receives various
signals from the target board through a device adaptor connected to the target board and
performs the execution of firmware under the control of debug commands from the debug
application. The emulation device can be either a standard chip same as the target processor
(e.g. AT89C51) or a Programmable Logic Device (PLD) configured to function as the target
CPU.
 Emulation Memory It is the Random Access Memory (RAM) incorporated in the Emulator
device. It acts as a replacement to the target board’s EEPROM where the code is supposed to
be downloaded after each firmware modification. Hence the original EEPROM memory is
emulated by the RAM of emulator. This is known as ‘ROM Emulation’.

MIT Thandavapura
The common features of trace buffer memory and trace buffer data viewing are
listed below:
Σ Trace buffer records each bus cycle in frames
Σ Trace data can be viewed in the debugger application as Assembly/Source code
Σ Trace buffering can be done on the basis of a Trace trigger (Event)
Σ Trace buffer can also record signals from target board other than CPU signals (Emulator dependent)
Σ Trace data is a very useful information in firmware debugging
Emulator Control Logic Emulator control logic is the logic circuits used for implementing complex
hardware breakpoints, trace buffer trigger detection, trace buffer control, etc. Emulator control logic
circuits are also used for implementing logic analyser functions in advanced emulator devices. The
‘Emulator POD’ is connected to the target board through a ‘Device adaptor’ and signal cable.
Device Adaptors Device adaptors act as an interface between the target board and emulator POD.
Device adaptors are normally pin-to-pin compatible sockets which can be inserted/plugged into the
target board for routing the various signals from the pins assigned for the target processor. The device
adaptor is usually connected to the emulator POD using ribbon cables. The adaptor type varies
depending on the target processor’s chip package. DIP, PLCC, etc. are some commonly used adaptors.

13.4.2.5 On Chip Firmware Debugging (OCD)

Advances in semiconductor technology has brought out new dimensions to target firmware debugging.
Today almost all processors/controllers incorporate built in debug modules called On Chip Debug (
OCD) support. Though OCD adds silicon complexity and cost factor, from a developer perspective it
is a very good feature supporting fast and efficient firmware debugging. The On Chip Debug facilities
integrated to the processor/controller are chip vendor dependent and most of them are proprietary
technologies like Background Debug Mode (BDM), OnCE, etc. Some vendors add ‘on chip software
debug support’ through JTAG (Joint TestAction Group) port. Processors/controllers with OCD support
incorporate a dedicated debug module to the existing architecture. Usually the on-chip debugger
provides the means to set simple breakpoints, query the internal state of the chip and single step through
code. OCD module implements dedicated registers for controlling debugging. An On Chip Debugger
can be enabled by setting the OCD enable bit (The bit name and register holding the bit varies across
vendors). Debug related registers are used for debugger control (Enable/disable single stepping, Freeze
execution, etc.) and breakpoint address setting. BDM and JTAG are the two commonly used interfaces
to communicate between the Debug application running on Development PC and OCD module of
target CPU. Some interface logic in the form of hardware will be implemented between the CPU OCD
interface and the host PC to capture the debug information from the target CPU and sending it to the
debugger application running on the host PC. The interface between the hardware and PC may be
Serial/Parallel/USB. The following section will give you a brief introduction about Background Debug
Mode (BDM) and JTAG interface used in On Chip Debugging. Background Debug Mode (BDM)
interface is a proprietary On Chip Debug solution from Motorola. BDM defines the communication

MIT Thandavapura
interface between the chip resident debug core and host PC where the BDM compatible remote
debugger is running. BDM makes use of 10 or 26 pin connector to connect to the target board. Serial
data in (DSI), Serial data out (DSO) and Serial clock (DSCLK) are the three major signal lines used in
BDM. DSI sends debug commands serially to the target processor from the remote debugger
application and DSO sends the debug response to the debugger from the processor. Synchronisation
of serial transmission is done by the serial clock DSCLK generated by the debugger application.
Debugging is controlled by BDM specific debug commands. The debug commands are usually 17-bit
wide. 16 bits are used for representing the command and 1 bit for status/control. Chips with JTAG
debug interface contain a built-in JTAG port for communicating with the remote debugger application.
JTAG is the acronym for Joint Test Action Group. JTAG is the alternate name for IEEE 1149.1
standard. Like BDM, JTAG is also a serial interface. The signal lines of JTAG protocol are explained
below.
Test Data In (TDI): It is used for sending debug commands serially from remote debugger to the
target
processor.
Test Data Out (TDO): Transmit debug response to the remote debugger from target CPU.
Test Clock (TCK): Synchronises the serial data transfer.
Test Mode Select (TMS): Sets the mode of testing.
Test Reset (TRST): It is an optional signal line used for resetting the target CPU.
The serial data transfer rate for JTAG debugging is chip dependent. It is usually within the range of 10
to 1000 MHz.

MIT Thandavapura