esp-idf/components/hal
2023-08-24 12:51:19 +08:00
..
esp32 feat(gptimer): use RCC atomic block to enable/reset peripheral 2023-08-22 17:05:35 +08:00
esp32c2 feat(gptimer): use RCC atomic block to enable/reset peripheral 2023-08-22 17:05:35 +08:00
esp32c3 feat(gptimer): use RCC atomic block to enable/reset peripheral 2023-08-22 17:05:35 +08:00
esp32c6 feat(gptimer): use RCC atomic block to enable/reset peripheral 2023-08-22 17:05:35 +08:00
esp32h2 feat(gptimer): use RCC atomic block to enable/reset peripheral 2023-08-22 17:05:35 +08:00
esp32p4 feat(gptimer): use RCC atomic block to enable/reset peripheral 2023-08-22 17:05:35 +08:00
esp32s2 feat(gptimer): use RCC atomic block to enable/reset peripheral 2023-08-22 17:05:35 +08:00
esp32s3 feat(gptimer): use RCC atomic block to enable/reset peripheral 2023-08-22 17:05:35 +08:00
include/hal docs(hal): update readme about the usage of the RCC macros 2023-08-22 17:05:35 +08:00
platform_port/include/hal fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
test esp32h2: add build test 2023-01-17 10:29:04 +08:00
test_apps/crypto feat(ci): Enable p4 example, test_apps and unit tests CI build 2023-08-24 12:51:19 +08:00
adc_hal_common.c adc_cali: supported channel compensation of adc calibration on esp32c6 2023-05-23 22:44:25 +08:00
adc_hal.c feat(esp_gdma): add hal interface for common operations 2023-07-10 13:45:57 +08:00
adc_oneshot_hal.c adc: remove adc_hal_conf.h 2023-02-23 11:48:31 +08:00
aes_hal.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
apm_hal.c apm: added support for APM on esp32c6 2023-02-10 08:18:07 +00:00
brownout_hal.c brownout: Disable the hardware BOD when BOD interrupt is enabled 2023-04-21 10:22:59 +08:00
cache_hal.c refactor(cache): abstract cache rom API in cache_ll.h 2023-08-09 10:32:12 +00:00
CMakeLists.txt Merge branch 'feature/esp_gdma_ops' into 'master' 2023-07-11 10:40:42 +08:00
ds_hal.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
ecc_hal.c esp32h2: Add support for ECC hardware accelerator 2023-03-13 16:39:46 +05:30
ecdsa_hal.c ecdsa: Support multiple ECDSA keys 2023-04-07 14:55:21 +05:30
efuse_hal.c adc_cali: supported channel compensation of adc calibration on esp32c6 2023-05-23 22:44:25 +08:00
emac_hal.c driver: minor code clean up to pass coverity scan test 2023-06-10 16:21:12 +08:00
etm_hal.c etm: added etm channel allocator 2022-11-23 15:31:33 +08:00
gdma_hal_ahb_v1.c fix(gdma): fixed compilation failure of gdma 2023-07-24 19:36:31 +08:00
gdma_hal_ahb_v2.c fix(gdma): fixed compilation failure of gdma 2023-07-24 19:36:31 +08:00
gdma_hal_axi.c fix(gdma): fixed compilation failure of gdma 2023-07-24 19:36:31 +08:00
gdma_hal_top.c fix(gdma): fixed compilation failure of gdma 2023-07-24 19:36:31 +08:00
gpio_hal.c feat(gpio): add support for ESP32P4 2023-08-10 17:58:49 +08:00
hmac_hal.c hmac_hal: Merge hmac hal layer for different into one 2022-11-24 16:04:26 +05:30
i2c_hal_iram.c feat(i2c): Add new API and implementation for I2C driver 2023-08-10 11:55:54 +08:00
i2c_hal.c feat(i2c): Add I2C driver support for esp32p4 2023-08-11 12:37:11 +08:00
i2s_hal.c i2s: fixed i2s_ll compiling failure under C++ evironment 2023-06-23 11:41:43 +08:00
Kconfig spi: change linker file let spi hal able to out from iram 2023-04-21 18:58:36 +08:00
lcd_hal.c rgb_lcd: workaround pclk polarity bug by setting mo>=2 2022-07-21 13:06:09 +00:00
ledc_hal_iram.c ledc: Add an all-in-one HAL function to set fade parameters, and refactor ledc_ll_get_max_duty function 2023-04-21 16:40:54 +08:00
ledc_hal.c ledc: Add an all-in-one HAL function to set fade parameters, and refactor ledc_ll_get_max_duty function 2023-04-21 16:40:54 +08:00
linker.lf feat(twai): Add twai linker.lf to control the placement of driver and hal 2023-08-07 10:21:47 +08:00
lp_timer_hal.c Power Management: move lp_timer_hal.c to upper hal layer for esp32h2 and esp32c6 2023-06-26 21:05:16 +08:00
mcpwm_hal.c mcpwm: clean up hal driver and add doc 2022-06-02 15:01:18 +08:00
mmu_hal.c feat(mmu): support mmu and flash mmap driver on p4 2023-08-15 10:17:03 +08:00
mpi_hal.c bignum: refactored the hardware abstraction of the mpi peripheral 2023-04-24 16:15:11 +05:30
mpu_hal.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
parlio_hal.c driver: add parallel IO TX driver 2023-03-01 00:43:14 +00:00
pcnt_hal.c pulse_cnt: new driver for PCNT peripheral 2022-03-03 22:38:32 +08:00
README.md docs(hal): update readme about the usage of the RCC macros 2023-08-22 17:05:35 +08:00
rmt_hal.c rmt: support esp32c6 2022-09-17 04:56:49 +00:00
rtc_io_hal.c refactor(driver/rtcio): Re-wrap RTCIO APIs with more accurate soc_caps 2023-07-05 11:47:51 +08:00
sdio_slave_hal.c sdio_slave: fix strict aliasing violation for sdio_ringbuf_recv() 2023-01-19 13:21:27 +07:00
sdkconfig.rename HAL: fix kconfig HAL_ASSERTION typo 2022-06-13 16:19:28 +08:00
sdm_hal.c sdm: clean up soc/hal/ll code 2022-07-20 14:59:50 +08:00
sha_hal.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
spi_flash_encrypt_hal_iram.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
spi_flash_hal_common.inc spi_flash: 2nd stage for supporting flash suspend. (1). Support more esp chips (2). Improve real-time performance (3). Making timing more stable (4) Add documents 2023-05-11 20:10:30 +08:00
spi_flash_hal_gpspi.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
spi_flash_hal_iram.c spi_flash: 2nd stage for supporting flash suspend. (1). Support more esp chips (2). Improve real-time performance (3). Making timing more stable (4) Add documents 2023-05-11 20:10:30 +08:00
spi_flash_hal.c spi_flash: 2nd stage for supporting flash suspend. (1). Support more esp chips (2). Improve real-time performance (3). Making timing more stable (4) Add documents 2023-05-11 20:10:30 +08:00
spi_hal_iram.c fix(all): unify default mosi level to low on all targets 2023-07-24 15:45:21 +08:00
spi_hal.c fix(all): unify default mosi level to low on all targets 2023-07-24 15:45:21 +08:00
spi_slave_hal_iram.c fix(all): unify default mosi level to low on all targets 2023-07-24 15:45:21 +08:00
spi_slave_hal.c feat(esp_gdma): add hal interface for common operations 2023-07-10 13:45:57 +08:00
spi_slave_hd_hal.c feat(esp_gdma): add hal interface for common operations 2023-07-10 13:45:57 +08:00
systimer_hal.c systimer: support etm event 2022-11-23 15:32:34 +08:00
timer_hal.c feat(gptimer): use RCC atomic block to enable/reset peripheral 2023-08-22 17:05:35 +08:00
touch_sensor_hal.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
twai_hal_iram.c twai: bringup on esp32c6 2022-11-04 17:40:29 +08:00
twai_hal.c twai: Add errata workaround for listen only mode 2023-02-23 12:50:06 +08:00
uart_hal_iram.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
uart_hal.c uart: Support LP_UART port with UART driver on esp32c6 2023-06-16 07:31:40 +00:00
usb_dwc_hal.c usb_host: Restrict ESP32-S2 AHB errata workaround to only ECO0 chips 2023-07-13 12:37:35 +02:00
usb_hal.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
usb_phy_hal.c usb: Add usb_phy driver to support operations on USB PHY 2021-09-13 12:39:56 +08:00
wdt_hal_iram.c wdt: refactor wdt codes to use unified type 2023-02-15 12:08:55 +08:00
xt_wdt_hal.c WDT: Add support for XTAL32K Watchdog timer 2021-09-02 09:09:00 +08:00

hal (G0 component)

⚠️ The HAL component is still under heavy development at the moment, so we don't guarantee the stability and backward-compatibility among versions.

The hal component provides a Hardware Abstraction Layer for all targets supported by ESP-IDF. It is designed to be a G0 component so that it can be used by other components like driver, esp_hw_support, esp_system and so on.

In a broad sense, the HAL layer consists of two sub-layers: HAL (upper) and Low-Level(bottom). The HAL layer defines the steps and data that is required to operate a peripheral (e.g. initialization, start and stop). The low-level is a translation layer above the register files under the soc component, it only covers general conceptions to register configurations.

Low-Level (hal/<periph>_ll.h)

Functions defined in the file must be static inlined. The first argument of an LL function is usually a pointer to the peripheral's base address 1. At the moment, each ESP target has its own set of Low-Level drivers. They're located under path e.g. components/hal/<target>/include/hal/<periph>_ll.h. We wish the the low-level functions could be as independent as possible, so that the caller doesn't need to worry about conflict between different sub-modules. For example, when resetting the driver of module A, the module B is also reset by accident. However, the digital design is not perfect, coupling happens from time to time.

Handling Shared Registers

One of the biggest coupling is the so-called "hardware shared resource". Take the common Reset and Clock Control part as an example, the clock enable and disable logic of different peripherals are mixing in the same register. In RTOS environment, it's super easy to make a mistake when you enable peripheral A and then peripheral B is disabled by accident. A simple way to avoid such mistake is to using a critical section when accessing such shared registers. However from the point of the software architecture, it's not a good idea to add a lock in the Low-Level because it's a concept of the operating system.

One compromise is to highlight the LL function which needs the caller to use them in a critical section. e.g.

/// use a macro to wrap the function, force the caller to use it in a critical section
/// the critical section needs to declare the __DECLARE_RCC_RC_ATOMIC_ENV variable in advance
#define timer_ll_reset_register(...) (void)__DECLARE_RCC_RC_ATOMIC_ENV; timer_ll_reset_register(__VA_ARGS__)

/// use a macro to wrap the function, force the caller to use it in a critical section
/// the critical section needs to declare the __DECLARE_RCC_ATOMIC_ENV variable in advance
#define timer_ll_set_clock_source(...) (void)__DECLARE_RCC_ATOMIC_ENV; timer_ll_set_clock_source(__VA_ARGS__)

By referencing a variable which is only declared in the critical section, the compiler will report an error if the caller forgets to use the critical section. The following macros are provided by esp_private/periph_ctrl.h, which contain the above magic variables.

Macro Private variables used to declare a critical section Use condition
PERIPH_RCC_ACQUIRE_ATOMIC __DECLARE_RCC_RC_ATOMIC_ENV This critical section not only protects the shared register accessing, but also increases a reference counter of the peripheral module.
You should use this critical section if the peripheral module has multiple independent sub-modules.
PERIPH_RCC_RELEASE_ATOMIC __DECLARE_RCC_RC_ATOMIC_ENV This critical section not only protects the shared register accessing, but also decreases a reference counter of the peripheral module.
You should use this critical section if the peripheral module has multiple independent sub-modules.
PERIPH_RCC_ATOMIC __DECLARE_RCC_ATOMIC_ENV This critical section only protects the shared register accessing.

ESP-IDF driver developers then can use the above macros to call the special LL functions. e.g.

static void enable_timer_group0_for_calibration(void)
{
    PERIPH_RCC_ACQUIRE_ATOMIC(PERIPH_TIMG0_MODULE, ref_count) {
        if (ref_count == 0) {
            timer_ll_enable_bus_clock(0, true);
            timer_ll_reset_register(0);
        }
    }
}

HAL (hal/<periph>_hal.h)

This layer is a combination of Low-Level function calls, aiming to ease the load when porting a new chip to other platforms (e.g. Zephyr). This layer shouldn't rely on Operating System, i.e., don't use primitives that only offered by an Operating System, e.g., the lock and other blocking functions. Please don't introduce any driver models in the HAL layer so that the non-idf developers can customized their own drivers according to their platform requirement.

The first argument of a HAL function is usually a pointer to the context object. The context object is a structure which saves the necessary information that is used by the HAL driver (e.g. the base address of the peripheral). Please note, the memory used by the HAL context object is allocated by the caller, so the HAL driver shouldn't free it.

File Structure

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 interacting 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 sometimes 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 preprocessor. 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.


  1. This is not a must. Sometimes if the LL is just operating some system level registers, you don't have to provide this argument. ↩︎