esp-idf/components/hal
Kevin (Lao Kaiyao) cf54ebc9c1 Merge branch 'feature/support_parlio_tx_on_p4' into 'master'
feat(parlio_tx): supported parlio tx on p4

Closes IDF-7472

See merge request espressif/esp-idf!25365
2023-09-27 12:33:34 +08:00
..
esp32 Merge branch 'feature/support_cache_p4' into 'master' 2023-09-25 15:21:46 +08:00
esp32c2 feat(cache): support cache driver on esp32p4 2023-09-22 14:19:41 +08:00
esp32c3 feat(cache): support cache driver on esp32p4 2023-09-22 14:19:41 +08:00
esp32c6 Merge branch 'feature/support_parlio_tx_on_p4' into 'master' 2023-09-27 12:33:34 +08:00
esp32h2 Merge branch 'feature/support_parlio_tx_on_p4' into 'master' 2023-09-27 12:33:34 +08:00
esp32p4 Merge branch 'feature/support_parlio_tx_on_p4' into 'master' 2023-09-27 12:33:34 +08:00
esp32s2 Merge branch 'feature/support_cache_p4' into 'master' 2023-09-25 15:21:46 +08:00
esp32s3 Merge branch 'feature/support_cache_p4' into 'master' 2023-09-25 15:21:46 +08:00
include/hal Merge branch 'feature/support_cache_p4' into 'master' 2023-09-25 15:21:46 +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 fix: remove wno format in hal component 2023-09-18 02:43:41 +00:00
test_apps refactor(hal): use hal utils to calculate clock division 2023-09-20 23:33:25 +08:00
.build-test-rules.yml refactor(hal): use hal utils to calculate clock division 2023-09-20 23:33:25 +08:00
CMakeLists.txt feat(hal): add hal utils for clock divider calculation 2023-09-20 23:32:06 +08:00
Kconfig
README.md fix(adc): invalid assertion on the adc_unit 2023-08-23 18:36:02 +08:00
adc_hal.c refactor(hal): use hal utils to calculate clock division 2023-09-20 23:33:25 +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_oneshot_hal.c fix: remove wno format in hal component 2023-09-18 02:43:41 +00: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
brownout_hal.c
cache_hal.c change(cache): swap cache hal arg 'type' and 'level' 2023-09-22 14:19:41 +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
ecdsa_hal.c feat(ecdsa): add ECDSA peripheral support for esp32p4 2023-09-06 11:07:37 +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
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 feat(gdma): support hardware crc calculation 2023-08-31 02:11:47 +00:00
gdma_hal_axi.c feat(gdma): support hardware crc calculation 2023-08-31 02:11:47 +00:00
gdma_hal_crc_gen.c feat(gdma): support hardware crc calculation 2023-08-31 02:11:47 +00:00
gdma_hal_top.c feat(gdma): support hardware crc calculation 2023-08-31 02:11:47 +00:00
gpio_hal.c feat(gpio): add support for ESP32P4 2023-08-10 17:58:49 +08:00
hal_utils.c refactor(hal): use hal utils to calculate clock division 2023-09-20 23:33:25 +08:00
hmac_hal.c
i2c_hal.c feat(i2c): Add I2C driver support for esp32p4 2023-08-11 12:37:11 +08:00
i2c_hal_iram.c feat(i2c): Add new API and implementation for I2C driver 2023-08-10 11:55:54 +08:00
i2s_hal.c refactor(hal): use hal utils to calculate clock division 2023-09-20 23:33:25 +08:00
lcd_hal.c refactor(hal): use hal utils to calculate clock division 2023-09-20 23:33:25 +08:00
ledc_hal.c
ledc_hal_iram.c
linker.lf feat(uart): Add sdkconfig.ci.iram_safe test for UART driver 2023-08-30 11:30:03 +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
mmu_hal.c feat(cache): support cache driver on esp32p4 2023-09-22 14:19:41 +08:00
mpi_hal.c
mpu_hal.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
parlio_hal.c feat(parlio_tx): supported parlio tx on p4 2023-09-25 10:42:30 +08:00
pcnt_hal.c
rmt_hal.c feat(rmt): add driver support for esp32p4 2023-09-19 12:54:14 +08:00
rtc_io_hal.c feat(lp_io): Add support for ESP32P4 2023-09-20 19:39:41 +08:00
sdio_slave_hal.c fix: remove wno format in hal component 2023-09-18 02:43:41 +00:00
sdkconfig.rename
sdm_hal.c
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.c
spi_flash_hal_common.inc fix(spi_flash): Fix spi_flash write fail on 26M C2(including OTA fail on this chip) 2023-09-07 17:30:15 +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_hal.c fix(all): unify default mosi level to low on all targets 2023-07-24 15:45:21 +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_slave_hal.c feat(esp_gdma): add hal interface for common operations 2023-07-10 13:45:57 +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_hd_hal.c feat(esp_gdma): add hal interface for common operations 2023-07-10 13:45:57 +08:00
systimer_hal.c feat(esp_timer): Support systimer for ESP32P4 2023-09-13 19:13:38 +08:00
timer_hal.c feat(mcpwm): MCPWM event comparator driver 2023-09-11 16:53:34 +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.c
twai_hal_iram.c
uart_hal.c uart: Support LP_UART port with UART driver on esp32c6 2023-06-16 07:31:40 +00:00
uart_hal_iram.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08: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
wdt_hal_iram.c
xt_wdt_hal.c

README.md

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.

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. ↩︎