Software for embedded systems complete

Software for
Embedded Systems
Designed & Presented by,
Anand K

Embedded Software
 Software interacting with the physical world
o it takes time.
o it consumes power
o it does not terminate.
 Embedded software
o hidden in watches, mobile phones, iPods
o guided missiles, controls satellites
o used in automotive instruments.
 Varying requirements and hardware platform.

Requirements of Software for
Embedded Systems
 Reliability
 Human intervention not possible for error handling
 Cost- effectiveness
 Low power consumption
 Efficient use of memory.
 Performance requirement
 Timeliness

Features of Embedded Software
Timeliness
 Computation takes time
 Even Infinitely fast computer embedded software needs to deal with time
because the physical processes with which it interacts evolves over time.
 Concurrency
 Engage with the physical world where multiple things happen at once.
 Liveliness
 Program must not terminate or block waiting for events that will never
occur.
 Heterogeneity
 Different computational styles and implementation technologies
Interact with events occurring
 Reactivity
 React continuously to the environment at the speed of the environment.

Real Time
 The time between presentation of a set of inputs
to a system and the realization of the required
behavior including availability of the associated
outputs, is called the response time of the
system.
 A real-time system is a system that must satisfy
explicit bounded response time constraints or
risk severe consequences including failure
 Soft Real-time systems
Hard real-time systems

Software Quality Measurement
 Dynamic efficiency
 Number of CPU cycles required.
 Static efficiency
 RAM size
 Global variables and stack.
 ROM size
 Fixed constants and program code.
 Power consumption.
 Correctness.
 Easy to understand
 Easy to change
 Flexibility and maintainability

Developing Software
 Determine requirements
 Product functionality
 Design the System Architecture
 Select the Operating System(if any)
 Choose the development platform
 Code the application
 Optimize the code according to the requirement.
 Verify the software on the host system
 Execution within a simulator environment.
 Execution within an emulator environment.
 Verify the software on the target system.

Make Process
Compiling
o Parsing, Semantic Analysis and Object Code Generation
o Processor specific characteristics to be exploited for
efficient code generation
o Cross-compiler or cross-assembler
 Run on host to produce code for target.
Linking
o Merge sections from multiple object files
o Unresolved reference to symbols replaced by reference to actual
variables or function calls
o A special object file that contains compiled start-up code also
included
o Start-up code:
 Small block assembly language code that prepares the way for the
execution of the code

Startup code
o Start-up code usually consists of following actions in
sequence.
 Disable all interrupts.
 Copy any predefined data from ROM to RAM.
 Zero the uninitialized data area.
 Allocate space and initialize the stack.
 Initialize processor’s stack pointer
 Create and initialize the heap
 Enable Interrupts.
 Call main
o Programmer may need to write his own start-up
code and link(if necessary)
Img.jpg

Memory Allocation
o RAM Memory
 Global variables.
 Heap
 Stack
• Local variables
• Return addresses
• Temporary data.
o Content changes at run-time

Memory Allocation
o ROM memory
 Machine Codes
 Fixed constants
o If both ROM and EPROM
 partitioning depending upon the requirements of the
design.
 Configuration data
 Flash
 Data store(RAM buffer)
o Slower compared to RAM

Software for embedded systems complete

Desirable HLL features
o Versatile parameter passing
 Call by value
 Copied into stack at considerable execution time
 Large data structures never passed by value.
 Call by reference
 Indirect instructions used; time for execution of procedure
more.

Desirable features
 Global variables Vs parameter lists
 References to global variables faster- direct
addressing
 Parameters make interfaces clearly defined
 Parameters can increase interrupt latency.
• interrupts disabled during parameter passing

C for Embedded Systems
o The practices that characterize Embedded C
development:
▫ In-line Assembly language
▫ Device knowledge
▫ #pragma directive
▫ Endianness
▫ Mechanical knowledge
▫ knowledge of specific device/peripheral operation
o Processor dependent objects like characters, bytes, bits
and addresses can be handled directly
 to be manipulated to control interrupt controllers, CPU registers etc.
o The @ operator associates port register with identifier in
#pragma port statements
o C provides special variable types like register, volatile,
static, and constant

C for Embedded Systems
o Storage modifiers
 register – variables to be frequently used, compiler
places in a register.
 static – private communication in modules. Static
variables initialized only once, visible within a single
compilation unit.
 extern – extern variables are meant to be allocated
memory only once across several modules.
 auto – by default all local variables are declared as ‘auto’
o Data type Identifiers
 const
• Allocated in ROM or any other NV memory
 volatile – variables whose values may change outside of
the executing software.

Memory management in C
o Static Allocation
 Global variables, variables with static qualifier
 Memory allocated during compile or link time
 Advantage of modularising the data within a
program design.
o Automatic Allocation
 At run time in stack for variables defined in every
function
 Compiler provides support for allocation and access
to these variables

Dynamic Allocation
 Dynamic allocation
 Allocation of memory at run-time on demand
 Allocation and de-allocation under program control.
 Allocated from a large pool of unused memory area
called Heap
 Memory accessed indirectly, via pointer reference

Dynamic Allocation
 Memory space in the heap is not always allocated
and deallocated from one end (like the stack).
If a block of sufficient size is found then it is
allocated and the pointer returned.
If no block is found to satisfy the request then a
heap overflow error is returned.
 Allocation in heap area
 Memory in heap as chunk of unit sizes 16,32, etc.
 Memory is actually acquired or released in the units in
which the memory is divided.
o wastage of memory
o Internal fragmentation

Allocation of Stack and Heap Space
for the Declaration of Array A

Heap Management
 A map of space allocated is kept so that, when a
block is deleted, the correct amount of space is
returned to the free list.
 Smaller unit size minimizes wastage but
increases memory requirement for maintaining
data about the allocated blocks
 free() returns unit to heap
o using free() more than once on the same pointer can
result in inconsistency

Difficulties
 Memory leak
 memory allocated, not freed
 not available subsequently
 “Run forever” can result in system failure due to
cumulative effect of small memory leak
 Dangling pointers

Software for embedded systems complete

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to Software for embedded systems complete (20)

Recently uploaded (20)

Software for embedded systems complete