Fix dependency tree so that lwip doesn't depend on any specific network
interface component.
Network interface drivers shall depend on esp_netif.
esp_netif shall depend on lwip (but not on any specific interface
driver) -- it optionally depends on vfs and esp_eth (need ethernet
header for L2/bridge mode)
GPIO_HOLD_MASK array was missing the last item
Add __Static_assert to check array sizes for all gpio_periph.c files to prevent same mistake in the future.
All gpio hal and ll functions input arguments gpio_num_t are changed to uint32_t type.
Validation of gpio num should be guaranteed from the driver layer.
feat: new find_build_apps rules with centralized manifest file
Closes IDFCI-1061, IDF-3553, IDFCI-941, IDFCI-1359, and IDFCI-1361
See merge request espressif/esp-idf!18299
* Added C++ sentinels if missed
* Used #pragma once, removed macro's with leading underscores
* Updated copyright checker to allow "BSD-2-Clause-FreeBSD AND
Apache-2.0" for newlib files
* Fixed minor compilation issues/implicit inclusions
Previously psram driver was in esp_hw_support, which is a common
requirement(when in non-bootloader build). So when building
idf_as_lib (on esp32), the mfix-esp32-psram-cache-issue flag
will always be added (when CONFIG_SPIRAM_CACHE_WORKAROUND is on).
As psram driver is moved to esp_psram component, and esp_psram
is added via idf_component_optional_requires, which is a "weak"
dependency. You need to include esp_psram compoennt explicitly
if psram will be in use.
As idf_as_lib doesn't need psram, this test can be removed.
When ESP32-C2 is paired with a 26 MHz XTAL, the systimer tick
frequency becomes equal to 26 / 2.5 = 10.4 MHz. Previously we always
assumed that systimer tick frequency is integer (and 1 MHz * power of
two, above that!).
This commit introduces a new LL macro, SYSTIMER_LL_TICKS_PER_US_DIV.
It should be set in such a way that:
1. SYSTIMER_LL_TICKS_PER_US / SYSTIMER_LL_TICKS_PER_US_DIV equals the
actual systimer tick frequency,
2. and SYSTIMER_LL_TICKS_PER_US is integer.
For ESP32-C2 this means that SYSTIMER_LL_TICKS_PER_US = 52 and
SYSTIMER_LL_TICKS_PER_US_DIV = 5.
This introduced two possible issues:
1. Overflow when multiplying systimer counter by 5
- Should not be an issue, since systimer counter is 52-bit, so
counter * 5 is no more than 55-bit.
2. The code needs to perform:
- divide by 5: when converting from microseconds to ticks
- divide by 52: when converting from ticks to microseconds
The latter potentially introduces a performance issue for the
esp_timer_get_time function.