Chapter 4. API Guides
ESP-IDF FreeRTOS Single Core
Although ESP-IDF FreeRTOS is an SMP scheduler, some ESP targets are single core (such as the ESP32-S2 and
ESP32-C3). When building ESP-IDF applications for these targets, ESP-IDF FreeRTOS is still used but the number
of cores will be set to 1 (i.e., the CONFIG_FREERTOS_UNICORE will always be enabled for single core targets).
For multicore targets (such as the ESP32 and ESP32-S3), CONFIG_FREERTOS_UNICORE can also be set. This will
result in ESP-IDF FreeRTOS only running on CPU0, and all other cores will be inactive.
Note: Users should bear in mind that enabling CONFIG_FREERTOS_UNICORE is NOT equivalent to running
Vanilla FreeRTOS. The additional API of ESP-IDF FreeRTOS can still be called, and the behavior changes of
ESP-IDF FreeRTOS will incur a small amount of overhead even when compiled for only a single core.
4.15 Hardware Abstraction
Hardware abstraction in ESP-IDF are a group of API that allow users to control peripherals at differing levels of
abstraction, as opposed to interfacing with hardware using only the ESP-IDF drivers. ESP-IDF Hardware abstraction
will likely be useful for users writing high performance bare-metal drivers, or for those attempting to port an ESP
chip to another platform.
This guide is split into the following sections:
1. Architecture
2. LL (Low Level) Layer
3. HAL (Hardware Abstraction Layer)
Warning: Hardware abstraction API (excluding the driver and xxx_types.h) should be considered an exper-
imental feature, thus cannot be considered public API. Hardware abstraction API do not adhere to the API name
changing restrictions of ESP-IDF’s versioning scheme. In other words, it is possible that Hardware Abstraction
API may change in between non-major release versions.
Note: Although this document mainly focuses on hardware abstraction of peripherals (e.g., UART, SPI, I2C),
certain layers of hardware abstraction extend to other aspects of hardware as well (e.g., some of the CPU’s features
are partially abstracted).
4.15.1 Architecture
Hardware abstraction in ESP-IDF is comprised of the following layers, ordered from low level (closer to hardware)
to high level (further away from hardware) of abstraction.
• Low Level (LL) Layer
• Hardware Abstraction Layer (HAL)
• Driver Layers
The LL Layer, and HAL are entirely contained within the hal component. Each layer is dependent on the layer
below it (i.e, driver depends on HAL, HAL depends on LL, LL depends on the register header files).
For a particular peripheral xxx, its hardware abstraction will generally consist of the header files described in the
table below. Files that are Target Specific will have a separate implementation for each target (i.e., a separate copy
for each chip). However, the #include directive will still be target-independent (i.e., will be the same for different
targets) as the build system will automatically include the correct version of the header and source files.
Espressif Systems 1366
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General