software for embedded systems n.
Skip this Video
Loading SlideShow in 5 Seconds..
Software for Embedded Systems PowerPoint Presentation
Download Presentation
Software for Embedded Systems

Loading in 2 Seconds...

play fullscreen
1 / 24

Software for Embedded Systems - PowerPoint PPT Presentation

  • Uploaded on

Software for Embedded Systems . Lecture 1 on Implementation. Roster. Why are we discussing Implementation? Choice of language Development Environment Member Access Control Visibility Synchronous invocation Asynchronous communication. Why are we discussing Implementation?.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Software for Embedded Systems' - tryna

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software for embedded systems

Software for Embedded Systems

Lecture 1 on Implementation

  • Why are we discussing Implementation?
  • Choice of language
  • Development Environment
  • Member Access Control
  • Visibility
    • Synchronous invocation
    • Asynchronous communication
why are we discussing implementation
Why are we discussing Implementation?
  • Its always the case that we draw a design and while implementing the design we just ignore the design almost completely
  • In a non-embedded and non-real time probably we can tolerate this aspect
  • In embedded real time systems, the design to implementation mapping rules system success or failure
  • The implementation will conform to proper design thus making it perform the best when constrained by memory and processing power and yet deliver on time (real time)
  • This property makes it very important to dedicate one or two lectures on the special features of implementation.
choice of language
Choice of Language
  • Till almost the last decade, assembly language has been the market leader for implementation of embedded real time systems.
  • Thanks to the advent of compilers that optimize code for memory and performance, we can now code in a high-level language (C, C++, Java etc...)
  • The Choice of language for realizing the design depends on lots of factors like the organization’s choice, performance issues, language features or support for specific utilities.
development environment
Development Environment
  • Usually software for embedded systems is implemented using two compilers
    • A host compiler for simulation on the host
    • A cross-compiler to compile the code for the target system
  • In practice several compilers and assemblers might be needed, for example:
    • When using different hosts (PC, sun etc...) or updating form one host to another
    • If some debugging tools need or assume a specific compiler
    • Etc...
development environments
Development Environments
  • The best solution is to use an IDE as possible
  • It gives a one stop place for developing, simulating and testing an embedded application
member access control
Member Access control
  • Most of the member functions that were identified in the design phase are intended for the users of the class (known as interface functions)
  • These interface functions access other data members and member functions that must not be directly accessible to the users of this class
  • We can control the access to data members and member functions by using “access modifiers” like public, private, friend etc...
  • Only interface functions will be public
  • In the design phase objects were freely interacting with each other synchronously or asynchronously
  • This was based on the assumption that somehow the objects knew each other.
  • The objects could use symbolic or direct references to communicate
  • A client has to interact with the server by using the runtime address of the server process
visibility synchronous invocation
Visibility: Synchronous Invocation
  • Client object calls a function in the server object
  • Client continues its operations only after the function in the server returns
  • The client can interact with the server in a number of ways
  • One simple way might be that the client object uses a reference to a global server object.
visibility synchronous invocation1
Visibility: Synchronous Invocation

fs() (Case 1)


  • Case 1: the class from where the client is instantiated aggregates the server object (s). Here the client object has a direct reference to the server object.

D :: d

fx() (Case 2)


fy() (Case 3)


fz() (Case4)


visibility synchronous invocation2
Visibility: Synchronous Invocation
  • Case 2: The reference might be passed to the client object as a parameter of a function
  • Case 3: The client object might have its own ref. of the server object and this might be set in the constructor of the client object
  • Case 4: The client object creates the server object , then it gets a reference to it from the creation process.
sample code
Sample code

// assuming classes X,Y, Z and S are declared and defined

// also objects x and y are created

class D



D (Y&);

Y& mry; // case 3

S s; // case 1

void f1(X&); // case 2

Z* mpz; // case 4


sample code contd
Sample code contd...

D :: D(Y& y): mry(y) { } // Case 3

void D:f1(X& x) { // Case 2

x.fx(); // Case 2

mry.fy(); // Case 3 (already initialized reference to

// server object is used here)

Z* mpz= new Z;

mpz->fz(); // Case 4


asynchronous communication
Asynchronous Communication
  • Client object communicates with the server object by making a service request
  • The client object continues execution
  • Async communication is dependent on the services of the underlying OS
  • The client object has to request the Os to send the message to the proper server object in the target process. There are three ways how this can be achieved:
asynchronous communication1
Asynchronous Communication

1) The target process has different message queues and each one leads to a member function class of one server object

2) The target process has one message queue, but the message itself is used to select the server object and the member function to be called



D :: objd



code listing for case 1
Code listing for case 1

Class Msg



enum MsgId{ToX, ToY};

void send (MsgId, toWho);



// other message structure


void send(MsgId toWho)



// send the message using osSend(....) to server process


code listing for case 11
Code listing for case 1

Msg msgx, msgy;

void D:: fd()


msgx.send(Msg ::ToX);

msgy.send(Msg ::ToY);


code listing for case 12
Code listing for case 1

Void G2() // server process function


for(;;) // waiting for messages from osRecieve(...)




case Msg::ToX:



case Msg::ToY:






asynchronous communication2
Asynchronous Communication
  • The address of the server object and member function are included in the message itself. Here the object group process on the server becomes generic. It can simply execute the function at a given pointer.

E :: obje



F :: objf



code listing for case 2
Code listing for case 2

Class Z



int fz1(Msg&);

int fz2(Msg&);



// other message structure


Z objza, objzb;

code listing for case 21
Code listing for case 2

Class Msg


Z *pz;

int (Z:: *pmfz) (Msg&);

// pointer to member function

// other contents of message structure


Msg msg;

code listing for case 22
Code listing for case 2

void F:: ff()





void F:: fe()





code listing for case 23
Code listing for case 2

void G4 () // server process


int i=(msg.pz)->*(msg.pmfz)(msg);

// calling through pointers the appropriate

// object and method


end of lecture
End of Lecture
  • We will deal with synchronization, implementing state charts etc in the next lecture