This commit adds support for using the RTC I2C peripheral on the ULP
RISC-V core for esp32s2 and esp32s3. It also adds an example to demonstrate the
usage of the RTC I2C peripheral.
This commit also modifies the rtc_i2c register structure files to enable
the use of bitfields in the ULP RISC-V RTC I2C driver.
There are multiple changes in this commit:
1. Unify the RISC-V and ULP-FSM code paths in esp32ulp_mapgen.py.
It seems that these were originally introduced because `nm` output
for the RISC-V case contained symbol sizes, while for the ULP-FSM
no symbol sizes were reported. This makes sense, because the
ULP-FSM object files are produced from assembly source, symbol
sizes have to be added manually using the .size directive.
In the case of RISC-V, the object files are built from C sources
and the sizes are automatically added by the compiler.
Now 'posix' output format is used for both RISC-V and ULP-FSM.
2. Move BASE_ADDR out of esp32ulp_mapgen.py. This now has to be passed
from CMake, which should make it easier to modify if a new chip
with a different RTC RAM base address is added.
3. Add C++ guards to the generated header file.
4. Switch from optparse to argparse for similarity with other IDF
tools.
5. Add type annotations.
* "dummy loop to force pre-processed linker file generation" seems to
be unnecessary. It looks like the idea was copied from the
dependency of ULP-FSM preprocessed source files on the LD script.
* Can use add_dependencies instead of
set_target_properties(...LINK_DEPENDS...) which is more readable
* Use target_link_options instead of target_link_libraries, which is
supported starting from CMake 3.13. Unlike target_link_libraries,
it doesn't require manually quoting the pats.
the variable "IDF_TARGET" is only used under a if clause
"if(ULP_C0CPU_IS_RISCV)". while building a non-riscv target,
there will be a cmake warning:
CMake Warning:
Manually-specified variables were not used by the project:
IDF_TARGET
Due to poor accuracy the ESP32 ULP TSENS instructions is not recommend for use.
We keep the instruction itself to support users which are already using it,
but should remove it from examples and docs to avoid encouring any new usage of it.
This updates the minimal supported version of CMake to 3.16, which in turn enables us to use more CMake features and have a cleaner build system.
This is the version that provides most new features and also the one we use in our latest docker image for CI.
RTC_CNTL_COCPU_SHUT_RESET_EN register was being reset during ULP RISC-V
initialization which does not let the ULP RISC-V coprocessor to reset
after it goes to halt. For proper operation of the coprocessor, it must
be reset after each cycle and hence this commit keeps
RTC_CNTL_COCPU_SHUT_RESET_EN set.
Moved the following kconfig options out of the target component:
* CONFIG_ESP*_DEFAULT_CPU_FREQ* -> esp_system
* ESP*_REV_MIN -> esp_hw_support
* ESP*_TIME_SYSCALL -> newlib
* ESP*_RTC_* -> esp_hw_support
Where applicable these target specific konfig names were merged into
a single common config, e.g;
CONFIG_ESP*_DEFAULT_CPU_FREQ -> CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ
Due to a hardware issue ULP support on S3 is temporarily disabled until a fixed is released.
Running ULP + sleep together can potentially cause permanent damage to the chip.
This commit enables ULP FSM support for esp32s3 and updates ULP FSM code
flow for other chips.
It adds C Macro support for the ULP FSM instruction set on esp32s2 and
esp32s3.
The unit tests are also updated to test ULP FSM on ep32s2 and esp32s3.
This commit refactors the ulp component.
Files are now divided based on type of ulp, viz., fsm or risc-v.
Files common to both are maintained in the ulp_common folder.
This commit also adds menuconfig options for ULP within the ulp
component instead of presenting target specific configuations for ulp.
riscv32-esp-elf toolchain (used for ESP32-C3) can also be used for
ESP32-S2 RISC-V ULP coprocessor.
This removes the riscv-none-embed-gcc toolchain which was originally
used for the ULP, and updates the docs and CMake files to use
riscv32-esp-elf.
Some flags are cleaned up and workarounds removed from CMake toolchain
file.
Sleep instruction removed from S2 instruction set.
LDx/STx instructions descritioin fix offset range to 13 bits (11 bits signed 32 bit words offset).
Remove I2C RD/WR operations from S2.
* changing dependencies from unity->cmock
* added component.mk and Makefile.projbuild
* ignore test dir in gen_esp_err_to_name.py
* added some brief introduction of CMock in IDF
!4452 used setting LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES to link
components built under ESP-IDF build system. However, LINK_LIBRARIES does
not produce behavior same as linking PRIVATE. This MR uses the new
signature for target_link_libraries directly instead. This also moves
setting dependencies during component registration rather than after all
components have been processed.
The consequence is that internally, components have to use the new
signature form as well. This does not affect linking the components to
external targets, such as with idf_as_lib example. This only affects
linking additional libraries to ESP-IDF libraries outside component processing (after
idf_build_process), which is not even possible for CMake<v3.13 as
target_link_libraries is not valid for targets not created in current
directory. See https://cmake.org/cmake/help/v3.13/policy/CMP0079.html#policy:CMP0079
This MR removes the common dependency from every IDF components to the SOC component.
Currently, in the ``idf_functions.cmake`` script, we include the header path of SOC component by default for all components.
But for better code organization (or maybe also benifits to the compiling speed), we may remove the dependency to SOC components for most components except the driver and kernel related components.
In CMAKE, we have two kinds of header visibilities (set by include path visibility):
(Assume component A --(depends on)--> B, B is the current component)
1. public (``COMPONENT_ADD_INCLUDEDIRS``): means this path is visible to other depending components (A) (visible to A and B)
2. private (``COMPONENT_PRIV_INCLUDEDIRS``): means this path is only visible to source files inside the component (visible to B only)
and we have two kinds of depending ways:
(Assume component A --(depends on)--> B --(depends on)--> C, B is the current component)
1. public (```COMPONENT_REQUIRES```): means B can access to public include path of C. All other components rely on you (A) will also be available for the public headers. (visible to A, B)
2. private (``COMPONENT_PRIV_REQUIRES``): means B can access to public include path of C, but don't propagate this relation to other components (A). (visible to B)
1. remove the common requirement in ``idf_functions.cmake``, this makes the SOC components invisible to all other components by default.
2. if a component (for example, DRIVER) really needs the dependency to SOC, add a private dependency to SOC for it.
3. some other components that don't really depends on the SOC may still meet some errors saying "can't find header soc/...", this is because it's depended component (DRIVER) incorrectly include the header of SOC in its public headers. Moving all this kind of #include into source files, or private headers
4. Fix the include requirements for some file which miss sufficient #include directives. (Previously they include some headers by the long long long header include link)
This is a breaking change. Previous code may depends on the long include chain.
You may need to include the following headers for some files after this commit:
- soc/soc.h
- soc/soc_memory_layout.h
- driver/gpio.h
- esp_sleep.h
The major broken include chain includes:
1. esp_system.h no longer includes esp_sleep.h. The latter includes driver/gpio.h and driver/touch_pad.h.
2. ets_sys.h no longer includes soc/soc.h
3. freertos/portmacro.h no longer includes soc/soc_memory_layout.h
some peripheral headers no longer includes their hw related headers, e.g. rom/gpio.h no longer includes soc/gpio_pins.h and soc/gpio_reg.h
BREAKING CHANGE
A problem if the Python interpreter used for idf.py (or set via PYTHON
variable) didn't match
"/usr/bin/env python" (or the associated executable for .py files, on
Windows).
Closes https://github.com/espressif/esp-idf/issues/3160
Possibly also fix for https://github.com/espressif/esp-idf/issues/2936
Adds build system test to catch any future direct execution of Python in
the standard build process.
Component which includes component_ulp_common.mk may also need to set
some of the same COMPONENT_XXX variables. Logically, we should combine
the lists of files to embed, ldflags, extra include dirs, etc.
Fixes https://github.com/espressif/esp-idf/issues/2157.
* Philosophical: "explicit is better than implicit".
* Practical: Allows useful errors if invalid directories given in components as the defaults aren't
always used. Also trims the -I path from a number of components that have no actual include
directory.
* Simplifies knowing which components will be header-only and which won't
When compiling
> const ulp_insn_t program[] = {
> I_DELAY(1)
> };
with the xtensa-esp32-elf-g++ compiler i always got the error:
> sorry, unimplemented: non-trivial designated initializers not supported
>
> };
This was due to the different order in the macro and the struct. The struct has another order of the fields (opcode, unused, cycles) vs (cycles, unused, opcode):
> struct {
> uint32_t cycles : 16; /*!< Number of cycles to sleep */
> uint32_t unused : 12; /*!< Unused */
> uint32_t opcode : 4; /*!< Opcode (OPCODE_DELAY) */
> } delay; /*!< Format of DELAY instruction */
After updating the order in the macro it is possible to compile with the g++ compiler.
Merges https://github.com/espressif/esp-idf/pull/1310
