esp-idf/components/hal
Armando 85ce6abdec Fix #10804 by running continuous ADC DMA in endless loop instead of restarting after each run (descriptor chain) to avoid losing samples. Use descriptor error callback for GDMA to check for DMA buffer overrun. 2023-09-05 11:18:56 +08:00
..
esp32 Merge branch 'feature/unicore_bootloader_can_run_multicore_app_v4.4' into 'release/v4.4' 2023-09-01 10:18:49 +08:00
esp32c3 fix(adc): fixed esp32, esp32s2,esp32s3 adc oneshot mode clk div issue 2023-07-12 17:24:19 +08:00
esp32h2 fix(adc): fixed esp32, esp32s2,esp32s3 adc oneshot mode clk div issue 2023-07-12 17:24:19 +08:00
esp32s2 fix(adc): fixed esp32, esp32s2,esp32s3 adc oneshot mode clk div issue 2023-07-12 17:24:19 +08:00
esp32s3 Merge branch 'feature/unicore_bootloader_can_run_multicore_app_v4.4' into 'release/v4.4' 2023-09-01 10:18:49 +08:00
include/hal Fix #10804 by running continuous ADC DMA in endless loop instead of restarting after each run (descriptor chain) to avoid losing samples. Use descriptor error callback for GDMA to check for DMA buffer overrun. 2023-09-05 11:18:56 +08:00
platform_port/include/hal C/Cxx: unify static assertions with the macro ESP_STATIC_ASSERT 2022-12-05 18:16:08 +08:00
test
CMakeLists.txt Merge branch 'feature/usb_host_feature_and_refactor_backports_v4.4' into 'release/v4.4' 2023-02-07 17:54:35 +08:00
Kconfig
README.md
adc_hal.c Fix #10804 by running continuous ADC DMA in endless loop instead of restarting after each run (descriptor chain) to avoid losing samples. Use descriptor error callback for GDMA to check for DMA buffer overrun. 2023-09-05 11:18:56 +08:00
aes_hal.c
component.mk usb_host: Rename struct/ll/hal files to use "usb_dwc" prefix 2022-12-13 21:36:00 +08:00
cpu_hal.c
dac_hal.c
ds_hal.c
efuse_hal.c efuse: Fix load_efuses_from_flash when FE is on 2023-03-29 16:18:54 +08:00
emac_hal.c esp_eth: possible start/stop issue fixed 2023-02-10 16:23:20 +01:00
gdma_hal.c
gpio_hal.c
i2c_hal.c I2C: put some interrupt used functions into IRAM, 2022-12-01 16:20:56 +08:00
i2c_hal_iram.c I2C: put some interrupt used functions into IRAM, 2022-12-01 16:20:56 +08:00
i2s_hal.c i2s: fixed I2S_mono_stereo_loopback_test (v4.4) 2023-04-07 11:17:07 +08:00
interrupt_controller_hal.c
lcd_hal.c
ledc_hal.c
ledc_hal_iram.c
linker.lf
mcpwm_hal.c
mpu_hal.c
pcnt_hal.c
rmt_hal.c
rtc_io_hal.c
sdio_slave_hal.c
sha_hal.c
sigmadelta_hal.c
soc_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
spi_hal_iram.c
spi_slave_hal.c
spi_slave_hal_iram.c spi: limit esp32 dma workaround only on esp32 2022-12-01 20:57:09 +08:00
spi_slave_hd_hal.c
systimer_hal.c
timer_hal.c
touch_sensor_hal.c
twai_hal.c twai: Add errata workaround for listen only mode 2023-02-24 20:26:53 +08:00
twai_hal_iram.c
uart_hal.c
uart_hal_iram.c
usb_dwc_hal.c usb_host: Restrict ESP32-S2 AHB errata workaround to only ECO0 chips 2023-08-22 15:43:39 +08:00
usb_hal.c
usb_phy_hal.c
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.