616baa239d
Legacy API of task watchdog used the same function esp_task_wdt_feed() to add and feed a task. This caused issues of implicitly adding a task to the wdt list if the function was used in shared code. The new API introduces init, adding, feeding, deleting, deinit functions. Tasks must now be explicitly added to the task watchdog using their handles. Deletion must also be explicit using task handles. This resolves the issue of implicit task additions to the task watchdog due to shared code calling esp_task_wdt_feed(). Task watchdog is now fully configurable at runtime by calling the init and deinit functions. Also added functions to get the handles of idle tasks of the other core. This helps when adding idle tasks to the watchdog at run time. Configuring the task watchdog using menu config is still available, however menu config will only result in calling the init and add functions for idle tasks shortly after the scheduler starts. Menu config also allows for using legacy behavior, however the legacy behavior willcall the new API functions but with slight variations to make them legacy compatible. Documentation and example have also been updated gcov_rtio.c headers updated to prevent error of freertos header files being included in the wrong order. Resolves issue TW#13265
Examples
This directory contains a growing number of simple example projects for esp-idf. These are intended to show basic esp-idf functionality, and to provide you can use for your own projects.
Using Examples
Building examples is the same as building any other project:
-
Follow the setup instructions in the top-level esp-idf README.
-
Set
IDF_PATHenvironment variable to point to the path to the esp-idf top-level directory. -
Change into the directory of the example you'd like to build.
-
make menuconfigto configure the example. Most examples require a simple WiFi SSID & password via this configuration. -
maketo build the example. -
Follow the printed instructions to flash, or run
make flash.
Copying Examples
Each example is a standalone project. The examples do not have to be inside the esp-idf directory. You can copy an example directory to anywhere on your computer in order to make a copy that you can modify and work with.
The IDF_PATH environment variable is the only thing that connects the example to the rest of the esp-idf system.
If you're looking for a more bare-bones project to start from, try esp-idf-template.
Contributing Examples
If you have a new example you think we'd like, please consider sending it to us as a Pull Request.
Please read the esp-idf CONTRIBUTING.rst file which lays out general contribution rules.
In addition, here are some tips for creating good examples:
- A good example is documented and the basic options can be configured.
- A good example does not contain a lot of code. If there is a lot of generic code in the example, consider refactoring that code into a standalone component and then use the component's API in your example.
- Names (of files, functions, variables, etc.) inside examples should be distinguishable from names of other parts of IDF (ideally, use
examplein names.) - Functions and variables used inside examples should be declared static where possible.
- Examples should demonstrate one distinct thing each. Avoid multi-purposed "demo" examples, split these into multiple examples instead.
- Examples must be licensed under the Apache License 2.0 or (preferably for examples) if possible you can declare the example to be Public Domain / Creative Commons Zero.