Merge branch 'bugfix/adc_two_point_cal_val_update' into 'master'

Updated information in  documentation about  'Two Point Values' used to calibrate ADC readings

See merge request idf/esp-idf!2678

docs/en/api-reference/peripherals/adc.rst

@@ -114,7 +114,7 @@ Calibration Values
 
 Calibration values are used to generate characteristic curves that account for the unique ADC reference voltage of a particular ESP32. There are currently three sources of calibration values. The availability of these calibration values will depend on the type and production date of the ESP32 chip/module.
 
-**Two Point** values represent each of the ADCs’ readings at 150mV and 850mV. These values are measured and burned into eFuse ``BLOCK3`` during factory calibration.
+**Two Point** values represent each of the ADCs’ readings at 150mV and 850mV. To obtain more accurate calibration results these values should be measured by user and burned into eFuse ``BLOCK3``.
 
 **eFuse Vref** represents the true ADC reference voltage. This value is measured and burned into eFuse ``BLOCK0`` during factory calibration. 
 

docs/en/contribute/creating-examples.rst

@@ -9,7 +9,7 @@ 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're 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.
+- The example should have a ``README.md`` file. Use the :idf_file:`template example README <docs/TEMPLATE_EXAMPLE_README.md>` and adapt it for your particular example.
 - Examples should have an ``example_test.py`` file for running an automated example test. If submitting a GitHub Pull Request which includes an example, it's OK not to include this file initially. The details can be discussed as part of the PR.
 
 General Guidelines
@@ -24,7 +24,7 @@ Checklist before submitting a new example:
 
 * Example project name (in ``Makefile`` and ``README.md``) uses the word "example". Use "example" instead of "demo", "test" or similar words.
 * 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`_.
+* Example has a ``README.md`` file which is similar to the :idf_file:`template example README <docs/TEMPLATE_EXAMPLE_README.md>`.
 * Functions and variables in the example are named according to :ref:`naming section of the style guide <style-guide-naming>`. (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.
@@ -32,5 +32,3 @@ Checklist before submitting a new example:
 * 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.
-
-.. _template example README: :idf_file:`/doc/TEMPLATE_EXAMPLE_README.md`