5b54ae76d4
When ESP32-C2 is paired with a 26 MHz XTAL, the systimer tick frequency becomes equal to 26 / 2.5 = 10.4 MHz. Previously we always assumed that systimer tick frequency is integer (and 1 MHz * power of two, above that!). This commit introduces a new LL macro, SYSTIMER_LL_TICKS_PER_US_DIV. It should be set in such a way that: 1. SYSTIMER_LL_TICKS_PER_US / SYSTIMER_LL_TICKS_PER_US_DIV equals the actual systimer tick frequency, 2. and SYSTIMER_LL_TICKS_PER_US is integer. For ESP32-C2 this means that SYSTIMER_LL_TICKS_PER_US = 52 and SYSTIMER_LL_TICKS_PER_US_DIV = 5. This introduced two possible issues: 1. Overflow when multiplying systimer counter by 5 - Should not be an issue, since systimer counter is 52-bit, so counter * 5 is no more than 55-bit. 2. The code needs to perform: - divide by 5: when converting from microseconds to ticks - divide by 52: when converting from ticks to microseconds The latter potentially introduces a performance issue for the esp_timer_get_time function. |
||
---|---|---|
.. | ||
adc_hal_common.h | ||
adc_hal.h | ||
adc_types_private.h | ||
adc_types.h | ||
aes_hal.h | ||
aes_types.h | ||
brownout_hal.h | ||
cache_hal.h | ||
cache_types.h | ||
dac_hal.h | ||
dac_types.h | ||
dma_types.h | ||
ds_hal.h | ||
ecc_hal.h | ||
ecc_types.h | ||
efuse_hal.h | ||
emac_hal.h | ||
esp_flash_err.h | ||
eth_types.h | ||
gdma_hal.h | ||
gpio_hal.h | ||
gpio_types.h | ||
i2c_hal.h | ||
i2c_types.h | ||
i2s_hal.h | ||
i2s_types.h | ||
lcd_hal.h | ||
lcd_types.h | ||
ledc_hal.h | ||
ledc_types.h | ||
mcpwm_hal.h | ||
mcpwm_types.h | ||
memprot_types.h | ||
mmu_hal.h | ||
mmu_types.h | ||
mpu_hal.h | ||
mpu_types.h | ||
pcnt_hal.h | ||
pcnt_types.h | ||
readme.md | ||
rmt_hal.h | ||
rmt_types.h | ||
rtc_hal.h | ||
rtc_io_hal.h | ||
rtc_io_types.h | ||
sdio_slave_hal.h | ||
sdio_slave_ll.h | ||
sdio_slave_types.h | ||
sha_hal.h | ||
sha_types.h | ||
sigmadelta_hal.h | ||
sigmadelta_types.h | ||
spi_flash_encrypt_hal.h | ||
spi_flash_hal.h | ||
spi_flash_types.h | ||
spi_hal.h | ||
spi_slave_hal.h | ||
spi_slave_hd_hal.h | ||
spi_types.h | ||
systimer_hal.h | ||
systimer_types.h | ||
temperature_sensor_types.h | ||
timer_hal.h | ||
timer_types.h | ||
touch_sensor_hal.h | ||
touch_sensor_types.h | ||
twai_hal.h | ||
twai_types.h | ||
uart_hal.h | ||
uart_types.h | ||
uhci_types.h | ||
usb_hal.h | ||
usb_phy_hal.h | ||
usb_phy_types.h | ||
usb_types_private.h | ||
usbh_hal.h | ||
usbh_ll.h | ||
wdt_hal.h | ||
wdt_types.h | ||
xt_wdt_hal.h |
HAL Layer Readme
The HAL layer is designed to be used by the drivers. We don't guarantee the stability and back-compatibility among versions. The HAL layer may update very frequently with the driver. Please don't use them in the applications or treat them as stable APIs.
The HAL layer consists of two layers: HAL (upper) and Lowlevel(bottom). The HAL layer defines the steps and data required by the peripheral. The lowlevel is a translation layer converting general conceptions to register configurations.
Lowlevel
This layer should be all static inline. The first argument of LL functions is usually a pointer to the beginning address of the peripheral register. Each chip should have its own LL layer. The functions in this layer should be atomic and independent from each other so that the upper layer can change/perform one of the options/operation without touching the others.
HAL
This layer should depend on the operating system as little as possible. It's a wrapping of LL functions, so that the upper layer can combine basic steps into different working ways (polling, non-polling, interrupt, etc.). Without using queues/locks/delay/loop/etc., this layer can be easily port to other os or simulation systems.
To get better performance and better porting ability, context
s are used to hold sustainable data and pass the parameters.
To develop your own driver, it is suggested to copy the HAL layer to your own code and keep them until manual update.