Software for Embedded Systems

1. Software for Embedded Systems Lecture 1 on Implementation

2. Roster • Why are we discussing Implementation? • Choice of language • Development Environment • Member Access Control • Visibility • Synchronous invocation • Asynchronous communication

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

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

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

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

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

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

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

10. Visibility: Synchronous Invocation fs() (Case 1) S::s • 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) X::x fy() (Case 3) Y::y fz() (Case4) Z::z

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

12. Sample code // assuming classes X,Y, Z and S are declared and defined // also objects x and y are created class D { public: D (Y&); Y& mry; // case 3 S s; // case 1 void f1(X&); // case 2 Z* mpz; // case 4 }

13. 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 }

14. 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:

15. 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 msgx(..) X::objx D :: objd msgy(...) Y::objy

16. Code listing for case 1 Class Msg { public: enum MsgId{ToX, ToY}; void send (MsgId, toWho); private: MsgId=id; // other message structure } void send(MsgId toWho) { id=toWho; // send the message using osSend(....) to server process }

17. Code listing for case 1 Msg msgx, msgy; void D:: fd() { msgx.send(Msg ::ToX); msgy.send(Msg ::ToY); }

18. Code listing for case 1 Void G2() // server process function { for(;;) // waiting for messages from osRecieve(...) { switch(msg->id) { case Msg::ToX: objx.fx(msg); break; case Msg::ToY: objy.fy(msg); break; } } }

19. 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 msgx(ptrs) Z::objzb F :: objf Z::objza msgy(ptrs)

20. Code listing for case 2 Class Z { public: int fz1(Msg&); int fz2(Msg&); private: MsgId=id; // other message structure }; Z objza, objzb;

21. Code listing for case 2 Class Msg {public: Z *pz; int (Z:: *pmfz) (Msg&); // pointer to member function // other contents of message structure } Msg msg;

22. Code listing for case 2 void F:: ff() { msg.pz=&objza; msg.pmfz=&Z::fz2; } void F:: fe() { msg.pz=&objzb; msg.pmfz=&Z::fz1; }

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 }

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