esp-idf/components
morris 5f257494c5 Merge branch 'contrib/github_pr_12179_v4.4' into 'release/v4.4'
fix(uart): Fix uart_ll_set_baudrate div-by-zero crash due to uint32_t overflow (backport v4.4)

See merge request espressif/esp-idf!26018
2023-10-20 22:19:34 +08:00
..
app_trace gcov: Fix not linked gcov rtio functions 2023-07-03 13:05:45 +03:00
app_update
asio
bootloader feat(bootloader): Update micro-ecc version to v1.1 2023-09-22 10:50:16 +05:30
bootloader_support Merge branch 'feature/unicore_bootloader_can_run_multicore_app_v4.4' into 'release/v4.4' 2023-09-01 10:18:49 +08:00
bt Merge branch 'backport_v4.4' into 'release/v4.4' 2023-10-17 09:31:28 +08:00
cbor
cmock
coap
console
cxx
driver feat(usb_serial_jtag): printing to console could sometimes skip bytes 2023-10-12 15:21:53 +08:00
efuse hal: Explicit setting of efuse time settings 2023-05-13 00:06:35 +08:00
esp-tls
esp32 kconfigs: Fix config issues raised by gen_kconfig_doc.py 2023-03-03 22:26:39 +00:00
esp32c3 kconfigs: Fix config issues raised by gen_kconfig_doc.py 2023-03-03 22:26:39 +00:00
esp32h2 kconfigs: Fix config issues raised by gen_kconfig_doc.py 2023-03-03 22:26:39 +00:00
esp32s2 Merge branch 'feature/apply_new_version_logic_v4.4' into 'release/v4.4' 2023-03-10 14:52:18 +08:00
esp32s3 Merge branch 'feature/apply_new_version_logic_v4.4' into 'release/v4.4' 2023-03-10 14:52:18 +08:00
esp_adc_cal
esp_common versions: Update version to 4.4.6 2023-09-26 07:11:21 +00:00
esp_eth Merge branch 'bugfix/eth_lan8720_ci_v4.4' into 'release/v4.4' 2023-06-13 16:42:07 +08:00
esp_event
esp_gdbstub
esp_hid fix(bt/bluedroid): Fix hid example stack overflow bugs when using esp32s3 2023-10-16 19:33:46 +08:00
esp_http_client fix(esp_http_client): Call event_handler after header value is received 2023-10-05 10:24:31 +05:30
esp_http_server esp_http_server: fix return values for `httpd_socket_send()` and `httpd_socket_recv()` APIs 2023-02-10 10:57:22 +05:30
esp_https_ota
esp_https_server
esp_hw_support feat(pm): add internal pull-up/downs option for gpio used for deepsleep wakeup 2023-09-19 11:16:20 +08:00
esp_ipc esp_system: Fix a race-condition in esp_ipc_isr (in QEMU env) 2023-05-30 23:04:31 +08:00
esp_lcd fix(i80_lcd): reset cs gpio on exit 2023-08-07 15:54:31 +08:00
esp_local_ctrl
esp_netif esp_netif/lwip: Fix core-locking config (v4.4) 2023-03-21 10:31:20 +01:00
esp_phy Merge branch 'bugfix/tempsensor_wifi_conflict_v4.4' into 'release/v4.4' 2023-09-07 14:15:16 +08:00
esp_pm bugfix: increase pm_dump time field width 2023-07-10 06:37:35 +00:00
esp_ringbuf
esp_rom fix(bt/controller): Fixed some HCI commands parameter 2023-10-09 02:28:44 +00:00
esp_serial_slave_link
esp_system Merge branch 'bugfix/wdt_deinit_timeout_v4.4' into 'release/v4.4' 2023-10-19 13:39:52 +08:00
esp_timer ci: Fix for `ETSTimers arm & disarm run from IRAM` UT 2023-08-16 11:13:39 +08:00
esp_websocket_client
esp_wifi fix(wifi): Fix crash occuring when station SAE group is not set to SECP256R1 2023-10-17 13:45:27 +05:30
espcoredump bugfix: avoid warning in espcoredump when log disabled 2023-08-02 15:04:47 +05:30
esptool_py fix(esptool): fix potential text/rodata mapping overlap issue on I/DBUS shares mmu entry chips 2023-08-03 22:18:52 +08:00
expat
fatfs
freemodbus freemodbus: remove component manifest file from freemodbus subrepo 2023-03-10 17:23:32 +08:00
freertos Merge branch 'bugfix/fix_freertos_system_task_names_v4.4' into 'release/v4.4' 2023-10-18 16:10:25 +08:00
hal fix(uart): Fix uart_ll_set_baudrate div-by-zero crash due to uint32_t overflow 2023-09-18 16:22:01 +08:00
heap heap: Fix erroneous value returned by heap_caps_get_allocated_size() when poisoning is enabled 2023-02-22 07:32:49 +01:00
idf_test
ieee802154
jsmn
json
libsodium
linux
log
lwip Merge branch 'feat/imporve_iperf_performance_v4.4' into 'release/v4.4' 2023-10-19 10:31:40 +08:00
mbedtls feat(mbedtls): Update to release v2.28.5 2023-10-17 15:09:36 +05:30
mdns components/mdns: use semaphore instead of task notification bits (IDFGH-9380) 2023-03-24 09:03:35 +01:00
mqtt
newlib Set errno in adjtime if delta is too large 2023-03-03 18:15:52 +08:00
nghttp
nvs_flash bugfix(nvs_flash): fixed wrong error check after open_nvs_handle 2023-02-10 10:00:13 +08:00
openssl
openthread
partition_table partition_table: fix make build for new "--secure [v1/v2]" argument 2023-02-12 21:29:39 +05:30
perfmon
protobuf-c protobuf-c: Update submodule to v1.4.1 2023-07-07 04:49:27 +00:00
protocomm wifi_prov_mgr: Fixed memory leak after bluetooth stack was stopping. 2023-07-17 06:05:36 +00:00
pthread fix(pthread): fixed pthread_condvar linker hook 2023-09-18 12:31:43 +08:00
riscv
sdmmc sdmmc: keep clock enabled for the duration of ACMD41 2023-07-18 18:17:48 +02:00
soc fix(interrupts): reorder esp32s3 irq names to align with the respective irq numbers 2023-10-16 22:26:36 +02:00
spi_flash change(mspi): remove s3 120mhz sdr warning 2023-09-27 15:03:07 +08:00
spiffs
tcp_transport
tcpip_adapter
tinyusb fix usb resume bug on esp32sx 2023-04-27 10:47:46 +08:00
touch_element touch_element: fix unintended integer division 2023-06-20 10:47:06 +08:00
ulp
unity
usb usbh: fix invalid assert on desc_status 2023-06-20 10:47:06 +08:00
vfs fix(vfs): Fix event_write may not exit critical section 2023-09-19 08:53:58 +02:00
wear_levelling
wifi_provisioning
wpa_supplicant Merge branch 'docs/update_wifi_and_wpa_supplicant_documentation_v4.4' into 'release/v4.4' 2023-10-19 04:04:19 +08:00
xtensa
README.md

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 from now on) contains hal, xtensa and riscv (referred to as arch components from now on), esp_rom, esp_common, and soc. This group contain information about and low-level access to underlying hardware; or in the case of esp_common, hardware-agnostic code and utilities. These components can depend on each other, but as much as possible have no dependencies outside the group. The reason for this is that, due to the nature of what these components contain, the likelihood is high that a lot of other components will require these. Ideally, then, the dependency relationship only goes one way. This makes it easier for these components, as a group, to be usable in another project. One can conceivably implement a competing SDK to ESP-IDF on top of these components.

The second group (referred to as G1 from now on) sits at a higher level than the first group. This group contains the components esp_hw_support, esp_system, newlib, spi_flash, freertos, log, and heap. Like the first group, circular dependencies within the group are allowed; and being at a higher level, dependency on the first group is allowed. These components represent software mechanisms essential to 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_address is a low-level function part of the hardware abstraction spi_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_handler
  • riscv_global_interrupts_enable
  • ERI_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 future
  • IDF_DEPRECATED(REASON)
  • ESP_IDF_VERSION_MAJOR

soc

Contains description of the underlying hardware: register structure, addresses, pins, capabilities, etc.

Example:

  • DR_REG_DPORT_BASE
  • SOC_MCPWM_SUPPORTED
  • uart_dev_s

esp_rom

Contains headers, linker scripts, abstraction layer, patches, and other related files to ROM functions.

Example:

  • esp32.rom.eco3.ld
  • rom/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:

  • malloc is implemented in terms of the component heap's functions
  • gettimeofday is implemented in terms of system time in esp_system

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. However, to maintain backward compatibility, esp_system.h includes these headers.

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.