1

I have two classes, commandparser and executor, in this design commandparser parses the command and calls the executecommand function of executor class,the executecommand returns immediately after setting few parameters, the command execution happens in ISR functions,after executing the command the results has to send back the parser via callback, the pseudo code:

class executor{
public:
    void executeCommand(void){
    //start Command execution, the command Execution takes place in some ISR functions.
}
private:
   void command1(void){
   //Call commandparser's sendresponse function.
}
void command2(void){
   //Call commandparser's sendresponse function.
}
};

class commandparser{
public:
    void sendresponse(int a){
    //....
    //...
}
void run(){
   b.executeCommand();
}
private:
    executor b;
};


int main(){
   commandparser cmdparser;
   cmdparser.run();
}

Is this possible to achieve?(The solution should not contain virtual functions as the I am working on embedded target where the RTTI are not allowed).

Sivaram
  • 155
  • 1
  • 8
  • Pass a pointer to cmdparser as argument to executeCommand – armagedescu Aug 17 '22 at 17:57
  • Sound like you need asynchronous calls to run executeCommand: Have a look at std::async, std::future, lambda functions. And quite likely std::mutex & std::scoped_lock. std::function may also be useful to register your callback – Pepijn Kramer Aug 17 '22 at 18:13
  • @whozcraig corrected the mistake in code. It should be clear now. – Sivaram Aug 18 '22 at 00:43
  • @Pepjin Kramer since it runs on microcontroller target, std::async, future and other things listed are not feasible. – Sivaram Aug 18 '22 at 00:46
  • cmdparser.run() only returns, when the command is finished and the response transmitted? Are you asking about the general concept? Yes, it works and is often done. Are you asking about, whether it will actually work with ISR, then we need information about the target platform, the (RT)OS, and so on. Are you asking about nice C++ (compared to plain C functions) call syntax and object model (you were mentioning virtual member functions), then we would need more information about different commands, should they be done by different objects or different classes or only different member functions. – Sebastian Aug 18 '22 at 06:02
  • @Sebastian, The Question is about how to call commandparser's sendresponse function from executor where executor doesn't hold the object of commandparser, whereas the command parser holds object of executor. It's is not about any specific RTOS or ISR's. In the design some of commands will take some time to execute(in ISR context) and they have to send their response via the event handler, where the sendresponse function is that handler. – Sivaram Aug 18 '22 at 06:58
  • So as the commands take time, the commandparser is not waiting for an answer before returning to its caller, or is it? The callback is executed either by a) the ISR (probably not) b) another thread (if available at all) c) when the executor gets control, e.g. when someone is transmitting another command (perhaps?) or during a regularly called housekeeping function (by timer). As sendresponse is not a static function, the executor needs a pointer or reference to the commandparser instance, either set to it generally instance-wide or given together with each command call. – Sebastian Aug 18 '22 at 07:26
  • As you wrote about not wanting virtual functions, I assume the commandparser has an inheritance hierarchy, where each derived class wants to do different functionality in sendresponse. You can manually create a virtual-function-like functionality: Have the base class of commandparser store a derived-class-id, as member variable and call the respective derived sendresponse from the base sendresponse. – Sebastian Aug 18 '22 at 07:34
  • Would it be an option to use virtual functions without RTTI, which is possible (this way around): https://stackoverflow.com/questions/34353751/no-rtti-but-still-virtual-methods – Sebastian Aug 18 '22 at 07:36
  • @Sebastian, The design is the command parser gets commands via RTOS message queue, it validates the message and calls the executor to run, the command is run motor for some x encoder counts in this duration, now the run functions sets the trajectory parameters and starts the timer, once the move is completed don't want to send rtos message from ISR, hence the executor post an event to the parser, where the result is stored and sent to message queue in a house keeping call of command parser. the cmd parser will have to manage more than one executor. – Sivaram Aug 18 '22 at 08:31
  • If there is one command parser, the executors can call a static function of the command parser, which stores the response in a thread/interrupt-safe way. You can send a command index with the command and it is sent back with the response and is the index to a table in the command parser, which stores active commands. – Sebastian Aug 18 '22 at 12:04

0 Answers0