FreeRTOS mechanism for a synchronous message

Kernel
1

avivf wrote on Tuesday, June 26, 2018:

Definition:

“Synchronous message” means taskA sends a message to taskB, and waits for a reply from taskB. taskA is blocked while waiting for a reply, and upon receiving a reply continues from the where is stopped.
Reply message may have data in it.

Question:

  • Does FreeRTOS have any mechanism which implements the above definition for synchronous message?
  • Does anybody can help with it?

Thanks,
A.F

2

heinbali01 wrote on Tuesday, June 26, 2018:

Many ways to go here, my favourite would be :

TaskA passes it’s task handle (xTaskGetCurrentTaskHandle()) as part of the message to taskB. Messages can be passed in a queue.
TaskB handles the message, and when done it will wake up taskA.
When handled, it wakes up taskA by calling xTaskNotify().
TaskA will block in xTaskNotifyWait() until woken up.

3

richard_damon wrote on Tuesday, June 26, 2018:

As Hein impilies, FreeRTOS doesn’t have a primative for that operation, but you can build up a way to do it.

But, if you generalize the meaning of Task (and from the domain where that definition comes from, you can generally do so), you DO have a mechamism that matches this mode of operation, the function call. In my experience, often when I find the need for this sort of interaction between my tasks, I need to ask myself if TaskB has a REAL need to be a seperate task, or can it be just a function that I call, If part of the definition of TaskB is that it serializes its requests, that can be acheived with a mutex, which is a lot lighter weight than a full task.

If you are generating fully isolated Restricted Tasks with the MPU, then it is more likely that a seperate Task may be appropriate, and the request and reply sent via Queues (each task having its own Queue to process).