8dbf23630a
This commit reorganizes SPI flash header files to better reflect their visibility and intended usage: 1. Rename `esp_flash_port/` to `esp_flash_chips/`: - Better reflects that these headers are for chip driver implementations - All chip driver headers moved to `esp_flash_chips/` directory - Added README.md explaining semi-public nature of these headers 2. Move internal headers to `esp_private/`: - `esp_flash_internal.h` -> `esp_private/esp_flash_internal.h` - `memspi_host_driver.h` -> `esp_private/memspi_host_driver.h` 3. Move chip driver related headers to `esp_flash_chips/`: - `esp_private/esp_flash_types.h` -> `esp_flash_chips/esp_flash_types.h` - `spi_flash/spi_flash_defs.h` -> `esp_flash_chips/spi_flash_defs.h` - `spi_flash_override.h` -> `esp_flash_chips/spi_flash_override.h` - All `spi_flash_chip_*.h` headers moved to `esp_flash_chips/` 4. Code improvements: - Remove unused includes (e.g., `spi_flash_override.h` from `cache_utils.c`) - Use public API `esp_flash_get_size()` instead of direct member access - Add `esp_flash_is_quad_mode` to linker.lf for IRAM placement 5. Documentation updates: - Add README.md in `esp_flash_chips/` explaining semi-public headers - Update programming guide with warnings about internal headers - Update both English and Chinese documentation 6. Update all references across the codebase: - Update includes in `spi_flash` component - Update `bootloader_support`, `app_update`, `esp_tee`, `espcoredump` - Update example projects Breaking changes: - Headers moved to new locations require include path updates - `custom_flash_driver` example temporarily disabled until external components are updated
esp_hal_mspi
⚠️ This HAL component is still under heavy development at the moment, so we don't guarantee the stability and backward-compatibility among versions.
The esp_hal_mspi component provides a Hardware Abstraction Layer of mspi for all targets supported by ESP-IDF.
In a broad sense, the HAL layer consists of two sub-layers: HAL (upper) and Low-Level(bottom). The HAL layer defines the steps and data that is required to operate a peripheral (e.g. initialization, start and stop). The low-level is a translation layer above the register files under the soc component, it only covers general conceptions to register configurations.
The functions in this file mainly provide hardware abstraction for IDF peripheral drivers. For advanced developers, the HAL layer functions can also be directly used to assist in implementing their own drivers. However, it needs to be mentioned again that the interfaces here do not guarantee stability.