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
- RTC_CNTL_SLOWCLK_FREQ define is removed; rtc_clk_slow_freq_get_hz
function can be used instead to get an approximate RTC_SLOW_CLK
frequency
- Clock calibration is performed at startup. The value is saved and used
for timekeeping and when entering deep sleep.
- When using the 32k XTAL, startup code will wait for the oscillator to
start up. This can be possibly optimized by starting a separate task
to wait for oscillator startup, and performing clock switch in that
task.
- Fix a bug that 32k XTAL would be disabled in rtc_clk_init.
- Fix a rounding error in rtc_clk_cal, which caused systematic frequency
error.
- Fix an overflow bug which caused rtc_clk_cal to timeout early if the
slow_clk_cycles argument would exceed certain value
- Improve 32k XTAL oscillator startup time by introducing bootstrapping
code, which uses internal pullup/pulldown resistors on 32K_N/32K_P
pins to set better initial conditions for the oscillator.
This fixes incorrect descriptions of I_END/I_SLEEP instructions and
changes the definition of I_END. New instruction, I_WAKE, is added,
which wakes up the SoC. Macro for ADC instruction is defined, and new
tests are added.
- I_RD_REG used the wrong union member (.rd_reg) due to a copy-paste
mistake
- Peripheral register address in bits[7:0] should be given in words,
not in bytes
Fixes https://github.com/espressif/esp-idf/issues/297
Starting the ULP using SENS_SAR_START_FORCE_REG doesn’t disable clock gating of RTC fast clock.
When SoC goes into deep sleep mode, RTC fast clock gets gated, so ULP can no longer run.
Instead, it has to be started using the timer (RTC_CNTL_ULP_CP_SLP_TIMER_EN bit).
When ULP is enabled by the timer, clock also gets enabled.
feature(rtc_module):add rtc module
1. add rtc io control API (pull,output and input)
2. add touch pad API (touch pad read and interrupt)
3. add adc1 API (the max width is 12 Bits and support attenuation)
4. add hall sensor API (support hall sensor read )
5. add dac API (the width is 8 Bits)
bugfix(gpio):gpio32 and gpio33 can not output and input
the gpio32 and gpio33 is initialize by librtc.a,and gpio_config not initialize the gpio as
digital gpio.they can not output and input,when users use gpio32 or gpio33.And there are some problems
about others driver ,when they use gpio32 or gpio33 as matrix.
