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

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

Viewers also liked

Similar to Software for embedded systems complete

Recently uploaded

Software for embedded systems complete