Warning
This document is not updated for ESP32C5 yet, so some of the content may not be correct.
This warning was automatically inserted due to the source file being in the add_warnings_pages list.
Creating Examples
Each ESP-IDF example is a complete project that someone else can copy and adapt the code to solve their own problem. Examples should demonstrate ESP-IDF functionality, while keeping this purpose in mind.
Structure
The
main
directory should contain a source file named(something)_example_main.c
with the main functionality.If the example has additional functionality, split it logically into separate C or C++ source files under
main
and place a corresponding header file in the same directory.If the example has a lot of additional functionality, consider adding a
components
directory to the example project and make some example-specific components with library functionality. Only do this if the components are specific to the example, if they are generic or common functionality then they should be added to ESP-IDF itself.The example should have a
README.md
file. Use the template example README and adapt it for your particular example.Examples should have a
pytest_<example name>.py
file for running an automated example test. If submitting a GitHub Pull Request which includes an example, it is OK not to include this file initially. The details can be discussed as part of the Pull Request. Please refer to IDF Tests with Pytest Guide for details.
General Guidelines
Example code should follow the Espressif IoT Development Framework Style Guide.
Checklist
Checklist before submitting a new example:
Example does one distinct thing. If the example does more than one thing at a time, split it into two or more examples.
Example has a
README.md
file which is similar to the template example README .Functions and variables in the example are named according to naming section of the style guide. For non-static names which are only specific to the example's source files, you can use
example
or something similar as a prefix.All code in the example is well structured and commented.
Any unnecessary code (old debugging logs, commented-out code, etc.) is removed from the example.
Options in the example (like network names, addresses, etc) are not hard-coded. Use configuration items if possible, or otherwise declare macros or constants.
Configuration items are provided in a
KConfig.projbuild
file with a menu named "Example Configuration". See existing example projects to see how this is done.All original example code has a license header saying it is "in the public domain / CC0", and a warranty disclaimer clause. Alternatively, the example is licensed under Apache License 2.0. See existing examples for headers to adapt from.
Any adapted or third party example code has the original license header on it. This code must be licensed compatible with Apache License 2.0.