Document CONFIG_COMPILER_LTO_LINKTIME / CONFIG_COMPILER_LTO_COMPILETIME in the
binary size reduction guide, including the caveats: less accurate per-component
size breakdown, longer build times, incompatibility with custom linker
fragments, and harder debugging.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Server can now start from any directory, not just a valid project dir
- Document project_dir argument available on all tools
- Add create-project tool to the list of available tools
Co-authored-by: Cursor <cursoragent@cursor.com>
Split the single build-system-v2 page into a landing page that dispatches
to focused how-to guides (creating a project, creating components,
configuring dependencies, third-party libraries, ESP-IDF as a library,
multiple binaries) and reference pages (design and architecture, breaking
changes, and the generated API reference). Mirror the new structure on
zh_CN and update the API Guides table of contents.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
feat(freertos): added option for automatically placing task stacks in PSRAM
Closes IDF-15538, IDF-15539, and IDF-15540
See merge request espressif/esp-idf!48953
The esp-idf-configdep utility works as a compiler wrapper. It lets the
compiler compile the app and checks whether -MF option was used to
generate dependency files. If yes, it checks for sdkconfig.h dependency
in those files.
Target file depending on sdkconfig.h is then scanned for all CONFIG_*
occurrences and the dependency file is altered so that the given target
file is marked as "dirty" only if the config options it actually uses
are changed.
This ensures that after a configuration update, only affected files are
rebuilt, reducing incremental build times.
The compiler launcher mechanism is changed from RULE_LAUNCH_COMPILE
(Makefile-only) to CMAKE_*_COMPILER_LAUNCHER (generator-agnostic),
enabling launcher chaining (configdep -> ccache -> compiler).
Made-with: Cursor
Add USB DFU and OTG console SOC capability flags for esp32s2, esp32s3, and esp32p4.
Use these caps in Kconfig, documentation conditionals, and idf.py DFU actions so USB support
is derived from SOC capabilities instead of hardcoded target names.
1) Add support for MAC randomization in Active scan and connect
2) Add support for randomizaton of sequence numbers
3) Add support for randomization of dialog token for GAS frames
Mirror the recent EN-side updates in the Chinese External RAM guide:
- Replace "PSRAM 顶部" with "PSRAM 上端（最高物理地址区）" to match the
clarified wording on the EN side.
- Add the verification-helper pointer next to the heap_caps_malloc
example so Chinese readers also learn about esp_psram_ptr_is_no_enc().
Also drop the :cpp:func: cross-reference for esp_psram_ptr_is_no_enc on
the EN side: esp_psram.h is not in any chip-specific Doxyfile, so
Sphinx/Breathe cannot resolve the reference. Use a plain inline code
literal instead, matching the existing reference style for
esp_psram_get_size and other esp_psram functions in the docs.
The previous wording "top of PSRAM" was ambiguous: the carve-out is
actually mapped at the highest physical addresses of PSRAM (after the
rodata, text, and main heap mappings). Update the Kconfig help text for
SPIRAM_ENC_EXEMPT and SPIRAM_ENC_EXEMPT_SIZE, the External RAM
documentation, and the internal layout comment to say "upper end of PSRAM
(highest physical addresses)" instead.
Drivers that allocate from the unencrypted PSRAM carve-out via
MALLOC_CAP_SPIRAM_NO_ENC currently have no way to verify after the fact
which pool a buffer came from. This is particularly relevant for callers
using heap_caps_malloc_prefer(MALLOC_CAP_SPIRAM_NO_ENC, MALLOC_CAP_SPIRAM),
where a silent fallback to encrypted PSRAM would still pass the typical
esp_ptr_external_ram() check.
Expose esp_psram_ptr_is_no_enc() in the public esp_psram.h header. It
performs a range check against the carve-out's virtual-address window and
returns false when PSRAM is not initialized or CONFIG_SPIRAM_ENC_EXEMPT is
disabled, so callers do not need to guard the call site with #if.
Also reference the helper from the External RAM documentation alongside
the heap_caps_malloc(MALLOC_CAP_SPIRAM_NO_ENC) usage example.
Extends the External RAM encryption section to describe
CONFIG_SPIRAM_ENC_EXEMPT and the MALLOC_CAP_SPIRAM_NO_ENC heap
capability, including a security warning and a typical DMA-alignment
use case. Mirrors the change in zh_CN.
