esp-idf/components/hal
wuzhenghui 4c78de50f4
fix(hal): fix PMU LL half word and byte access
2024-06-07 14:18:24 +08:00
..
esp32 fix(uart): Fix mismatch wakeup rising edges required with the threshold configured 2024-04-24 17:21:37 +08:00
esp32c2 fix(uart): Fix mismatch wakeup rising edges required with the threshold configured 2024-04-24 17:21:37 +08:00
esp32c3 feat(hal/usb): Update USB WRAP and USJ LL 2024-05-13 17:36:34 +08:00
esp32c6 fix(hal): fix PMU LL half word and byte access 2024-06-07 14:18:24 +08:00
esp32h2 fix(hal): fix PMU LL half word and byte access 2024-06-07 14:18:24 +08:00
esp32s2 feat(hal/usb): Update USB WRAP and USJ LL 2024-05-13 17:36:34 +08:00
esp32s3 feat(hal/usb): Update USB WRAP and USJ LL 2024-05-13 17:36:34 +08:00
include/hal refactor(usb/hcd): Allow port resets with allocated pipes 2024-06-02 00:29:35 +08:00
platform_port/include/hal fix(hal): Fix incorrect behavior of hal_memcpy 2023-11-03 15:49:35 +08:00
test
test_apps/ecc
.build-test-rules.yml
CMakeLists.txt refactor(hal/usb): Add new USB PHY related HAL API 2024-05-13 17:36:34 +08:00
Kconfig
README.md
adc_hal.c fix(adc): workaround to fix adc continuous get less results on c3 2024-02-21 13:54:29 +08:00
adc_hal_common.c
adc_oneshot_hal.c fix(adc): fix h2 adc oneshot read zero and add delay after getting done signal v5.1 2023-11-17 02:16:21 +00:00
aes_hal.c
apm_hal.c
brownout_hal.c fix(bod): Reset brownout in configuration to avoid RF cannot be enabled again 2023-12-07 10:33:58 +08:00
cache_hal.c
ds_hal.c
ecc_hal.c
ecdsa_hal.c feat(hal/ecdsa): Add HAL API for operation successful check 2024-04-12 11:14:10 +05:30
efuse_hal.c feat(pmu): set fix voltage to different mode for esp32h2 2024-01-26 11:39:16 +08:00
emac_hal.c
etm_hal.c
gdma_hal.c
gpio_hal.c
hmac_hal.c
i2c_hal.c
i2c_hal_iram.c
i2s_hal.c
lcd_hal.c
ledc_hal.c
ledc_hal_iram.c
linker.lf change(pm): put pmu_hal to iram 2024-01-16 14:01:22 +08:00
lp_timer_hal.c
mcpwm_hal.c
mmu_hal.c
mpu_hal.c
parlio_hal.c fix(parlio_tx): fix wrong dma descriptor setup 2023-09-27 14:53:53 +08:00
pcnt_hal.c
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.c
spi_flash_hal_common.inc
spi_flash_hal_gpspi.c
spi_flash_hal_iram.c
spi_hal.c fix(spi): fixed undesired touching to DMA 2023-10-31 15:52:26 +08:00
spi_hal_iram.c
spi_slave_hal.c fix(spi): fixed undesired touching to DMA 2023-10-31 15:52:26 +08:00
spi_slave_hal_iram.c
spi_slave_hd_hal.c fix(spi): fixed undesired touching to DMA 2023-10-31 15:52:26 +08:00
systimer_hal.c
timer_hal.c
touch_sensor_hal.c
twai_hal.c
twai_hal_iram.c
uart_hal.c
uart_hal_iram.c
usb_dwc_hal.c feat(usb/host): Update ISOC scheduler for HS endpoints 2024-03-04 09:59:50 +01:00
usb_serial_jtag_hal.c refactor(hal/usb): Add new USB PHY related HAL API 2024-05-13 17:36:34 +08:00
usb_wrap_hal.c refactor(hal/usb): Add new USB PHY related HAL API 2024-05-13 17:36:34 +08:00
wdt_hal_iram.c
xt_wdt_hal.c

README.md

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.