1 / 18

Software for Embedded Systems

Software for Embedded Systems . Lecture 2 on Implementation. Roster. Visibility Synchronous invocation (done) Asynchronous communication. Asynchronous Communication. Client object communicates with the server object by making a service request The client object continues execution

elin
Télécharger la présentation

Software for Embedded Systems

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software for Embedded Systems Lecture 2 on Implementation

  2. Roster • Visibility • Synchronous invocation (done) • Asynchronous communication

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

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

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

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

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

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

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

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

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

  12. Code listing for case 2 void G4 () // server process { int i=(msg.pz)->*(msg.pmfz)(msg); // calling through pointers the appropriate // object and method }

  13. Memory and performance optimization • Use sync calls instead of async • Instead of deleting and recreating message buffers, reuse them • An async control logic could be converted to more effective OS routines like signals and semaphores • If you instantiate many objects from one class dynamically, consider writing a specific allocation mechanism • Use references to objects rather than copying them. (input and output of functions)

  14. Memory and performance optimization • Dynamic objects and dynamic binding (implemented by virtual functions) increase memory consumption thereby affecting performance • But use of virtual functions increases the flexibility of the program • So when you wish to use virtual functions, compare the whole solution with these aspects rather than aspect by aspect • Programmer must be aware of padding inserted by the compiler inside structures • Each instance of a class has a hidden pointer to the virtual table • Each non static member function has a pointer to the object itself “this”, passed in the parameter list

  15. Classes with singular objects • Many classes in an embedded system typically have only one instance • The singleton design pattern deals with this in a very flexible way • Another variation could be to declare all the data members and member functions as static thereby using the class itself instead of the single instance

  16. Immutable data members and objects • Many classes in embedded systems declare immutable data using the “const” keyword only to prevent direct assignment to that variable, but not to control storage. • We could place such immutable data members and objects in the ROM rather than the RAM • So one solution could be to partition the class into three parts • A part that contains data members and objects in RAM to be initialized via constructor calls etc.. • A part that contains the data members and Objects in Ram to be initialized not via the constructor but from an initialization data image in ROM at startup • A part that contains immutable data members and objects. This could be achieved using an aggregator class and instantiating it and can be placed in ROM or other special memory

  17. Two more interesting topics • Please refer the notes kept in S9 for these two topics. • Synchronization • Implementing state charts • The entire material for these two implementation lectures have been referred from “Object Oriented Technology for real time systems” by Maher Awad et al • The photocopy of the 8th chapter (Design to implementation) is kept in S9 for further reading

  18. End of Lecture • Thank You!

More Related