d69d1aafaf
This commit fixes a race condtion bug with usb_dwc_hal_chan_request_halt() where a channel the channel is halted if it has just completed a transfer (i.e., finished processing a QTD with the "HOC" flag set) but the channel is still pending interrupt handling. In this case... - usb_dwc_hal_chan_request_halt() would simply read the channel's underlying register, determine it is not active, not set the "halt_requested" flag, and simply return true. - The caller assumes of usb_dwc_hal_chan_request_halt() will assume that the channel has halted, and may proceed to reconfigure the pipe/port - When usb_dwc_hal_chan_decode_intr() comes to process the pending interrupt it will simply return USB_DWC_HAL_CHAN_EVENT_CPLT not knowing a halt has been requested. This commit updates the implementation of usb_dwc_hal_chan_request_halt() so that a halt is properly requested even if the underlying channel has already physically halted. |
||
|---|---|---|
| .. | ||
| esp32 | ||
| esp32c2 | ||
| esp32c3 | ||
| esp32c6 | ||
| esp32h2 | ||
| esp32h4 | ||
| esp32s2 | ||
| esp32s3 | ||
| include/hal | ||
| platform_port/include/hal | ||
| test | ||
| adc_hal_common.c | ||
| adc_hal.c | ||
| adc_oneshot_hal.c | ||
| aes_hal.c | ||
| cache_hal.c | ||
| CMakeLists.txt | ||
| ds_hal.c | ||
| ecc_hal.c | ||
| efuse_hal.c | ||
| emac_hal.c | ||
| etm_hal.c | ||
| gdma_hal.c | ||
| gpio_hal.c | ||
| hmac_hal.c | ||
| i2c_hal_iram.c | ||
| i2c_hal.c | ||
| i2s_hal.c | ||
| Kconfig | ||
| lcd_hal.c | ||
| ledc_hal_iram.c | ||
| ledc_hal.c | ||
| linker.lf | ||
| mcpwm_hal.c | ||
| mmu_hal.c | ||
| mpu_hal.c | ||
| pcnt_hal.c | ||
| README.md | ||
| rmt_hal.c | ||
| rtc_io_hal.c | ||
| sdio_slave_hal.c | ||
| sdkconfig.rename | ||
| sdm_hal.c | ||
| sha_hal.c | ||
| spi_flash_encrypt_hal_iram.c | ||
| spi_flash_hal_common.inc | ||
| spi_flash_hal_gpspi.c | ||
| spi_flash_hal_iram.c | ||
| spi_flash_hal.c | ||
| spi_hal_iram.c | ||
| spi_hal.c | ||
| spi_slave_hal_iram.c | ||
| spi_slave_hal.c | ||
| spi_slave_hd_hal.c | ||
| systimer_hal.c | ||
| timer_hal_iram.c | ||
| timer_hal.c | ||
| touch_sensor_hal.c | ||
| twai_hal_iram.c | ||
| twai_hal.c | ||
| uart_hal_iram.c | ||
| uart_hal.c | ||
| usb_dwc_hal.c | ||
| usb_hal.c | ||
| usb_phy_hal.c | ||
| wdt_hal_iram.c | ||
| xt_wdt_hal.c | ||
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.