Hi guys,
Just a quick one, can anyone confirm the behaviour of os_evt_get?
I'm wishing to share a buffer between two threads of different priority. When the thread of higher priority wishes to use the buffer, it sends a cease and desist event signal to the other thread.
I'm using Mutex locks but am concerned about the remote possibility of the cease and desist signal arriving in-between the lower priority thread waking up and locking the Mutex.
My thoughts were to lock the Mutex then re-check the event signaling, however the manual states:
"You can use the os_evt_get function to identify the event that caused the os_evt_wait_or function to complete."
Can I be sure that this function will always return the latest set of events, even if they've not yet been used to wake a thread?
Many thanks
Makes sense, hadn't occurred to me os_evt_wait_or() could be used with zero timeout.
FYI: Remember also that only 1 wait/delay RTOS routine can be used per task:
You cannot mix the wait method os_itv_wait and os_dly_wait (or any other delay wait method) in the same task."
http://www.keil.com/support/man/docs/rlarm/rlarm_os_dly_wait.htm
Although this statement does not specifically state os_evt_wait_or() it does have a generic disclaimer within the parenthesis (and os_evt_wait_or() DOES require some type of RTOS timer).
reading through this stuff I come to think of one REAL concern re comms: "You can NOT pause reading" In most cases you can pause sending. I have seen schemes that were guaranteed to allowpausing reading and all have failed
Erik
Thanks for the concern, but no problem, there's a hardware fifo of 16 bytes and receive has priority over send, the only task that's of a higher priority is triggered only when the fifo is empty and sleeps within O(1) time, which is considerably less than the time it takes to fill the FIFO.
Originally I was using DMA, which was so much simpler, however I had a need to detect parity bits and so had to avoid this ultimately :S
You can have multiple wait/delay routines in the task.
But os_itv_wait() consumes the only timing resource for the thread, disallowing any other delay methods for the task. But a task that doesn't use os_itv_set()/os_itv_wait() and have multiple os_dly_wait(), os_evt_wait_or(), ... without a problem. This is because os_dly_wait(), os_evt_wait_or(), ... only needs a timing resource during that specific function call. After call ends, the task-specific variables are available for reuse.
os_itv_set()/os_itv_wait() on the other hand makes permanent use of the task-specific delay variables, to make sure that the thread gets a wake up call again and again and again like a metronome. So when os_itv_wait() returns, the task variables are still used to keep track of when the task should wake up next time.