Skip to content

Espressif: Share one ESP-IDF PAL across examples - #24291

Merged
JakeStevens merged 1 commit into
pytorch:mainfrom
JakeStevens:espressif-shared-pal
Oct 29, 2026
Merged

JakeStevens merged 1 commit into
pytorch:mainfrom
JakeStevens:espressif-shared-pal

Conversation

@JakeStevens

Copy link
Copy Markdown
Contributor

Summary

Share one ESP-IDF PAL implementation between the Espressif examples.

The executor runner and camera_stream both need the same strong
et_pal_* implementation, so this moves the runner's PAL to
examples/espressif/platform/esp_pal.cpp and points both examples at
it. Keeping one source avoids the implementations drifting apart; an
ESP-IDF image can only link one strong PAL in any case.

The shared PAL logs through ESP_LOG (with an optional
ET_ESP_LOG_LEVEL compile-time floor), uses esp_timer nanosecond
ticks so timestamps stay monotonic across DFS and light sleep, and
uses malloc/free for the PAL allocation fallback instead of
returning nullptr.

This is the first PR in a small ESP-IDF component series; the
following PRs add the component template and the generator that
reuses this PAL.

Test plan

  • Confirmed both examples now reference
    examples/espressif/platform/esp_pal.cpp and the old
    runner-local PAL file is removed.
  • Host syntax compile of the PAL's non-ESP fallback path passes.
  • With the full series applied, generated a component and built a
    minimal ESP-IDF consumer for esp32s3 and esp32c5; both builds
    complete (details on the generator PR).

@JakeStevens JakeStevens added the release notes: examples Changes to any of our example LLMs integrations, such as Llama3 and Llava label Oct 29, 2026
@pytorch-bot

pytorch-bot Bot commented Oct 29, 2026 •

Copy link
Copy Markdown

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/24291

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

✅ No Failures

As of commit 1b8a9e1 with merge base fcacda3 (image):
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 29, 2026
@JakeStevens
JakeStevens requested a review from rascani October 29, 2026 15:52
Move the executor runner's ESP PAL to examples/espressif/platform/esp_pal.cpp and point both the executor runner and camera_stream at it, so the Espressif examples have a single strong PAL implementation. Logging now goes through ESP_LOG with an optional ET_ESP_LOG_LEVEL floor, ticks stay on esp_timer, and the PAL allocation fallback uses malloc/free instead of the minimal nullptr behavior.
@JakeStevens
JakeStevens merged commit 6bb588c into pytorch:main Oct 29, 2026
244 checks passed
JakeStevens added a commit that referenced this pull request Nov 2, 2026
### Summary
Add the "hand-written" template for a generated ExecuTorch ESP-IDF
component.

This contains only the component glue that is copied into generated
output: the component `CMakeLists.txt`, manifest template, README,
the small C inference API in `et_model.h`/`et_model.cpp`, and the
ESP-IDF `MmapDataLoader` stub (ESP-IDF has no `mmap`). It deliberately
does not carry a PAL copy; the generator in the next PR copies the
shared PAL from #24291.

Splitting the template out keeps the hand-written runtime glue
reviewable separately from the generator and its vendored output.
On its own this PR is inert: `et_generated.cmake` and `Kconfig` are


### Test plan
- With the generator PR applied, generated a component from this
  template and built a minimal ESP-IDF consumer that calls
  `et_model_create` for `esp32s3` and `esp32c5` with ESP-IDF v6.0.1;
  both builds complete.
- Verified the template contains no PAL copy; the generated
  component's `src/platform/esp_pal.cpp` is byte-identical to the
  shared PAL from #24291.
- Tested fully end to end w/ Muse Gadget SDK on Box 3
JakeStevens added a commit that referenced this pull request Nov 3, 2026
…#24293)

### Summary
Add `examples/espressif/build_idf_component.sh`, which generates a
source-vendored, registry-shaped ESP-IDF component from this
repository, following the same approach as the Arduino library
packaging but with an ESP-IDF layout.

The generator produces the schema headers, vendors the runtime and
needed kernel sources (using the same `build_variables.bzl` lists as
the CMake build), copies the component template from #24292 and the
shared PAL from #24291, and writes `et_generated.cmake`, `Kconfig`,
`idf_component.yml`, licenses, and a `VERSION` file recording the
ExecuTorch commit and per-profile op-set hashes. Kernel
registration is generated per profile in `idf_profiles/<name>.ops`;
the component's Kconfig selects which profile compiles, so switching
profiles needs no regeneration. This PR ships one example profile,
`wakeword_int8`, which mixes portable ATen glue ops with Cadence
backend generic (portable) int8 kernels.

Consumers of the generated component need only ESP-IDF — no host
CMake build and no `flatc`. Application code and models are not
included; they stay with the application.

Stacked on #24292
### Test plan
- Generated the component:
`./examples/espressif/build_idf_component.sh --profiles wakeword_int8
--out /tmp/et-idf-out`
  (component version `1.6.0~3`, 80 sources / 292 headers; the
  known exporter/runtime version-skew warning is printed when the
  installed Python package was built from a different commit).
- Verified the generated `src/platform/esp_pal.cpp` is
  byte-identical to `examples/espressif/platform/esp_pal.cpp`
  (`cmp`).
- Built a minimal ESP-IDF consumer that vendors the generated
  component and calls `et_model_create`, for `esp32s3` and
  `esp32c5` with ESP-IDF v6.0.1 (`idf.py set-target <target> build`);
  both complete with `Project build complete`.
- Ran end to end on Muse Gadget SDK w/ Box 3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. release notes: examples Changes to any of our example LLMs integrations, such as Llama3 and Llava

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants