This commit updates the ESP-IDF FreeRTOS and FreeRTOS Additions to account for
the fact that there are now two implementations of SMP FreeRTOS (i.e., IDF SMP
vs Amazon SMP).
This commit updates "freertos.rst" to act as an overview document of FreeRTOS
in ESP-IDF, outlining the different FreeRTOS implementations (IDF vs Amazon)
and various supplemental features. The details of each implementation will be
separated to their own documents.
This commit renames "freertos-smp" docuemnt to "freertos_idf". This fits better
with the current dual FreeRTOS implementation (i.e., IDF FreeRTOS and Amazon
SMP FreeRTOS), both of which are SMP capable.
IDF_PYTHON_ENV_PATH is the path where the Python environment is created
and used. By default it is inside IDF_TOOLS_PATH. IDF_PYTHON_ENV_PATH
was exported by idf_tools.py but was not imported back. This fixes the
issue and ESP-IDF will honor the value of IDF_PYTHON_ENV_PATH.
Closes https://github.com/espressif/esp-idf/issues/10489
This adds a new outdated option, which only lists outdated
packages installed in IDF_TOOLS_PATH. It searches for the
latest installed tool version in the IDF_TOOLS_PATH/tools path and
compares it against the latest available version in the tools.json
file. If the latest version of a tool installed in IDF_TOOLS_PATH/tools
is smaller, it's reported as outdated. Nothing is reported if the tool
is up to date.
Two new tests are added. First just checks if nothing is reported in
case there is no update available. The second artificially generates
new tools.json file called tools.outdated.json and sets XTENSA_ESP32_ELF
version to 'zzzzzz'. It then checks if the XTENSA_ESP32_ELF tool
is reported as outdated by the 'zzzzzz' version.
Description of the new outdated option is addedd to docs as well.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Hints should be now working for gdbui and openocd. They are not
produced via RunTool(), but the hints are used directly.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
In a very rare cases there is a need to use custom license, which is not
present on the SPDX list. Now, files under such license are added to the
check_copyright ignore list. For example zigbee examples introduced
by !16205. SPDX has a LicenseRef-[idstring] identifier[1] for such cases,
so let's try to use it in license representation[2]. The idea is that licenses
not on the SPDX list can be added into the LICENSES[3] directory and used as
SPDX-License-Identifier: LicenseRef-Special-License
Or if the custom license is present directly in a source file we can use
a special LicenseRef-Included identifier to state that the license
is included.
SPDX-License-Identifier: LicenseRef-Included
Please note that LicenseRef-Included is just a made up identifier to
state the fact that the license is included directly in the source file.
There is nothing in the SPDX spec about this usage.
This relatively small adjustment allows to refer to custom licenses
without a need to skip check_copyright for them.
[1] https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/#101-license-identifier-field
[2] https://spdx.github.io/spdx-spec/v2.3/using-SPDX-short-identifiers-in-source-files/#e4-representing-multiple-licenses
[3] https://reuse.software/spec/
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
