Event Loop Library¶
Overview¶
The event loop library allows components to declare events to which other components can register handlers – code which will execute when those events occur. This allows loosely coupled components to attach desired behavior to changes in state of other components without application involvement. For instance, a high level connection handling library may subscribe to events produced by the wifi subsystem directly and act on those events. This also simplifies event processing by serializing and deferring code execution to another context.
Using esp_event APIs¶
There are two objects of concern for users of this library: events and event loops.
Events are occurrences of note. For example, for WiFi, a successful connection to the access point may be an event. Events are referenced using a two part identifier which are discussed more here. Event loops are the vehicle by which events get posted by event sources and handled by event handler functions. These two appear prominently in the event loop library APIs.
Using this library roughly entails the following flow:
A user defines a function that should run when an event is posted to a loop. This function is referred to as the event handler. It should have the same signature as
esp_event_handler_t.An event loop is created using
esp_event_loop_create(), which outputs a handle to the loop of typeesp_event_loop_handle_t. Event loops created using this API are referred to as user event loops. There is, however, a special type of event loop called the default event loop which are discussed here.Components register event handlers to the loop using
esp_event_handler_register_with(). Handlers can be registered with multiple loops, more on that here.Event sources post an event to the loop using
esp_event_post_to().Components wanting to remove their handlers from being called can do so by unregistering from the loop using
esp_event_handler_unregister_with().Event loops which are no longer needed can be deleted using
esp_event_loop_delete().
In code, the flow above may look like as follows:
// 1. Define the event handler
void run_on_event(void* handler_arg, esp_event_base_t base, int32_t id, void* event_data)
{
// Event handler logic
}
void app_main()
{
// 2. A configuration structure of type esp_event_loop_args_t is needed to specify the properties of the loop to be
// created. A handle of type esp_event_loop_handle_t is obtained, which is needed by the other APIs to reference the loop
// to perform their operations on.
esp_event_loop_args_t loop_args = {
.queue_size = ...,
.task_name = ...
.task_priority = ...,
.task_stack_size = ...,
.task_core_id = ...
};
esp_event_loop_handle_t loop_handle;
esp_event_loop_create(&loop_args, &loop_handle);
// 3. Register event handler defined in (1). MY_EVENT_BASE and MY_EVENT_ID specifies a hypothetical
// event that handler run_on_event should execute on when it gets posted to the loop.
esp_event_handler_register_with(loop_handle, MY_EVENT_BASE, MY_EVENT_ID, run_on_event, ...);
...
// 4. Post events to the loop. This queues the event on the event loop. At some point in time
// the event loop executes the event handler registered to the posted event, in this case run_on_event.
// For simplicity sake this example calls esp_event_post_to from app_main, but posting can be done from
// any other tasks (which is the more interesting use case).
esp_event_post_to(loop_handle, MY_EVENT_BASE, MY_EVENT_ID, ...);
...
// 5. Unregistering an unneeded handler
esp_event_handler_unregister_with(loop_handle, MY_EVENT_BASE, MY_EVENT_ID, run_on_event);
...
// 6. Deleting an unneeded event loop
esp_event_loop_delete(loop_handle);
}
Declaring and defining events¶
As mentioned previously, events consists of two-part identifers: the event base and the event ID. The event base identifies an independent group of events; the event ID identifies the event within that group. Think of the event base and event ID as a person’s last name and first name, respectively. A last name identifies a family, and the first name identifies a person within that family.
The event loop library provides macros to declare and define the event base easily.
Event base declaration:
ESP_EVENT_DECLARE_BASE(EVENT_BASE)
Event base definition:
ESP_EVENT_DEFINE_BASE(EVENT_BASE)
注解
In IDF, the base identifiers for system events are uppercase and are postfixed with _EVENT. For example, the base for wifi events is declared and defined
as WIFI_EVENT, the ethernet event base ETHERNET_EVENT, and so on. The purpose is to have event bases look like constants (although
they are global variables considering the defintions of macros ESP_EVENT_DECLARE_BASE and ESP_EVENT_DEFINE_BASE).
For event ID’s, declaring them as enumerations is recommended. Once again, for visibility, these are typically placed in public header files.
Event ID:
enum {
EVENT_ID_1,
EVENT_ID_2,
EVENT_ID_3,
...
}
Default Event Loop¶
The default event loop is a special type of loop used for system events (WiFi events, for example). The handle for this loop is hidden from the user. The creation, deletion, handler registration/unregistration and posting of events is done through a variant of the APIs for user event loops. The table below enumerates those variants, and the user event loops equivalent.
User Event Loops |
Default Event Loops |
|---|---|
If you compare the signatures for both, they are mostly similar except the for the lack of loop handle specification for the default event loop APIs.
Other than the API difference and the special designation to which system events are posted to, there is no difference to how default event loops and user event loops behave. It is even possible for users to post their own events to the default event loop, should the user opt to not create their own loops to save memory.
Notes on Handler Registration¶
It is possible to register a single handler to multiple events individually, i.e. using multiple calls to esp_event_handler_register_with().
For those multiple calls, the specific event base and event ID can be specified with which the handler should execute.
However, in some cases it is desirable for a handler to execute on (1) all events that get posted to a loop or (2) all events
of a particular base identifier. This is possible using the special event base identifier ESP_EVENT_ANY_BASE and
special event ID ESP_EVENT_ANY_ID. These special identifiers may be passed as the event base and event ID arguments
for esp_event_handler_register_with().
Therefore, the valid arguments to esp_event_handler_register_with() are:
<event base>, <event ID> - handler executes when the event with base <event base> and event ID <event ID> gets posted to the loop
<event base>, ESP_EVENT_ANY_ID - handler executes when any event with base <event base> gets posted to the loop
ESP_EVENT_ANY_BASE, ESP_EVENT_ANY_ID - handler executes when any event gets posted to the loop
As an example, suppose the following handler registrations were performed:
esp_event_handler_register_with(loop_handle, MY_EVENT_BASE, MY_EVENT_ID, run_on_event_1, ...);
esp_event_handler_register_with(loop_handle, MY_EVENT_BASE, ESP_EVENT_ANY_ID, run_on_event_2, ...);
esp_event_handler_register_with(loop_handle, ESP_EVENT_ANY_BASE, ESP_EVENT_ANY_ID, run_on_event_3, ...);
If the hypothetical event MY_EVENT_BASE, MY_EVENT_ID is posted, all three handlers run_on_event_1, run_on_event_2,
and run_on_event_3 would execute.
If the hypothetical event MY_EVENT_BASE, MY_OTHER_EVENT_ID is posted, only run_on_event_2 and run_on_event_3 would execute.
If the hypothetical event MY_OTHER_EVENT_BASE, MY_OTHER_EVENT_ID is posted, only run_on_event_3 would execute.
Handler Registration and Handler Dispatch Order¶
The general rule is that for handlers that match a certain posted event during dispatch, those which are registered first also gets executed first. The user can then control which handlers get executed first by registering them before other handlers, provided that all registrations are performed using a single task. If the user plans to take advantage of this behavior, caution must be exercised if there are multiple tasks registering handlers. While the ‘first registered, first executed’ behavior still holds true, the task which gets executed first will also get their handlers registered first. Handlers registered one after the other by a single task will still be dispatched in the order relative to each other, but if that task gets pre-empted in between registration by another task which also registers handlers; then during dispatch those handlers will also get executed in between.
Event loop profiling¶
A configuration option CONFIG_ESP_EVENT_LOOP_PROFILING can be enabled in order to activate statistics collection for all event loops created.
The function esp_event_dump() can be used to output the collected statistics to a file stream. More details on the information included in the dump
can be found in the esp_event_dump() API Reference.
Application Example¶
Examples on using the esp_event library can be found in system/esp_event. The examples cover event declaration, loop creation, handler registration and unregistration and event posting.
Other examples which also adopt esp_event library:
NMEA Parser , which will decode the statements received from GPS.
API Reference¶
Header File¶
Functions¶
-
esp_err_t
esp_event_loop_create(const esp_event_loop_args_t *event_loop_args, esp_event_loop_handle_t *event_loop)¶ Create a new event loop.
- Return
ESP_OK: Success
ESP_ERR_NO_MEM: Cannot allocate memory for event loops list
ESP_FAIL: Failed to create task loop
Others: Fail
- Parameters
[in] event_loop_args: configuration structure for the event loop to create[out] event_loop: handle to the created event loop
-
esp_err_t
esp_event_loop_delete(esp_event_loop_handle_t event_loop)¶ Delete an existing event loop.
- Return
ESP_OK: Success
Others: Fail
- Parameters
[in] event_loop: event loop to delete
-
esp_err_t
esp_event_loop_create_default(void)¶ Create default event loop.
- Return
ESP_OK: Success
ESP_ERR_NO_MEM: Cannot allocate memory for event loops list
ESP_FAIL: Failed to create task loop
Others: Fail
-
esp_err_t
esp_event_loop_delete_default(void)¶ Delete the default event loop.
- Return
ESP_OK: Success
Others: Fail
-
esp_err_t
esp_event_loop_run(esp_event_loop_handle_t event_loop, TickType_t ticks_to_run)¶ Dispatch events posted to an event loop.
This function is used to dispatch events posted to a loop with no dedicated task, i.e task name was set to NULL in event_loop_args argument during loop creation. This function includes an argument to limit the amount of time it runs, returning control to the caller when that time expires (or some time afterwards). There is no guarantee that a call to this function will exit at exactly the time of expiry. There is also no guarantee that events have been dispatched during the call, as the function might have spent all of the alloted time waiting on the event queue. Once an event has been unqueued, however, it is guaranteed to be dispatched. This guarantee contributes to not being able to exit exactly at time of expiry as (1) blocking on internal mutexes is necessary for dispatching the unqueued event, and (2) during dispatch of the unqueued event there is no way to control the time occupied by handler code execution. The guaranteed time of exit is therefore the alloted time + amount of time required to dispatch the last unqueued event.
In cases where waiting on the queue times out, ESP_OK is returned and not ESP_ERR_TIMEOUT, since it is normal behavior.
- Note
encountering an unknown event that has been posted to the loop will only generate a warning, not an error.
- Return
ESP_OK: Success
Others: Fail
- Parameters
[in] event_loop: event loop to dispatch posted events from[in] ticks_to_run: number of ticks to run the loop
-
esp_err_t
esp_event_handler_register(esp_event_base_t event_base, int32_t event_id, esp_event_handler_t event_handler, void *event_handler_arg)¶ Register an event handler to the system event loop.
This function can be used to register a handler for either: (1) specific events, (2) all events of a certain event base, or (3) all events known by the system event loop.
specific events: specify exact event_base and event_id
all events of a certain base: specify exact event_base and use ESP_EVENT_ANY_ID as the event_id
all events known by the loop: use ESP_EVENT_ANY_BASE for event_base and ESP_EVENT_ANY_ID as the event_id
Registering multiple handlers to events is possible. Registering a single handler to multiple events is also possible. However, registering the same handler to the same event multiple times would cause the previous registrations to be overwritten.
- Note
the event loop library does not maintain a copy of event_handler_arg, therefore the user should ensure that event_handler_arg still points to a valid location by the time the handler gets called
- Return
ESP_OK: Success
ESP_ERR_NO_MEM: Cannot allocate memory for the handler
ESP_ERR_INVALID_ARG: Invalid combination of event base and event id
Others: Fail
- Parameters
[in] event_base: the base id of the event to register the handler for[in] event_id: the id of the event to register the handler for[in] event_handler: the handler function which gets called when the event is dispatched[in] event_handler_arg: data, aside from event data, that is passed to the handler when it is called
-
esp_err_t
esp_event_handler_register_with(esp_event_loop_handle_t event_loop, esp_event_base_t event_base, int32_t event_id, esp_event_handler_t event_handler, void *event_handler_arg)¶ Register an event handler to a specific loop.
This function behaves in the same manner as esp_event_handler_register, except the additional specification of the event loop to register the handler to.
- Note
the event loop library does not maintain a copy of event_handler_arg, therefore the user should ensure that event_handler_arg still points to a valid location by the time the handler gets called
- Return
ESP_OK: Success
ESP_ERR_NO_MEM: Cannot allocate memory for the handler
ESP_ERR_INVALID_ARG: Invalid combination of event base and event id
Others: Fail
- Parameters
[in] event_loop: the event loop to register this handler function to[in] event_base: the base id of the event to register the handler for[in] event_id: the id of the event to register the handler for[in] event_handler: the handler function which gets called when the event is dispatched[in] event_handler_arg: data, aside from event data, that is passed to the handler when it is called
-
esp_err_t
esp_event_handler_unregister(esp_event_base_t event_base, int32_t event_id, esp_event_handler_t event_handler)¶ Unregister a handler with the system event loop.
This function can be used to unregister a handler so that it no longer gets called during dispatch. Handlers can be unregistered for either: (1) specific events, (2) all events of a certain event base, or (3) all events known by the system event loop
specific events: specify exact event_base and event_id
all events of a certain base: specify exact event_base and use ESP_EVENT_ANY_ID as the event_id
all events known by the loop: use ESP_EVENT_ANY_BASE for event_base and ESP_EVENT_ANY_ID as the event_id
This function ignores unregistration of handlers that has not been previously registered.
- Return
ESP_OK success
- Return
ESP_ERR_INVALID_ARG invalid combination of event base and event id
- Return
others fail
- Parameters
[in] event_base: the base of the event with which to unregister the handler[in] event_id: the id of the event with which to unregister the handler[in] event_handler: the handler to unregister
-
esp_err_t
esp_event_handler_unregister_with(esp_event_loop_handle_t event_loop, esp_event_base_t event_base, int32_t event_id, esp_event_handler_t event_handler)¶ Unregister a handler with the system event loop.
This function behaves in the same manner as esp_event_handler_unregister, except the additional specification of the event loop to unregister the handler with.
- Return
ESP_OK: Success
ESP_ERR_INVALID_ARG: Invalid combination of event base and event id
Others: Fail
- Parameters
[in] event_loop: the event loop with which to unregister this handler function[in] event_base: the base of the event with which to unregister the handler[in] event_id: the id of the event with which to unregister the handler[in] event_handler: the handler to unregister
-
esp_err_t
esp_event_post(esp_event_base_t event_base, int32_t event_id, void *event_data, size_t event_data_size, TickType_t ticks_to_wait)¶ Posts an event to the system default event loop. The event loop library keeps a copy of event_data and manages the copy’s lifetime automatically (allocation + deletion); this ensures that the data the handler recieves is always valid.
- Return
ESP_OK: Success
ESP_ERR_TIMEOUT: Time to wait for event queue to unblock expired, queue full when posting from ISR
ESP_ERR_INVALID_ARG: Invalid combination of event base and event id
Others: Fail
- Parameters
[in] event_base: the event base that identifies the event[in] event_id: the event id that identifies the event[in] event_data: the data, specific to the event occurence, that gets passed to the handler[in] event_data_size: the size of the event data[in] ticks_to_wait: number of ticks to block on a full event queue
-
esp_err_t
esp_event_post_to(esp_event_loop_handle_t event_loop, esp_event_base_t event_base, int32_t event_id, void *event_data, size_t event_data_size, TickType_t ticks_to_wait)¶ Posts an event to the specified event loop. The event loop library keeps a copy of event_data and manages the copy’s lifetime automatically (allocation + deletion); this ensures that the data the handler recieves is always valid.
This function behaves in the same manner as esp_event_post_to, except the additional specification of the event loop to post the event to.
- Return
ESP_OK: Success
ESP_ERR_TIMEOUT: Time to wait for event queue to unblock expired, queue full when posting from ISR
ESP_ERR_INVALID_ARG: Invalid combination of event base and event id
Others: Fail
- Parameters
[in] event_loop: the event loop to post to[in] event_base: the event base that identifies the event[in] event_id: the event id that identifies the event[in] event_data: the data, specific to the event occurence, that gets passed to the handler[in] event_data_size: the size of the event data[in] ticks_to_wait: number of ticks to block on a full event queue
-
esp_err_t
esp_event_dump(FILE *file)¶ Dumps statistics of all event loops.
Dumps event loop info in the format:
event loop handler handler ... event loop handler handler ... where: event loop format: address,name rx:total_recieved dr:total_dropped where: address - memory address of the event loop name - name of the event loop, 'none' if no dedicated task total_recieved - number of successfully posted events total_dropped - number of events unsuccessfully posted due to queue being full handler format: address ev:base,id inv:total_invoked run:total_runtime where: address - address of the handler function base,id - the event specified by event base and id this handler executes total_invoked - number of times this handler has been invoked total_runtime - total amount of time used for invoking this handler
- Note
this function is a noop when CONFIG_ESP_EVENT_LOOP_PROFILING is disabled
- Return
ESP_OK: Success
ESP_ERR_NO_MEM: Cannot allocate memory for event loops list
Others: Fail
- Parameters
[in] file: the file stream to output to
Structures¶
-
struct
esp_event_loop_args_t¶ Configuration for creating event loops.
Public Members
-
int32_t
queue_size¶ size of the event loop queue
-
const char *
task_name¶ name of the event loop task; if NULL, a dedicated task is not created for event loop
-
UBaseType_t
task_priority¶ priority of the event loop task, ignored if task name is NULL
-
uint32_t
task_stack_size¶ stack size of the event loop task, ignored if task name is NULL
-
BaseType_t
task_core_id¶ core to which the event loop task is pinned to, ignored if task name is NULL
-
int32_t