Hardware Software Co-Design

Traditional development approach

• In the traditional embedded system development approach, the

hardware software partitioning is done at an early stages
embedded system.
• Engineers from the software group take care of the software
architecture development and implementation, whereas
engineers from the hardware group are responsible for building
the hardware required for the product.
• There is less interaction between the two teams and the
development happens either serially or in parallel.
• Once the hardware and software are ready, the integration is
performed.
• The increasing competition in the commercial market and need
for reduced ‘ time-to-market’ the product calls for a novel
approach for embedded system design in which the hardware
and software are co-developed instead of independently
developing both.
FUNDAMENTAL ISSUES IN HARDWARE SOFTWARE CO-
DESIGN
• The hardware software co-design is a problem statement and when we
try to solve this problem statement in real life we may come across
multiple issues in the design.
• Some of the fundamental issues in hardware software co-design are:
Model selection : Captures and describes system characteristics and
specifications. It does not provide the information of how the system
can be manufactured.
Architecture Selection : Specifies how the system is going to
implement in terms of number of different types of components and
interaction among them.
Language selection: Programming language captures “computation
model” and maps it into architecture. Model can be captured using
multiple programming languages like C, C++,Java, etc the language
should capture the model easily.
H/W – S/W Partitioning: Is an implementation aspect of a system level
requirement. Performance, reusability, effort etc are to be considered.
COMPUTATIONAL MODELS IN EMBEDDED DESIGN

• Data Flow Graph (DFG) model,

• State Machine model,

• Concurrent Process model,

• Sequential Program model,

• Object Oriented model, etc.

are the commonly used computational models in embedded

system design.
 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 emphasizes on the data and operations on the
data which transforms the input data to output data.

Suppose one of the functions in our

application contains the
computational requirement x = a + b;
and y = x – c.
Control Data Flow Graph/Diagram (CDFG)
• The Control DFG ( CDFG) model is used for modeling
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;
Control Data Flow Graph/Diagram (CDFG)

If flag = 1, x = a + b; else y = a – b;
State Machine Model
• The State Machine model is used for modeling reactive or
event-driven embedded systems whose processing behavior
are dependent on state transitions.
• The State Machine model describes the system behavior 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.
Finite State Machine ( FSM) model
• 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
modeled as given in Fig.
• 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.
• 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.
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
1. ‘Conventional Procedural Based Firmware Design’ and
2. ‘ Embedded Operating System (OS) Based Design’.
• The conventional procedural based design is also known as
‘Super Loop Model’.
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.

• This is a true procedural one. In a multiple task based system,
each task is executed in serial in this approach. The firmware
execution flow for this will be
• 1. Configure the common parameters and perform
initialization for various hardware components memory,
registers, etc.
• 2. Start the fi rst task and execute it
• 3. Execute the second task
• 4. Execute the next task
• 5. :
• 6. :
• 7. Execute the last defi ned task
• 8. Jump back to the fi rst task and follow the same fl ow
• 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
• We can visualize the operational sequence listed above in
terms of a ‘C’ program code as

•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 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.
• 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.
• 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.
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.
• 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.
• 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.
EMBEDDED FIRMWARE DEVELOPMENT LANGUAGES
• We 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.

Assembly Language based Development

• 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.
• The general format of an assembly language instruction is an
Op code followed by Operands.
• The Op code tells the processor/controller what to do and the
Operands provide the data and information required to perform
the action specified by the op code.
• MOV A, #30
• This instruction mnemonic moves decimal value 30 to the 8051
Accumulator register. Here MOV A is the Op code 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 op
code MOV A and the second 8 bit binary value 00011110
represents the operand 30.
• LJMP 16bit address is an example for dual operand instruction.
The machine language for the same is
• 00000010 addr_bit15 to addr_bit 8 addr_bit7 to addr_bit 0
• Each line of an assembly language program is split into four
fields as given below
• LABEL OPCODE OPERAND COMMENTS
• A ‘LABEL’ is an identifi er used extensively in programs
• The sample code given below using 8051 Assembly language
illustrates the structured assembly language programming.
• The Assembly language program written in assembly code is
saved as .asm (Assembly file) file or an .src (source) file

• Modular programming is employed when the program is

too complex or too big. In ‘Modular Programming’, the entire
code is divided into sub modules and each module is made
re-usable. Modular Programs are usually easy to code, debug
and alter.
Source File to Object File Translation

The various steps involved in the conversion of a program written

in assembly language to corresponding binary file/machine
language is illustrated in Fig. 9.1.
• Each source module is written in Assembly and is stored
as .src file or .asm file. Each file can be assembled
separately to examine the syntax errors and incorrect
assembly instructions.
• On successful assembling of each .src/.asm file a
corresponding object file is created with extension ‘.obj’
• The object file 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 file creation stage.
• Importing a variable or function from a module (taking a variable
or function from any one of other modules) is done by declaring
that variable or function as EXTRN (EXTERN) in the module
where it is going to be accessed.
• The ‘PUBLIC’ Keyword informs the assembler that the variables
or functions declared as ‘PUBLIC’ needs to be exported.
• Similarly the ‘EXTRN’ Keyword tells the assembler that the
variables or functions declared as ‘EXTRN’ needs to be imported
from some other modules.
Library File Creation on and Usage
• Libraries are specially formatted, ordered program collections of
object modules that may be used by the linker at a later time.
• When the linker processes a library, only those object modules in
the library that are necessary to create the program are used.
Library files are generated with extension ‘.lib’.
 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.
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 file representation varies
depending on the target processor/controller make
Advantages of Assembly Language Based Development
The major advantages of Assembly Language based development is listed
below.
• Efficient Code Memory and Data Memory Usage (Memory
Optimisaon)
• Since the developer is well versed with the target processor architecture and
memory organization, optimized code can be written for performing
operations.
• High Performance Optimized code not only improves the code memory
usage but also improves the total system performance.
• 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’.
Drawbacks of Assembly Language Based Development
• Every technology has its own pros and cons. From certain
technology aspects assembly language development is the
most efficient technique. But it is having the following technical
limitations also.
• High Development Time
• Non-Portable
High Level Language Based Development
• The most commonly used high level language for embedded
firmware application development is ‘C’.
• C is the well defined, easy to use high level language with
extensive cross platform development tool support.
• 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.
High level language to machine language conversion
process
Advantages of High Level Language Based Development

• Reduced Development Time

• Developer Independency
• Portability

Limitations of High Level Language Based Development

• Some cross compilers available for high level languages may
not be so efficient in generating optimized target processor
specific instructions.
• High level language based code snippets may not be efficient
in accessing low level hardware where hardware access
timing is critical
 Mixing Assembly and High Level Language
• Certain embedded fi rmware 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.
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 optimized code offered by machine
code generated by hand written assembly rather than cross
compiler generated machine code.
• Writing the hardware/ peripheral access routine in
processor/controller specific c 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.
The objective of this example is to give an idea on how
C51 cross compiler performs the mixing of Assembly code with
‘C’.
• 1. Write a simple function in C that passes parameters and
returns values the way you want your assembly routine to.
• 2. Use the SRC directive (#PRAGMA SRC at the top of the fi
le) so that the C compiler generates an .SRC file instead of
an .OBJ file.
• 3. Compile the C file. Since the SRC directive is specified,
the .SRC file is generated. The .SRC file contains the
assembly code generated for the C code you wrote.
• 4. Rename the .SRC file to .A51 file.
• 5. Edit the .A51 file and insert the assembly code you want
to execute in the body of the assembly function shell
included in the .A51 file.
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 optimized code, optimal performance, efficient code memory
utilization 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 16 bit multiplication and division in 8051 Assembly Language.
3. To include built in library functions written in ‘C’ language provided by
the cross compiler.
E.g. LCALL _Cfunction
• The ‘C’ subroutine can be invoked from the assembly program using the
subroutine call Assembly instruction
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. C51 uses the keywords #pragma asm and #pragma
endasm to indicate a block of code written in assembly.
• E.g. #pragma asm
MOV A, #13H
#pragma end asm
Integration and Testing of Embedded Hardware and Firmware

• Both embedded hardware and firmware should be independently

tested (Unit Tested) to ensure their proper functioning.
• Functioning of individual hardware sections can be verified by
writing small utilities which checks the operation of the specified
part.
• As far as the embedded firmware is concerned, its targeted
functionalities can easily be checked by the simulator
environment provided by the embedded firmware development
tool’s IDE.
• By simulating the firmware, the memory contents, register
details, status of various flags and registers can easily be
monitored and it gives an approximate picture of “What happens
inside the processor/controller and what are the states of various
peripherals” when the firmware is running on the target
hardware.
INTEGRATION OF HARDWARE AND FIRMWARE
• Integration of hardware and firmware deals with the
embedding of firmware into the target hardware board. It is
the process of ‘Embedding Intelligence’ to the product.
• The commonly used firmware embedding techniques for a
non-OS based embedded system are explained below.
• The non-OS based embedded systems store the firmware
either in the on chip processor/controller memory or off chip
memory (FLASH/NVRAM, etc.).
• A variety of techniques are used for embedding the firmware
into the target board. The commonly used firmware
embedding techniques for a non-OS based embedded system
are
 Out-of-Circuit Programming

Fig. 12.2 Interfacing of Device Programmer with PC

The sequence of operations for embedding the firmware with a programmer is
listed below.
1. Connect the programming device to the specified port of PC (USB/COM
port/parallel port)
2. Power up the device (Most of the programmers incorporate LED to indicate
Device power up. Ensure that the power indication LED is ON)
3. Execute the programming utility on the PC and ensure proper connectivity is
established between PC and programmer. In case of error, turn off device power
and try connecting it again
4. Unlock the ZIF socket by turning the lock pin
5. Insert the device to be programmed into the open socket as
per the insert diagram shown on the programmer
6. Lock the ZIF socket
7. Select the device name from the list of supported devices
8. Load the hex fi le which is to be embedded into the device
9. Program the device by ‘Program’ option of utility program
10. Wait till the completion of programming operation (Till busy
LED of programmer is off)
11. Ensure that programming is successful by checking the status
LED on the programmer (Usually ‘Green’ for success and ‘Red’
for error condition) or by noticing the feedback from the
utility program
12. Unlock the ZIF socket and take the device out of programmer
In System Programming (ISP)
• With ISP, programming is done ‘within the system’, meaning the
firmware is embedded into the target device without removing it
from the target board.
• The only pre-requisite is that the target device must have an ISP
support.
• Apart from the target board, PC, ISP cable and ISP utility, no other
additional hardware is required for ISP.
• Chips supporting ISP generates the necessary programming
signals internally, using the chip’s supply voltage.
• The target board can be interfaced to the utility program running
on PC through Serial Port/Parallel Port/USB.
• The communication between the target device and ISP utility will
be in a serial format.
• Once the ISP operations are completed, the device is re-
configured so that it will operate normally by applying a reset or a
re-power up.
In System Programming with SPI Protocol
• Devices with SPI In System Programming support contains a
built-in SPI interface and the on-chip EEPROM or FLASH
memory is programmed through this interface. The primary
I/O lines involved in SPI – In System Programming are listed
below.
• MOSI – Master Out Slave In
• MISO – Master In Slave Out
• SCK – System Clock
• RST – Reset of Target Device
• GND – Ground of Target Device
• PC acts as the master and target device acts as the slave in ISP.
• The program data is sent to the MOSI pin of target device and
the device acknowledgement is originated from the MISO pin
of the device. SCK pin acts as the clock for data transfer.
 The power up sequence for In System Programming for Atmel’s
AT89S series microcontroller family is listed below.
• 1. Apply supply voltage between VCC and GND pins of target chip.
• 2. Set RST pin to “HIGH” state.
• 3. If a crystal is not connected across pins XTAL1 and XTAL2, apply a 3 MHz to
24 MHz clock to XTAL1 pin and wait for at least 10 milliseconds.
• 4. Enable serial programming by sending the Programming Enable serial
instruction to pin MOSI/P1.5. The frequency of the shift clock supplied at pin
SCK/P1.7 needs to be less than the CPU clock at XTAL1 divided by 40.
• 5. The Code or Data array is programmed one byte at a time by supplying the
address and data together with the appropriate Write instruction. The selected
memory location is first erased before the new data is written. The write cycle is
self-timed and typically takes less than 2.5 ms at 5V.
• 6. Any memory location can be verified by using the Read instruction, which
returns the content at the selected address at serial output MISO/P1.6.
• 7. After successfully programming the device, set RST pin low or turn off the
chip power supply and turn it ON to commence the normal operation.
In Application Programming ( IAP)
• In Application Programming (IAP) is a technique used by the
firmware running on the target device for modifying a
selected portion of the code memory.
It is not a technique for first time embedding of user written
firmware. It modifies the program code memory under the
control of the embedded application.
• Updating calibration data, look-up tables, etc., which are
stored in code memory, are typical examples of IAP.
• The Boot ROM resident API instructions which perform
various functions such as programming, erasing, and reading
the Flash memory during ISP mode, are made available to the
end-user written firmware for IAP.
Use of Factory Programmed Chip
• It is possible to embed the firmware into the target
processor/controller memory at the time of chip fabrication
itself.
• Such chips are known as ‘ Factory programmed chips’. Once
the firmware design is over and the firmware achieved
operational stability, the firmware files can be sent to the
chip fabricator to embed it into the code memory.
• Factory programmed chips are convenient for mass
production applications and it greatly reduces the product
development time.
• It is not recommended to use factory programmed chips for
development purpose where the firmware undergoes
frequent changes.
• Factory programmed ICs are bit expensive.
Firmware Loading for Operating System Based Devices
• The OS based embedded systems are programmed using the In
System Programming (ISP) technique.
• OS based embedded systems contain a special piece of code called
‘Boot loader’ program which takes control of the OS and
application firmware embedding and copying of the OS image to
the RAM of the system for execution.
• The ‘ Boot loader’ for such embedded systems comes as pre-
loaded or it can be loaded to the memory using the various
interface supported like JTAG.
• The bootloader contains necessary driver initialisation
implementation for initializing the supported interfaces like
UART/I2C, TCP/IP etc.
• Bootloader implements menu options for selecting the source for
OS image to load (Typical menu item examples are
• Load from FLASH ROM, Load from Network, Load through UART
etc).
BOARD BRING UP
• The term bring up in embedded product design deals with
performing a series of validations in a controlled environment,
in a well-defined sequence which is specifically tailored for
the product.
• Bring up process usually includes basic hardware spot
checks/validations to make sure that the individual
components and buses/interconnects are operational – which
involves checking power, clocks, and basic functional
connectivity; basic firmware verification to make sure that the
processor is fetching the code and the firmware execution is
happening in the expected manner and then running
advanced validations such as memory validations, signal
integrity validation etc.
Components in embedded system
development environment (IDE)
• In embedded system development context, Integrated
Development Environment ( IDE) stands for an integrated
environment for developing and debugging the target
processor specific embedded firmware.
• IDE is a software package which bundles a ‘Text Editor (Source
Code Editor)’, ‘Cross-compiler (for cross platform
development and compiler for same platform development)’,
‘Linker’ and a ‘Debugger’.
• Some IDEs may provide interface to target board emulators,
Target processor’s/controller’s Flash memory programmer,
etc. and incorporate other software development utilities like
‘Version Control Tool’, ‘Help File for the Development
Language’, etc.
The Keil μVision IDE for 8051
• Keil μVision5 is a licensed IDE tool from Keil Software
(www.keil.com), an ARM company, for 8051 family microcontroller
based embedded firmware development.
• The IDE looks very similar to the Microsoft® Visual Studio IDE and it
contains various menu options, a project window showing files,
Register view and Functions Tab and an output window.
• To start a new project, go to the ‘Project’ tab on the menu, select
‘New μVision Project’ option.
• Give a name to your workspace in the ‘File Name’ section of the
‘Create New Project’ Pop-up dialog Box (Let it be ‘sample’).
• Choose the directory to save the project from the pop-up dialog.
• The default extension of a project work space file is .uvproj. On
clicking the ‘Save’ button of the ‘Create New Project’ pop-up dialog,
a device selection dialog as shown in Fig. 13.3 appears on the
screen.
1. Close existing project
2. Click on new project
3. Save it in a new folder
4. Select your device
5. Click on new file
6. Save it as hello.c file
7. Right click on project and click and add files to the source
8. Add the newly created file
9. To go to target options
10. Check on “create hexfile”,put the desired clock frequency
and click on
11. Build
Code Editing
• Code editing is one of the core features of an Integrated
Development Environment. It provide a text editor that is specifically
designed for writing code, which typically includes features such as
syntax highlighting, code completion, and refactoring tools. These
features help developers write code more efficiently and accurately,
reducing the chances of errors and making it easier to understand
and navigate the code.
• Syntax highlighting is a feature that automatically colors different
parts of the code according to their type, such as keywords,
variables, and comments. This makes it easier for developers to
identify different code elements, making it more readable and
understandable.
• Building and Debugging
• Building and debugging are essential Integrated Development
Environment features. It include tools for building and
debugging code, such as compilers and debuggers, which are
integrated into the IDE, making it easy for developers to
switch between writing and testing code.
• A compiler is a tool that converts the source code written by
the developer into machine code that a computer can
execute. This is an essential step in the software development
process, as it allows the developer to see how their code will
function when it is run on a target device or platform.
• A debugger is a tool that helps developers identify and fix
code errors. It allows developers to step through their code
line by line, inspect variables and memory and set
breakpoints to pause the execution of the code at specific
points. This allows developers to identify and fix an error's
root cause.
Code Analysis
• Code analysis is a feature that some Integrated Development
Environments (IDEs) include, which helps developers identify
potential errors or bugs in their code.
• One of the main advantages of using code analysis tools is
that they can help developers identify potential bugs and
errors in the code early on in the development process before
the code is even executed.
Conclusion
• An IDE is a powerful tool that makes writing, testing, and
debugging code easier. It provides a comprehensive set of
features to help developers work more efficiently and
improve the quality of their code. Integrated Development
Environment are available for different languages, platforms,
and development needs and can be customized to suit the
specific requirements of a project.
TYPES OF FILES GENERATED ON CROSS-COMPILATION
• 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
files. Almost all compilers provide the option to select
whatever intermediate files needs to be retained after cross-
compilation.
• The various files 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)
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 file, symbol tables, errors and warnings detected
during the cross-compilation process.
• The ‘list file’ generated contains the following sections.
• Page Header
• Command Line
• Source Code
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/cross assembling.
• Decompiler is the utility program for translating machine
codes into corresponding high level language instructions.
Decompiler performs the reverse operation of compiler/cross-
compiler.
• However disassemblers /decompilers generate a source code
which is somewhat matching to the original source code from
which the binary code is generated.
SIMULATORS, EMULATORS AND DEBUGGING
• Simulators and emulators are two important tools used in
embedded system development.
• The Integrated Development Environment (IDE) itself will be
providing simulator support and they help in debugging the
firmware for checking its required functionality.
• 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.
Simulators

• 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 behavior
Advantages of Simulator Based Debugging
• No Need for Original Target Board
• Simulate I/O Peripherals
• Simulates Abnormal Conditions
Limitations of Simulator based Debugging
• Deviation from Real Behavior
• Lack of Real Timeliness
• Emulators and Debuggers
Emulators and Debuggers
• 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.
• 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.
Types of firmware debugging

1. Incremental EEPROM Burning Technique

2. Inline Breakpoint Based Firmware Debugging

3. Monitor Program Based Firmware Debugging

4. In Circuit Emulator ( ICE) Based Firmware Debugging

5. On Chip Firmware Debugging (OCD)