Some standard features of events are listed below:
More than one task can block waiting for the same event, and the RTOS will unblock all of them (and run them in priority order) when the event occurs. For example, if the radio task needs to start warming up the radio when the user pulls the trigger, then that task can also wait on the trigger-pull event.
RTOSs typically form groups of events, and tasks can wait for any subset of events within the group. For example, an event indicating that the user pressed a key on the scanner keypad might be in the same group with the trigger-pull event. If the radio task needs to wake up both for a key and for the trigger, it can do that. The scanning task will wake up only for the trigger event.
Different RTOSs deal in different ways with the issue of resetting an event after it has occurred and tasks that were waiting for it have been unblocked. Some RTOSs reset events automatically; others require that your task software do this. It is important to reset events: if the trigger-pull event is not reset, for example, then tasks that need to wait for that event to be set will never again wait.
A Brief Comparison of the Methods for Intertask Communication
We have discussed using queues, pipes, mailboxes, semaphores, and events for communication between two tasks or between an interrupt routine and a task. Here is a comparison of these methods:
Semaphores are usually the fastest and simplest methods. However, not much information can pass through a semaphore, which passes just a 1-bit message saying that it has been released.
Events are a little more complicated than semaphores and take up just a hair more microprocessor time than semaphores. The advantage of events over semaphores is that a task can wait for any one of several events at the same time, whereas it can only wait for one semaphore. (Another advantage is that some RTOSs make it convenient to use events and make it inconvenient to use semaphores for this purpose.)
Queues allow you to send a lot of information from one task to another. Even though the task can wait on only one queue (or mailbox or pipe) at a time, the fact that you can send data through a queue make it even more flexible than events. The drawbacks are (1) putting messages into and taking messages out of queues is more microprocessor-intensive and (2) that queues offer you many more opportunities to insert bugs into your code. Mailboxes and pipes share all of these characteristics.
