esp-idf/components/hal
Ivan Grokhotkov 17214c2db6 hal: fix CONFIG_TWAI_ISR_IN_IRAM not taking effect for C3/H2 2022-09-21 08:35:54 +00:00
..
esp32 Merge branch 'bugfix/spi_hd_quad_issue_4.4' into 'release/v4.4' 2022-09-21 12:06:40 +08:00
esp32c3 Merge branch 'bugfix/spi_hd_quad_issue_4.4' into 'release/v4.4' 2022-09-21 12:06:40 +08:00
esp32h2 Merge branch 'bugfix/spi_hd_quad_issue_4.4' into 'release/v4.4' 2022-09-21 12:06:40 +08:00
esp32s2 Merge branch 'bugfix/spi_hd_quad_issue_4.4' into 'release/v4.4' 2022-09-21 12:06:40 +08:00
esp32s3 Merge branch 'bugfix/spi_hd_quad_issue_4.4' into 'release/v4.4' 2022-09-21 12:06:40 +08:00
include/hal Merge branch 'bugfix/spi_hd_quad_issue_4.4' into 'release/v4.4' 2022-09-21 12:06:40 +08:00
platform_port/include/hal ulp-riscv: add support for using ADC as well as an example show-casing it. 2022-08-09 09:21:15 +08:00
test
CMakeLists.txt adc_cal: fixed the assertion failure or returning wrong error code when ADC2 failed the arbitration 2022-03-28 10:23:48 +00:00
Kconfig
README.md
adc_hal.c adc: fix esp32 continuous mode sampling freq issue 2022-07-20 16:43:38 +08:00
aes_hal.c
component.mk usb: Add usb_phy driver to support operations on USB PHY 2021-09-13 12:39:56 +08:00
cpu_hal.c
dac_hal.c
ds_hal.c
emac_hal.c esp_eth: EMAC start/stop optimization 2022-03-10 10:15:34 +01:00
gdma_hal.c
gpio_hal.c
i2c_hal.c i2c: Correct hal functions iram placement and remove IRAM_ATTR for i2c_hw_fsm_reset 2022-04-18 22:24:47 +08:00
i2c_hal_iram.c i2c: Correct hal functions iram placement and remove IRAM_ATTR for i2c_hw_fsm_reset 2022-04-18 22:24:47 +08:00
i2s_hal.c i2s: fix PDM TX stereo mode for c3 and s3 2022-08-09 18:28:09 +08:00
interrupt_controller_hal.c
lcd_hal.c lcd: unify callback prototype 2021-10-02 14:23:31 +08:00
ledc_hal.c LEDC: improved support for ESP32-C3 and refactored divisor calculation 2022-02-10 16:54:00 +08:00
ledc_hal_iram.c
linker.lf hal: fix CONFIG_TWAI_ISR_IN_IRAM not taking effect for C3/H2 2022-09-21 08:35:54 +00:00
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 esp_flash: add opi flash support in esp_flash chip driver, for MXIC 2021-09-07 14:44:40 +08:00
spi_flash_hal_common.inc spi_flash: remove back-compatible with caller function of S3Beta ROM 2022-06-14 19:30:59 +08:00
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_slave_hd_hal.c
systimer_hal.c
timer_hal.c driver: fix timer driver initialization sequence to not trigger interrupt immediately 2021-09-16 19:45:33 +08:00
touch_sensor_hal.c
twai_hal.c
twai_hal_iram.c
uart_hal.c
uart_hal_iram.c
usb_hal.c
usb_phy_hal.c usb: Add usb_phy driver to support operations on USB PHY 2021-09-13 12:39:56 +08:00
usbh_hal.c usb: USB Host stack uses USB PHY driver 2022-02-18 15:51:05 +08:00
wdt_hal_iram.c
xt_wdt_hal.c WDT: Add support for XTAL32K Watchdog timer 2021-09-02 09:09:00 +08:00

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.