200f69e6eb
modem retention: Support esp32c6 wifi MAC and baseband sleep retention sleep_modem: wifi MAC modem wakeup protect in modem state before PMU trigger sleep enable request sleep modem: provide a interface to get whether the Modem power domain is allowed to power off during sleep add i2c_ana master header file to project auto beacon: release PMU's lock on root clock source (it is locked in the PLL) wifi receiving beacon frame in PMU modem state strongly depends on the BBPLL clock, PMU will forcibly lock the root clock source as PLL, when the root clock source of the software system is selected as PLL, we need to release the root clock source locking. When it is judged that the PLL is locked by PMU after wakeing up from the PMU modem state, switch the root clock source to the PLL in the sleep process (a critical section). auto beacon: fix the failure to receive broadcast/multicast frames in modem state When the multicast field in the beacon frame received in the PMU modem state is True, the PMU switches to the PMU active state (the PMU waits for the HP LDO to stabilize and then restores the MAC context) and starts to receive broadcast/multicast frames (Broadcast/Multicast frames will be sent after a minimum delay of 48 us after the beacon frame), because the PMU waits for the HP LDO to stabilize too long (~154 us), which will cause broadcast/multicast frame reception to be missed. auto beacon: select the PLL clock source as the REGDMA backup clock source when the PMU switches to ACTIVE from MODEM state update Digital Peripheral (M2A switch) REGDMA restore time parameter auto beacon: fix the issue that only channel 1 can connect to AP in modem state |
||
|---|---|---|
| .. | ||
| esp32 | ||
| esp32c2 | ||
| esp32c3 | ||
| esp32c6 | ||
| esp32h2 | ||
| esp32h4 | ||
| esp32s2 | ||
| esp32s3 | ||
| include/hal | ||
| platform_port/include/hal | ||
| test | ||
| adc_hal_common.c | ||
| adc_hal.c | ||
| adc_oneshot_hal.c | ||
| aes_hal.c | ||
| apm_hal.c | ||
| brownout_hal.c | ||
| cache_hal.c | ||
| CMakeLists.txt | ||
| ds_hal.c | ||
| ecc_hal.c | ||
| efuse_hal.c | ||
| emac_hal.c | ||
| etm_hal.c | ||
| gdma_hal.c | ||
| gpio_hal.c | ||
| hmac_hal.c | ||
| i2c_hal_iram.c | ||
| i2c_hal.c | ||
| i2s_hal.c | ||
| Kconfig | ||
| lcd_hal.c | ||
| ledc_hal_iram.c | ||
| ledc_hal.c | ||
| linker.lf | ||
| mcpwm_hal.c | ||
| mmu_hal.c | ||
| mpu_hal.c | ||
| parlio_hal.c | ||
| pcnt_hal.c | ||
| README.md | ||
| rmt_hal.c | ||
| rtc_io_hal.c | ||
| sdio_slave_hal.c | ||
| sdkconfig.rename | ||
| sdm_hal.c | ||
| sha_hal.c | ||
| spi_flash_encrypt_hal_iram.c | ||
| spi_flash_hal_common.inc | ||
| spi_flash_hal_gpspi.c | ||
| spi_flash_hal_iram.c | ||
| spi_flash_hal.c | ||
| spi_hal_iram.c | ||
| spi_hal.c | ||
| spi_slave_hal_iram.c | ||
| spi_slave_hal.c | ||
| spi_slave_hd_hal.c | ||
| systimer_hal.c | ||
| timer_hal_iram.c | ||
| timer_hal.c | ||
| touch_sensor_hal.c | ||
| twai_hal_iram.c | ||
| twai_hal.c | ||
| uart_hal_iram.c | ||
| uart_hal.c | ||
| usb_dwc_hal.c | ||
| usb_hal.c | ||
| usb_phy_hal.c | ||
| wdt_hal_iram.c | ||
| xt_wdt_hal.c | ||
hal
The hal component provides hardware abstraction and implementation for targets supported by ESP-IDF.
include/hal
/include/hal contains header files which provides a hardware-agnostic interface to the SoC. The interface consists of function declarations and abstracted types that other, higher level components can make use of in order to have code portable to all targets ESP-IDF supports.
It contains an abstraction layer for ineracting with/driving the hardware found in the SoC such as the peripherals and 'core' hardware such as the CPU, MPU, caches, etc. It contains for the abstracted types.
The abstraction design is actually two levels -- often somtimes xxx_hal.h includes a lower-level header from a xxx_ll.h, which resides in the implementation. More on this abstraction design in the hal/include/hal's Readme
target/include
Provides the implementation of the hardware-agnostic interface in the abstraction. Target-specific subdirectories exist for wildly different implementations among targets; while code that are common/very similar might be placed in the top-level of /<target>/include, using some amount of conditional preprocessors. It is up to the developers' discretion on which strategy to use. Code usually reside in source files with same names to header files whose interfaces they implement, ex. xxx_hal.c for xxx_hal.h.
As mentioned previously, the lower-level abstraction header xxx_ll.h resides in this directory, since they contain hardware-specific details.
However, what these can do is provide some abstraction among implementations, so that more code can be moved to the common, non-target-specific subdirectories.
This can also contain target-specific extensions to the HAL headers. These target-specific HAL headers have the same name and include the abstraction layer HAL header via include_next. These extensions might add more function declarations or override some things using macro magic.