From 6c3bddd257cc521db0d5bf5fb9524fdd234e038e Mon Sep 17 00:00:00 2001 From: gdisirio Date: Sat, 18 Sep 2010 08:31:12 +0000 Subject: Fixed bug 3069854, fixed documentation article about events. git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@2180 35acf78f-673a-0410-8e92-d51de3d6d3f4 --- docs/src/events.dox | 41 +++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 20 deletions(-) (limited to 'docs/src') diff --git a/docs/src/events.dox b/docs/src/events.dox index 98ba8d55f..27de187e4 100644 --- a/docs/src/events.dox +++ b/docs/src/events.dox @@ -27,33 +27,34 @@ * explanation.
* Lets start with the events related terminology: * - Event Source, an @p EventSource is a system object that can be - * @a broadcasted asynchronously in response of a system event, as example, - * when the CAN driver receives a packet from the CAN bus it @a broadcasts + * broadcasted asynchronously in response of a system event, as example, + * when the CAN driver receives a packet from the CAN bus it broadcasts * an event source in order to inform the registered threads that a packet * has just arrived. * - Broadcast, the operation performed on an event source in order - * to inform the @a registered threads that an event just occurred. + * to inform the registered threads that an event just occurred. * Broadcasting can happened both in interrupt handlers and in threads. * - Event Listener, a system object that associates a @p Thread object * to an event source. The process of associating a @p Thread to an - * @p EventSource using an @p EventListener is called @a registration. + * @p EventSource using an @p EventListener is called registration. * - Registration, action performed by a thread in order to be informed * of events from a specific event source. Of course a thread can be - * @a registered on more than one event source by using multiple - * @p EventListener objects. Threads can also @a unregister from an event + * registered on more than one event source by using multiple + * @p EventListener objects. Threads can also unregister from an event * source. - * - Pend, each thread has a mask of @a pending events. The @a broadcast - * operation @a pends an event mask on all the @a registered threads. + * - Pending Events, event flags waiting to be served by a thread. + * - Add, the broadcast operation adds (logical or) an events + * mask to all the registered threads. * - Wait, synchronous operation performed by a thread in order to - * @a wait a specific combination of events. The API offers a variety of - * @a wait functions, please refer to the events API documentation. + * wait a specific combination of events. The API offers a variety of + * wait functions, please refer to the events API documentation. * . * Note that events are asynchronously generated, as example in an interrupt * handler, but are synchronously served. * *

Events related data structures

* The following diagram explains the relationship between an event source, - * its list of event listeners and the @a registered threads. + * its list of event listeners and the registered threads. * @dot digraph example { rankdir="LR"; @@ -97,19 +98,19 @@ el4 -> t4 [label="el_listener"]; } * @enddot - * Note that each event listener has a different bit mask to be @a pended on - * its associated thread when the event source is @a broadcasted, this means + * Note that each event listener has a different bit mask to be added on + * its associated thread when the event source is broadcasted, this means * that each thread can define its own event identifiers independently. A - * @a broadcast operation can also @a pend more than one bit on the - * @a registered threads.
- * The threads have a variety of @a wait primitives, they can @a wait for one - * or more event flags to become @a pending, and can also specify AND/OR - * conditions, as example a thread can @a wait for any event to become - * @a pending or @a wait for all the specified events to become @a pending.
+ * broadcast operation can also add more than one bit on the + * registered threads.
+ * The threads have a variety of wait primitives, they can wait for one + * or more event flags, and can also specify AND/OR conditions, as example + * a thread can wait for any of the specified events or wait for all the + * specified events.
* The field @p p_epending is the mask of the currently pending events, * the field @p p_ewmask is the mask of the events the thread is interested * on in that moment (AND or OR condition depending on the invoked - * @a wait API). + * wait API). * *

Use Scenarios

* Events are best used when one of more of the following conditions are -- cgit v1.2.3