This allows the processes launched from idf_tools.py to use the value
of IDF_PATH. One such example is the installation of Python packages,
when requirements.txt uses IDF_PATH to refer to the esp-windows-curses
package.
Closes https://github.com/espressif/esp-idf/issues/4341
implemented workaround in idf_monitor for known usbser.sys bug which
causes changes in RTS signal to only be sent if DTR signal also changes.
Works by forcing a dummy change in DTR signal (re-assigning its current
value, as it has previously been done in the flashing tool)
Closes https://github.com/espressif/esp-idf/pull/4676
use CI dependencies could waste a lot bandwidth for target test jobs, as
example binary artifacts are very large. Now we will parse required
artifacts first, then use API to download required files in artifacts.
we should only load one module once.
if we load one module twice, python will regard the same object loaded in the first time and second time as different objects.
it will lead to strange errors like `isinstance(object, type_of_this_object)` return False
If we have multiple configs, we need to flash DUT with different binaries. But if we don't close DUT before apply new config, the old DUT will be reused, so new config name will not be applied.
Currently we use config and test function as filter when assign cases to one CI job. It's not necessary as the runner can run test with different configs / test functions. Now we will try to assign as many cases to a job as possible, to reduce the amount of jobs required.
This commit adds a pair of scripts, find_apps.py and build_apps.py.
These scripts are intended to be used in various CI jobs, building
multiple applications with different configurations and targets.
The first script, find_apps.py, is used to prepare the list of builds:
1. It finds apps for the given build system.
2. For each app, it finds configurations (sdkconfig files) which need
to be built.
3. It filters out the apps and configurations which are not compatible
with the given target.
4. It outputs the list of builds into stdout or a file. Currently the
format is a list of lines, each line a JSON string. In the future,
the tool can be updated to output YAML files.
The lists of builds can be concatenated and processed with standard
command line tools, like sed.
The second script, build_apps.py, executes the builds from the list.
It can execute a subset of builds based on --parallel-count and
--parallel-index arguments.
These two scripts are intended to replace build_examples_make,
build_examples_cmake, and the custom unit-test-app logic (in the
Makefile and idf_ext.py).
Closes IDF-641
... to reduce the number of simultaneously open files at link time.
When plugin support is enabled in the linker, BFD's (and the
corresponding file handles) are cached for the plugin to use. This
results in quite a large number of simultaneously open files, which
hits the default limit on macOS (256 files).
Since we aren't using LTO now, disable it explicitly when invoking the
linker.
Closes IDF-923
Closes IDFGH-1764
Closes https://github.com/espressif/esp-idf/issues/3989
Tests for external flash chips used to controlled by macros, one bin for
one chip. And tests are done manually. This commit refactored the test
so that all 3 chips can all run in single test.
Use rev-parse to get the HEAD directory instead of manually looking for
it. This method works in the main repository, worktrees and submodules.
Closes https://github.com/espressif/esp-idf/issues/4136
This commit makes it so that BUILD_COMPONENT holds only the component,
and a new property BUILD_COMPONENT_ALIASES hold the full name of the
component.
This also removes erroneous check for duplicate components, as this can
never happen:
(1) if two components have the same name but different prefixes,
the internal names are still unique between them
(2)if two components happen to have the same name and same prefix, the
latter would override the former
Previous implementation only builds list of components included in the
build during component registration.
Since the build components is known as the requirements expansion is
ongoing, update the list here instead.
Use imported library, which does not create additional rules, but still
allows attaching arbitraty properties instead of custom targets. This
allows the targets to not appear in the target list of IDEs such as
CLion.
The workaround for PSRAM that will occupy an SPI bus is enabled only when:
1. used on 32MBit ver 0 PSRAM.
2. work at 80MHz.
The test used to only check 32MBit by the config option, but for PSRAM
on Wrover-B module seems to use a newer version of 32MBit PSRAM. So it
expects the workaround to be enabled, but actually not.
This commit split the unit test into two parts:
1. check all SPI buses are available, for all configs except psram_hspi
and psram_vspi, run on regular runners (including Wrover and Wrover-B).
a hidden option is enabled so that the compiler knows it's not building
psram_hspi or psram_vspi.
2. check the specified bus are acquired, for config psram_hspi and
psram_vspi. This only run on special runner (legacy Wrover module).
Ref. https://github.com/espressif/esp-idf/issues/1684
This change allows RTTI to be enabled in menuconfig. For full RTTI
support, libstdc++.a in the toolchain should be built without
-fno-rtti, as it is done now.
Generally if libstdc++.a is built with RTTI, applications which do not
use RTTI (and build with -fno-rtti) could still include typeinfo
structures referenced from STL classes’ vtables. This change works
around this, by moving all typeinfo structures from libstdc++.a into
a non-loadable section, placed into a non-existent memory region
starting at address 0. This can be done because when the application
is compiled with -fno-rtti, typeinfo structures are not used at run
time. This way, typeinfo structures do not contribute to the
application binary size.
If the application is build with RTTI support, typeinfo structures are
linked into the application .rodata section as usual.
Note that this commit does not actually enable RTTI support.
The respective Kconfig option is hidden, and will be made visible when
the toolchain is updated.
Replace the outdated build_installer.sh with the steps used in CI,
call build_installer.sh from CI. Move the signing part into the new
script, sign_installer.sh.
