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