fec80b5d36
From: Arno Moonen <arno.moonen@airios.eu> Follows original message from Arno Moonen <arno.moonen@airios.eu> While integrating the ESP-IDF into our existing CMake structure, I've come across quite some hurdles. Most I've been able to fix in our CMake files, however this one I could not. Most of the targets created by the esptool_py component assume that the EXECUTABLE IDF build property (which contains the name of the CMake executable target) always equals the name of the created binary. This is however not always true. For instance, in our setup we use CMAKE_EXECUTABLE_SUFFIX_C and CMAKE_EXECUTABLE_SUFFIX_CXX in our toolchain file (both set to .elf). If we do add_executable(my_app), the target binary file would actually be my_app.elf. In order to fix this, I've updated it to use the TARGET_FILE generated expression. That way we also no longer need the EXECUTABLE_DIR IDF build property here. I've fixed this on v5.0.1 (as that's the ESP-IDF version I'm currently trying to integrate), but I assume it should be easy to apply the same fix to newer versions and the master branch as well. Note that this problem might exist in multiple places where EXECUTABLE is being used. While going through the ESP-IDF code base, I even noticed that a few places actually already seem to use the TARGET_FILE expression. To be honest the property name might be somewhat confusing as well, as it is actually the executable target. Closes https://github.com/espressif/esp-idf/pull/12558 |
||
|---|---|---|
| .. | ||
| app_trace | ||
| app_update | ||
| bootloader | ||
| bootloader_support | ||
| bt | ||
| cmock | ||
| console | ||
| cxx | ||
| driver | ||
| efuse | ||
| esp_adc | ||
| esp_app_format | ||
| esp_bootloader_format | ||
| esp_coex | ||
| esp_common | ||
| esp_driver_gpio | ||
| esp_driver_gptimer | ||
| esp_driver_mcpwm | ||
| esp_driver_pcnt | ||
| esp_driver_spi | ||
| esp_eth | ||
| esp_event | ||
| esp_gdbstub | ||
| esp_hid | ||
| esp_http_client | ||
| esp_http_server | ||
| esp_https_ota | ||
| esp_https_server | ||
| esp_hw_support | ||
| esp_lcd | ||
| esp_local_ctrl | ||
| esp_mm | ||
| esp_netif | ||
| esp_netif_stack | ||
| esp_partition | ||
| esp_phy | ||
| esp_pm | ||
| esp_psram | ||
| esp_ringbuf | ||
| esp_rom | ||
| esp_system | ||
| esp_timer | ||
| esp_wifi | ||
| esp-tls | ||
| espcoredump | ||
| esptool_py | ||
| fatfs | ||
| freertos | ||
| hal | ||
| heap | ||
| http_parser | ||
| idf_test | ||
| ieee802154 | ||
| json | ||
| linux | ||
| log | ||
| lwip | ||
| mbedtls | ||
| mqtt | ||
| newlib | ||
| nvs_flash | ||
| nvs_sec_provider | ||
| openthread | ||
| partition_table | ||
| perfmon | ||
| protobuf-c | ||
| protocomm | ||
| pthread | ||
| riscv | ||
| sdmmc | ||
| soc | ||
| spi_flash | ||
| spiffs | ||
| tcp_transport | ||
| touch_element | ||
| ulp | ||
| unity | ||
| usb | ||
| vfs | ||
| wear_levelling | ||
| wifi_provisioning | ||
| wpa_supplicant | ||
| xtensa | ||
| README.md | ||
Core Components
Overview
This document contains details about what the core components are, what they contain, and how they are organized.
Organization
The core components are organized into two groups.
The first group (referred to as G0) includes hal, arch (where arch is either riscv or xtensa depending on the chip), esp_rom, esp_common, and soc. This group contains information about and provides low-level access to the underlying hardware. In the case of esp_common, it contains hardware-agnostic code and utilities. These components may have dependencies on each other within the group, but outside dependencies should be minimized. The reason for this approach is that these components are fundamental, and many other components may require them. Ideally, the dependency relationship only goes one way, making it easier for this group to be usable in other projects.
The second group (referred to as G1) operates at a higher level than the first group. G1 includes the components esp_hw_support, esp_system, newlib, spi_flash, freertos, log, and heap. Like the first group, circular dependencies within this group are allowed, and these components can have dependencies on the first group. G1 components represent essential software mechanisms for building other components.
Descriptions
The following is a short description of the components mentioned above.
G0 Components
hal
Contains the hardware abstraction layer and low-level operation implementations for the various peripherals. The low-level functions assign meaningful names to register-level manipulations; the hardware abstraction provide operations one level above this, grouping these low-level functions into routines that achieve a meaningful action or state of the peripheral.
Example:
spi_flash_ll_set_addressis a low-level function part of the hardware abstractionspi_flash_hal_read_block
arch
Contains low-level architecture operations and definitions, including those for customizations (can be thought of on the same level as the low-level functions of hal).
This can also contain files provided by the architecture vendor.
Example:
xt_set_exception_handlerrv_utils_intr_enableERI_PERFMON_MAX
esp_common
Contains hardware-agnostic definitions, constants, macros, utilities, 'pure' and/or algorithmic functions that is useable by all other components (that is, barring there being a more appropriate component to put them in).
Example:
BIT(nr)and other bit manipulation utilities in the futureIDF_DEPRECATED(REASON)ESP_IDF_VERSION_MAJOR
soc
Contains description of the underlying hardware: register structure, addresses, pins, capabilities, etc.
Example:
DR_REG_DPORT_BASESOC_MCPWM_SUPPORTEDuart_dev_s
esp_rom
Contains headers, linker scripts, abstraction layer, patches, and other related files to ROM functions.
Example:
esp32.rom.eco3.ldrom/aes.h
G1 Components
spi_flash
SPI flash device access implementation.
freertos
FreeRTOS port to targets supported by ESP-IDF.
log
Logging library.
heap
Heap implementation.
newlib
Some functions n the standard library are implemented here, especially those needing other G1 components.
Example:
mallocis implemented in terms of the componentheap's functionsgettimeofdayis implemented in terms of system time inesp_system
esp_mm
Memory management. Currently, this encompasses:
- Memory mapping for MMU supported memories
- Memory synchronisation via Cache
- Utils such as APIs to convert between virtual address and physical address
esp_psram
Contains implementation of PSRAM services
esp_system
Contains implementation of system services and controls system behavior. The implementations here may take hardware resources and/or decide on a hardware state needed for support of a system service/feature/mechanism. Currently, this encompasses the following, but not limited to:
- Startup and initialization
- Panic and debug
- Reset and reset reason
- Task and interrupt watchdogs
esp_hw_support
Contains implementations that provide hardware operations, arbitration, or resource sharing, especially those that
is used in the system. Unlike esp_system, implementations here do not decide on a hardware state or takes hardware resource, acting
merely as facilitator to hardware access. Currently, this encompasses the following, but not limited to:
- Interrupt allocation
- Sleep functions
- Memory functions (external SPIRAM, async memory, etc.)
- Clock and clock control
- Random generation
- CPU utilities
- MAC settings
esp_hw_support vs esp_system
This section details list some implementations and the reason for placing it in either esp_hw_support or esp_system.
task_wdt.c (esp_system) vs intr_alloc.c (esp_hw_support)
The task watchdog fits the definition of taking and configuring hardware resources (wdt, interrupt) for implementation of a system service/mechanism.
This is in contrast with interrupt allocation that merely facilitates access to the underlying hardware for other implementations - drivers, user code, and even the task watchdog mentioned previously!
crosscore_int.c (esp_system)
The current implementation of crosscore interrupts is tightly coupled with a number of interrupt reasons associated with system services/mechanisms: REASON_YIELD (scheduler), REASON_FREQ_SWITCH (power management) REASON_PRINT_BACKTRACE (panic and debug).
However, if an implementation exists that makes it possible to register an arbitrary interrupt reason - a
lower level inter-processor call if you will, then this implementation is a good candidate for esp_hw_support.
The current implementation in esp_system can then just register the interrupt reasons mentioned above.
esp_mac.h, esp_chip_info.h, esp_random.h (esp_hw_support)
The functions in these headers used to be in esp_system.h, but have been split-off.
The remaining functions in esp_system.h are those that deal with system behavior, such
as esp_register_shutdown_handler, or are proxy for other system components's APIs such as
esp_get_free_heap_size.
The functions split-off from esp_system.h are much more hardware manipulation oriented such as:
esp_read_mac, esp_random and esp_chip_info.