From f4ef7689bd79d04b56278b5cfa28df8f901e05f4 Mon Sep 17 00:00:00 2001 From: krzychb Date: Fri, 29 Jun 2018 19:01:11 +0200 Subject: [PATCH 1/2] The 'Two Point Values' used to calibrate ADC readings, unlike 'eFuse Vref', are not measured and burned into eFuse BLOCK3 for each individual chip during factory calibration. This operation should be done by user, if more accurate calibration is required. --- docs/en/api-reference/peripherals/adc.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/api-reference/peripherals/adc.rst b/docs/en/api-reference/peripherals/adc.rst index ee6f98a6dc..972c1f0c9a 100644 --- a/docs/en/api-reference/peripherals/adc.rst +++ b/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. From 8a7ee46b7fc93c4384006fc7a1a6e0320955a6dc Mon Sep 17 00:00:00 2001 From: krzychb Date: Fri, 29 Jun 2018 19:21:51 +0200 Subject: [PATCH 2/2] Fixed link to 'TEMPLATE_EXAMPLE_README.md' --- docs/en/contribute/creating-examples.rst | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/en/contribute/creating-examples.rst b/docs/en/contribute/creating-examples.rst index 69c0bbdae9..eb8132b80e 100644 --- a/docs/en/contribute/creating-examples.rst +++ b/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 ` 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 `. * Functions and variables in the example are named according to :ref:`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. @@ -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`