esp-idf/components/hal
2024-04-08 17:48:20 +08:00
..
esp32 change(gptimer): use private unsafe RCC LL functions in bootloader 2024-04-08 17:48:20 +08:00
esp32c2 change(gptimer): use private unsafe RCC LL functions in bootloader 2024-04-08 17:48:20 +08:00
esp32c3 change(gptimer): use private unsafe RCC LL functions in bootloader 2024-04-08 17:48:20 +08:00
esp32c5 change(gptimer): use private unsafe RCC LL functions in bootloader 2024-04-08 17:48:20 +08:00
esp32c6 change(gptimer): use private unsafe RCC LL functions in bootloader 2024-04-08 17:48:20 +08:00
esp32c61 change(gptimer): use private unsafe RCC LL functions in bootloader 2024-04-08 17:48:20 +08:00
esp32h2 change(gptimer): use private unsafe RCC LL functions in bootloader 2024-04-08 17:48:20 +08:00
esp32p4 change(gptimer): use private unsafe RCC LL functions in bootloader 2024-04-08 17:48:20 +08:00
esp32s2 change(gptimer): use private unsafe RCC LL functions in bootloader 2024-04-08 17:48:20 +08:00
esp32s3 change(gptimer): use private unsafe RCC LL functions in bootloader 2024-04-08 17:48:20 +08:00
include/hal Merge branch 'feature/support_lp_i2c_in_drv' into 'master' 2024-04-07 19:27:04 +08:00
platform_port/include/hal fix(hal): use __builtin_unreachable in no-assert mode 2024-03-06 11:50:32 +08:00
test_apps ci(esp32c5mp): disable the unsupported tests 2024-04-07 12:13:29 +08:00
.build-test-rules.yml feat: re enables tests on p4 2024-03-05 17:48:05 +08:00
adc_hal_common.c
adc_hal.c refactor(adc): refactor dma ll functions on adc continuous mode 2024-03-12 11:12:48 +08:00
adc_oneshot_hal.c fix(adc): fix h2 adc oneshot read zero and add delay after getting done signal 2023-11-13 14:48:40 +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: updated APM HAL/LL APIs. 2023-10-17 18:20:36 +05:30
brownout_hal.c fix(bod): Reset brownout in configuration to avoid RF cannot be enabled again 2023-11-24 10:17:20 +08:00
cache_hal.c Use configuration option instead of in components not related to FreeRTOS 2023-11-28 07:49:20 +00:00
CMakeLists.txt refactor(hal/usb): Add new USB PHY related HAL API 2024-04-04 02:47:00 +08:00
color_hal.c feat(esp_hw_support/dma2d): Add 2D-DMA support on ESP32P4 2024-01-22 20:51:43 +08:00
dma2d_hal.c feat(esp_hw_support/dma2d): Add 2D-DMA support on ESP32P4 2024-01-22 20:51:43 +08:00
ds_hal.c fix(hal): check the public header files and fix violations 2023-07-05 17:33:32 +08:00
dw_gdma_hal.c feat(dw_gdma): channel allocator driver 2023-12-12 03:35:05 +00:00
ecc_hal.c
ecdsa_hal.c feat(hal): Add LL and HAL layer support for deterministic ECDSA 2024-03-29 12:14:11 +05:30
efuse_hal.c feat(pmu): set fix voltage to different mode for esp32h2 2024-01-24 13:11:41 +08:00
emac_hal.c feat(esp_eth): Added support of internal EMAC for ESP32P4 2024-01-16 14:29:25 +01:00
etm_hal.c
gdma_hal_ahb_v1.c feat(gdma): support ETM subsystem on esp32p4 2023-12-06 18:02:43 +08:00
gdma_hal_ahb_v2.c feat(gdma): support ETM subsystem on esp32p4 2023-12-06 18:02:43 +08:00
gdma_hal_axi.c feat(gdma): support ETM subsystem on esp32p4 2023-12-06 18:02:43 +08: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 ETM subsystem on esp32p4 2023-12-06 18:02:43 +08:00
gpio_hal.c feat(gpio): add support for ESP32P4 2023-08-10 17:58:49 +08:00
hal_utils.c feat(dma): refactor dma calloc function 2024-04-02 14:30:14 +08:00
hmac_hal.c
huk_hal.c feat(hal): Update HAL layer for Key manager 2024-01-23 10:24:37 +05:30
i2c_hal_iram.c refactor(i2c): Make i2c driver as a seperate component 2023-12-14 15:39:35 +08:00
i2c_hal.c feat(i2c_master): Add parameter to config I2C scl await time 2024-03-27 10:35:11 +08:00
i2s_hal.c fix(i2s): add rcc trick for some ll functions 2023-12-22 19:40:38 +08:00
isp_hal.c feat(isp): isp af submodule low level driver 2023-10-30 17:32:46 +08:00
jpeg_hal.c feat(jpeg_encoder): Add the basic support for jpeg encoder 2024-04-01 20:03:31 +08:00
Kconfig
key_mgr_hal.c fix(esp_hw_support): Update key manager support 2024-01-23 10:24:39 +05:30
lcd_hal.c feat(lcd): pre-support rgb and i80 lcd driver on esp32p4 2023-11-21 10:46:52 +08:00
ledc_hal_iram.c feat(ledc): support ledc on esp32p4 2023-10-17 16:40:04 +08:00
ledc_hal.c feat(ledc): support ledc on esp32p4 2023-10-17 16:40:04 +08:00
linker.lf refactor(ledc): move related kconfig and linker.lf to its own folder 2023-10-02 07:32:16 +00: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
mipi_csi_hal.c change(csi): changed the clk_freq_hz to lane_bit_rate_mbps 2024-03-27 10:40:59 +08:00
mipi_dsi_hal.c feat(mipi_dsi): use DCS short packet when possible 2024-03-06 17:25:09 +08:00
mmu_hal.c Use configuration option instead of in components not related to FreeRTOS 2023-11-28 07:49:20 +00: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
README.md fix(adc): invalid assertion on the adc_unit 2023-08-23 18:36:02 +08:00
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
sdmmc_hal.c feat(sdmmc): supported sd2.0 on esp32p4 2023-10-18 11:57:55 +00: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 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 feat(spi_flash): Enable auto suspend on when flash works under 120M 2023-11-15 17:27:42 +08:00
spi_flash_hal.c feat(spi_flash): Support configurable tSUS in flash suspend 2023-11-06 18:04:43 +08:00
spi_hal_iram.c feat(spi_master): rebase dma sct mode support, rename APIs, use malloc conf_buffer 2024-03-20 16:06:43 +08:00
spi_hal.c feat(spi_master): rebase dma sct mode support, rename APIs, use malloc conf_buffer 2024-03-20 16:06:43 +08:00
spi_slave_hal_iram.c feat(spi_slave): add p4 hp spi slave driver support 2023-10-30 12:51:56 +08:00
spi_slave_hal.c refactor(spi): replace dma_ll related in spi by dma driver (part1) 2023-12-04 16:20:05 +08:00
spi_slave_hd_hal.c refactor(spi): replace dma_ll related in spi by dma driver (part1) 2023-12-04 16:20:05 +08:00
systimer_hal.c ci(system): fixed and enabled misc system build tests 2023-11-28 14:00:16 +08:00
timer_hal.c feat(mcpwm): MCPWM event comparator driver 2023-09-11 16:53:34 +08:00
touch_sensor_hal.c feat(touch): support touch driver on p4 (soc) 2023-11-16 11:13:02 +00:00
twai_hal_iram.c
twai_hal.c feat(twai): support legacy twai(can) driver for esp32p4 2023-10-26 16:20:45 +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 feat(uart): add RCC atomic block to uart/lp-uart peripheral 2023-10-08 10:10:02 +08:00
usb_dwc_hal.c feat(usb/host): Update ISOC scheduler for HS endpoints 2024-03-01 18:05:40 +01:00
usb_serial_jtag_hal.c refactor(hal/usb): Add new USB PHY related HAL API 2024-04-04 02:47:00 +08:00
usb_wrap_hal.c refactor(hal/usb): Add new USB PHY related HAL API 2024-04-04 02:47:00 +08:00
wdt_hal_iram.c
xt_wdt_hal.c

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