This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Wait for message and signal simultaneously using CMSIS RTX call


Wait for message and signal simultaneously using CMSIS RTX call

Hi All,

I am using CMSIS RTX V4.80.0. I need to wait for a message and a signal simultaneously in a single thread.

In the CMSIS RTOS API, I came across a function osWait() which meets my requirement. Is there any methods to achieve the same using the CMSIS RTX API.

In CMSIS RTX, both the osSignalWait and the osMessageGet functions return the same structure an osEvent which contains osStatus that contains the information for unblock(an osEventSignal or an osEventMessage). I tried using osSignalWait/osMessageGet function in the thread and identify whether message or signal is received using the return status. But for osSignalWait only osEventSignal is received as status and for osMessageGet only osEventMessage is received as status.

Is there any other alternatives to meet the requirement.

Thank you.

Parents
  • You could augment the communications between the two tasks in the following manner. Task A will wait forever for a signal. Task B can send a message to task A and then it would also send a "message" signal. Task A would wake with the "message" signal and then know to get a message. You could also tie in mail the same way. The other signals in Task A could be used just for signalling.

    We've implemented this with a health manager task which initially waits forever for any signals. If any task has an emergency, then it sends a 911 signal to the health manager which deals with the crisis. If a task wishes to schedule a regular checkup, then it sends a mail with the details and sets the "register" signal. The health manager gets the "register" signal, reads the mail and then schedules an appointment. The time to the appointment is now used in the signal timeout as opposed to waiting forever.

Reply
  • You could augment the communications between the two tasks in the following manner. Task A will wait forever for a signal. Task B can send a message to task A and then it would also send a "message" signal. Task A would wake with the "message" signal and then know to get a message. You could also tie in mail the same way. The other signals in Task A could be used just for signalling.

    We've implemented this with a health manager task which initially waits forever for any signals. If any task has an emergency, then it sends a 911 signal to the health manager which deals with the crisis. If a task wishes to schedule a regular checkup, then it sends a mail with the details and sets the "register" signal. The health manager gets the "register" signal, reads the mail and then schedules an appointment. The time to the appointment is now used in the signal timeout as opposed to waiting forever.

Children
No data