ARM MICROCONTROLLER & EMBEDDED

SYSTEMS (17EC62)

Embedded System Design

Concepts (Lecture-4)
ARM MICROCONTROLLER & EMBEDDED
SYSTEMS (17EC62)

Embedded System Design

Concepts (Lecture-4)
Embedded Firmware Design and
Development.
 Introduction to Embedded Firmware Design
• The embedded firmware is responsible for controlling the various
peripherals of the embedded hardware and generating response in
accordance with the functional requirements.
• Firmware is considered as the master brain of the embedded system.

• Imparting intelligence to an Embedded system is a one time process and it

can happen at any stage.
• It can be immediately after the fabrication of the embedded hardware or at
a later stage.

• For most of the embedded products, the embedded firmware is stored at a

permanent memory (ROM) and they are non-alterable by end users.
• Some of the embedded products used in the Control and Instrumentation
domain are adaptive.
 Introduction to Embedded Firmware Design
(continued)
• Designing embedded firmware requires understanding of the particular
embedded product hardware, like various component interfacing, memory
map details, I/O port details, configuration and register details of various
hardware chips used and some programming language.

• Embedded firmware development process starts with the conversion of the

firmware requirements into a program model using modelling tools.

• Once the program model is created, the next step is the implementation of
the tasks and actions by capturing the model using a language which is

understandable by the target processor/controller.

 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:

• Super Loop Based Approach (Conventional Procedural Based

Design)

• Embedded Operating System (OS) Based Approach

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

• In a multiple task based system, each task is executed in serial in this

approach.
 Super Loop Based Approach (continued)

• The firmware execution flow 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
 Super Loop Based Approach (continued)

• 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
void main()
{
Configuratio
ns();
Initializati
ons();
while(1)
{
Task 1();
Task 2();
n();
}
}
 Super Loop Based Approach (continued)

• Almost all tasks in embedded applications are non-ending and are

repeated infinitely throughout the operation.
• This repetition is achieved by using an infinite loop.

• Hence the name 'Super loop based approach'.

• 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.
• 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.
 Super Loop Based Approach (continued)

• Advantage of Super Loop Based Approach:

• It doesn't require an operating system

• There is no need for scheduling which task is to be executed and

assigning priority to each task.
• 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.
 Super Loop Based Approach (continued)

• Applications of Super Loop Based Approach:

• 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.
• It should strictly follow a specified sequence and the combination of
these series of tasks constitutes a single task-namely data read/write.
 Super Loop Based Approach (continued)

• 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
 Super Loop Based Approach (continued)
• Drawbacks of Super Loop Based Approach:
• Any failure in any part of a single task will affect the total system.

• If the program hangs up at some point while executing a task, it will remain there forever and
ultimately the product stops functioning.
• Watch Dog Timers (WDTs) can be used to overcome this, but this, in turn, may cause additional
hardware cost and firmware overheads.

• 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, 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.
• Interrupts can be used for external events requiring real time attention.
 Embedded Operating System (OS) Based
Approach

• The Embedded 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.
 Embedded Operating System (OS) Based
Approach (continued)
• 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 XP
Embedded.
• Examples of Embedded products using Microsoft Windows XP OS are Personal Digital
Assistants (PDAs), Hand held devices/Portable devices and Point of Sale (POS) terminals.
• 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 .
 Embedded Operating System (OS) Based
Approach (continued)
• Real Time Operating System (RTOS) based design approach is employed in embedded
products demanding Real-time response.
• RTOS responds 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.
• ’Windows CE’, ’pSOS’, ’VxWorks’, ’ThreadX’, ’MicroC/OS-II', ’Embedded Linux’,

’Symbian', etc. are examples of RTOS employed in embedded product development.

• Mobile phones, PDAs (Based on Windows CE/Windows Mobile Platforms), handheld devices,
etc. are examples of 'Embedded Products' based on RTOS.
• Most of the mobile phones are built around the popular RTOS 'Symbian'. (sic)
 Embedded Firmware Development
Languages

• For embedded firmware development, 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' is the human readable notation of 'machine language'

• 'Machine language' is a processor understandable language.

• 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 Based Development
• 'Assembly language' is the human readable notation of 'machine language'

• 'Machine language' is a processor understandable language.

• 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 Based Development
(continued)
• Assembly Language program was the most common type of
programming adopted in the beginning of software revolution.
• Even today also almost all low level, system related, programming is
carried out using assembly language.
• 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.
 Assembly Language Based Development
(continued)

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

MOV A, #30
Here MOV A is the Opcode and #30 is the 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
 Assembly Language Based Development
(continued)

• Each line of an assembly language program is split into four fields

as given below

LABEL OPCODE OPERAND COMMENTS

• A 'LABEL' is an optional identifier used extensively in programs to

reduce the reliance on programmers for remembering where data or
code is located.

• For example

DELAY: MOV R0,#255 ;Load Register R0 with 255

'-, ' '-.-' 1—.—' 1-,-'

LABEL OPCODE OPERAND COMMENT

 Assembly Language Based Development
(continued)
• The Assembly language program written in assembly code is saved as .asm (Assembly
file) file or an .src (source) file (also .s file).
• Any text editor like 'Notepad' or 'WordPad' from Microsoft or the text editor provided by
an Integrated Development (IDE) tool can be used for writing the assembly instructions.
• Similar to 'C' and other high level language programming, we can have multiple source
files called modules in assembly language programming.
• Each module is represented by an '.asm' or '.src' file.

• This approach is known as 'Modular Programming'.

• Modular programming is employed when the program is too complex or too big.

• In 'Modular Programming', the entire code is divided into submodules and each module is
made re-usable.
• Modular Programs are usually easy to code, debug and alter.
 Assembly Language Based Development
(continued)

Assembly language to
machine language
conversion process

Machine Code
(Hex File)
 Assembly Language Based Development
(continued)

• 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.
• 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 file/machine language are illustrated in the
figure.
 Assembly Language Based Development
(continued)
• 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/locater to assign absolute address for this module.
• Each module can share variables and subroutines (functions) among them.

• Keyword 'PUBLIC' and 'EXTRN' are used while accessing shared variables and
subroutines.
 Assembly Language Based Development
(continued)

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

• Library files are generated with extension '. lib'.

• When the linker processes a library, only those object modules in the library
that are necessary to create the program are used.
• Library file is some kind of source code hiding technique.
• For example, 'LIB51' from Keil Software is an example for a library creator and
it is used for creating library files for A51 Assembler/C51 Compiler for 8051
specific controller.
 Assembly Language Based Development
(continued)
• Linker and Locator
• Linker and Locater is another software utility responsible for "linking the various object
modules in a multi-module 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.
• An absolute object file or module does not contain any re-locatable code or data.
• All code and data reside at fixed memory locations.

• The absolute object file is used for creating hex files for dumping into the code memory of
the processor/controller.
• 'BL51' from Keil Software is an example for a Linker & Locater for A51 Assembler/C51
Compiler for 8051 specific controller.
 Assembly Language Based Development
(continued)
• 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.
• HEX files are ASCII files that contain a hexadecimal representation of target
application.
• Hex file is created from the final 'Absolute Object File' using the Object to Hex File
Converter utility.
• 'OH51' from Keil software is an example for Object to Hex File Converter utility
for A51 Assembler/C51 Compiler for 8051 specific controller.
 Advantages of Assembly Language Based
Development

• Efficient Code Memory and Data Memory Usage (Memory Optimisation)

• 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.
• 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.
 Advantages of Assembly Language Based
Development (continued)
• 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 'hawkers' 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 .
 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.
• 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'.
 Drawbacks of Assembly Language Based
Development (continued)
• Developer Dependency
• Unlike high level languages, there is no common written rule for developing assembly
language based applications.
• 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.
 Drawbacks of Assembly Language Based
Development (continued)

• 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 ARM11 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.
 High Level Language Based Development

• Any high level language (like C, C++ or Java) with a supported crosscompiler
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.
• 'C' is 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.
 High Level Language Based Development
(continued)

• 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 file is
done by a cross-compiler.
• 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 file/machine language is illustrated in the
figure.
 High Level Language Based Development
(continued)

High level language to

machine language
conversion process

Machine Code
(Hex File)
 High Level Language Based Development
(continued)
• The program written in any of the high level languages 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 can be used for writing the
program.
• Most of the high level languages support modular programming approach and
hence we can have multiple source files called modules written in corresponding
high level language.
• The source files corresponding to each module is represented by a file with
corresponding language extension.
 High Level Language Based Development
(continued)

• Translation of high level source code to executable object code is done by a

cross-compiler.
• Each high level language should have a cross-compiler for converting the high
level source code into the target processor machine code.
• C51 Cross-compiler from Keil software is an example for Cross-compiler used
for 'C' language for the 8051 family of microcontroller.
• Conversion of each module's source code to corresponding object file 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.
 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.
• 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.
 Advantages of High Level Language
Based Development (continued)

• 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.
• 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.
 Advantages of High Level Language
Based Development (continued)
• 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
recompiling the application for the required target processor/controller, provided, the
cross-compiler has support for the processor/controller selected.
• This makes applications written in high level language highly portable.
• Little effort may be required in the existing code to replace the target processor
specific files with new header files, register definitions with new ones, etc.
• This is the major flexibility offered by high level language based design.
 Limitations of High Level Language Based
Development
• Poor Optimization by Cross-Compilers
• 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
 Limitations of High Level Language Based
Development (continued)

• Not Suitable for Low Level Hardware

• 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).
• High Investment Cost

• 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.
 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:
• Mixing Assembly Language with High Level Language
• Mixing High Level Language with Assembly Language
• Inline Assembly programming
 Mixing Assembly Language with High Level
Language
• 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.
• 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 Assembly Language with High
Level Language (continued)

• Mixing 'C' and Assembly is little complicated.

• 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.
 Mixing Assembly Language with High
Level Language (continued)
• Consider an example Keil C51 cross compiler for 8051 controller.
• The steps for mixing assembly code with 'C' are:
• Write a simple function in C that passes parameters and returns values the way
you want your assembly routine to.
• Use the SRC directive (#PRAGMA SRC at the top of the file) so that the C
compiler generates an .SRC file instead of an .OBJ file.
• 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.
• Rename the .SRC file to .A51 file.
• 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 Assembly Language with High
Level Language (continued)

• As an example consider the following sample code:

#pragma SRC
unsigned char my_assembly_func (unsigned int
argument)
{
} return (argument + 1); // Insert dummy lines to access all args and
// retvals
• This C function on cross compilation generates the following
assembly SRC file.
• The special compiler directive SRC generates the Assembly code
corresponding to the 'C' function and each lines of the source code is
converted to the corresponding Assembly instruction.
 Mixing High Level Language 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, 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.
• For example, Built in Graphics library functions and String operations supported by
’C'.
 Mixing High Level Language with
Assembly Language (continued)

• Most often the functions written in ’C’ use parameter passing to the
function and returns value/s to the calling functions.
• Parameters are passed to the function and values are returned from the
function using CPU registers, stack memory and fixed memory.
• Its implementation is cross compiler dependent and it varies across
cross compilers.
 Mixing High Level Language with
Assembly Language (continued)

• Consider an example for the Keil C51 cross compiler.

• C51 allows passing of a maximum of three arguments through general purpose
registers R2 to R7.
• If the three arguments are char variables, they are passed to the function using
registers R7, R6 and R5, respectively.
• If the parameters are int values, they are passed using register pairs (R7, R6),
(R5, R4) and (R3, R2).
• If the number of arguments is greater than three, the first three arguments are
passed through registers and rest is passed through fixed memory locations.
 Mixing High Level Language with
Assembly Language (continued)
Return values are usually passed through general purpose registers.

R7 is used for returning char value and register pair (R7, R6) is
used for returning int value.
The 'C' subroutine can be invoked from the assembly program
using the subroutine call Assembly instruction.
For example
LCALL Cfunction

where Cfunction is a function written in 'C'

• The prefix _ informs the cross compiler that the parameters
to the function are passed through registers.
• If the function is invoked without the _ prefix, it is
understood that the parameters are passed through fixed
memory locations.
 Inline Assembly Programming

• Inline assembly is a 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.
• 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.
• For example:

#pragma asm MOV A, #13H #pragma endasm

 Programming in Embedded C
• Whenever the conventional 'C' Language and its extensions are used for programming
embedded systems, it is referred as 1Embedded C programming.
• Programming in 'Embedded C' is quite different from conventional Desktop application
development using 'C' language for a particular OS platform.
• Desktop computers contain working memory in the range of Megabytes (Nowadays Giga
bytes) and storage memory in the range of Giga bytes.
• For a desktop application developer, the resources available are surplus in quantity and s/he can
be very lavish in the usage of RAM and ROM and no restrictions are imposed at all.
• This is not the case for embedded application developers.
• Almost all embedded systems are limited in both storage and working memory resources.
• Embedded application developers should be aware of this fact and should develop applications
in the best possible way which optimises the code memory and working memory usage as well
as performance.
• In other words, the hands of an embedded application developer are always tied up in the
memory usage context.
 'C' vs. 'Embedded C'
• 'C is a well structured, well defined and • Embedded 'C' can be considered as a subset of
standardised general purpose programming conventional 'C' language.
language with extensive bit manipulation
support. • Embedded 'C' supports all 'C' instructions and
incorporates a few target processor specific
functions/instructions.
• 'C offers a combination of the features of
high level language and assembly and helps • The standard ANSI 'C' library implementation
in hardware access programming (system is always tailored to the target
level programming) as well as business processor/controller library files in Embedded
package developments (Application 'C.
developments like pay roll systems, banking
applications, etc). • The implementation of target
processor/controller specific
• The conventional 'C language follows ANSI functions/instructions depends upon the
standard and it incorporates various library processor/controller as well as the supported
files for different operating systems. cross-compiler for the particular Embedded 'C'
language.
• A platform (operating system) specific
application, known as, compiler is used for • A software program called 'Cross-compiler' is
the conversion of programs written in 'C1 to used for the conversion of programs written in
the target processor (on which the OS is Embedded 'C' to target processor/controller
running) specific binary files. specific instructions (machine language).
• Hence it is a platform specific development.
 Compiler vs. Cross-Compiler
• Compiler is a software tool that converts a • Cross-compilers are the software tools used in
source code written in a high level language on crossplatform development applications.
top of a particular operating system running on a • In cross-platform development, the compiler
running on a particular target processor/OS
specific target processor architecture (e.g. Intel
converts the source code to machine code for a
x86/Pentium). target processor whose architecture and
instruction set is different from the processor on
• Here the operating system, the compiler program which the compiler is running or for an
and the application making use of the source operating system which is different from the
code run on the same target processor. current development environment OS.

• Embedded system development is a typical

• The source code is converted to the target
example for cross-platform development.
processor specific machine instructions. • Embedded firmware is developed on a machine
with Intel/AMD or any other target processors
• The development is platform specific (OS as and the same is converted into machine code for
well as target processor on which the OS is any other target processor architecture (e.g.
8051, PIC, ARM etc).
running).
• Keil C51 is an example for cross-compiler.
• Compilers are generally termed as 'Native
Compilers'. • In embedded firmware application, whenever we
• A native compiler generates machine code for the
use the term 'Compiler' it normally refers to the
same machine (processor) on which it is
crosscompiler.
running.
Compiler vs. Cross-Compiler
Thank You