Repository navigation
Building a backend tailored to Espressif systems #22334
Description
🚀 The feature, motivation and pitch
Hello Executorch devs,
I want this to be as short as possible. I want to develop a backend for Espressif chips as some of them are capable of working with TinyML applications, but I see they are not supported out of the box by Executorch.
Thank you in advance.
Kind Regards.
Alternatives
No response
Additional context
No response
RFC (Optional)
No response
Metadata
Metadata
Assignees
Labels
Issues related to backend APIs or requests for new backendsFor embedded MCUs like Cortex-M, or RTOS like Zephyr, does not track NPU backend like Arm Ethos.Request for comment and feedback on a post, proposal, etc.This issue has been looked at a team member, and triaged and prioritized into an appropriate module
Activity
nil-is-all commentedon Sep 10, 2026
@rascani is this something you can comment on since you worked on the model zoo?
nil-is-all commentedon Sep 10, 2026
Also @CodeKitty-max, currently there are examples for espressif added via #18224 under examples/espressif
CodeKitty-max commentedon Sep 10, 2026
Yes, I saw the example. I want to write something more hardware-specific to utilize the features of the Xtensa chip to a maximum rather than something generic. I believe better performance can be squeezed out of it
rascani commentedon Sep 10, 2026
Hi @CodeKitty-max - I agree with the sentiment that better performance can be reached on Espressif chips and developing a backend makes sense.
We've generally been encouraging new backends to be developed out-of-tree (examples: executorch-ggml, TensorRT). The benefit to this approach is that development can progress independently and doesn't depend upon ExecuTorch maintainers. We can add documentation & pointers to the ExecuTorch documentation advertising the out-of-tree backend. Is this a direction you would be interested in pursuing?
From a technical perspective, I would generally suspect an Espressif backend to be an "operator library" backend, rewriting the graph to use optimized kernels. Were you planning on building this with the esp-nn lib? Or writing your own kernels? You may want to look at the cortex-m & cadence backends as examples for building on top of an operator library. You may also be able to re-use some of the cadence backend here.
Additionally, I'm interested in looking at how we can reduce the cost of developing these MCU backends utilizing some shared infrastructure. Shared quantization, graph transforms, layout & optimization passes, etc. I'll work on an RFC soon for that, but would welcome input on how we can help here.
CC @mcremon-meta @digantdesai
CodeKitty-max commentedon Sep 11, 2026
I wouldn't mind an out of tree implementation. I want to use esp-NN rather than my own unique kernels.
As for the development of a common platform for MCUs, I see how it can work for the upper half of the process.
mergennachin commentedon Sep 18, 2026
Hi @CodeKitty-max
Keep us posted on the progress.
CodeKitty-max commentedon Sep 20, 2026
I've already largely dealt with the upper half of the code. Now I am dealing with the ESP-NN optimizations. Hopefully can get it up on Github within the week. I'll link it here when I do so.
rascani commentedon Oct 6, 2026
Hi @CodeKitty-max - how are the ESP-NN optimizations going?
CodeKitty-max commentedon Oct 8, 2026
Is there a guide on dealing with the licences? I am not sure how to deal with that
nil-is-all commentedon Oct 8, 2026
Is there some specific tech's license guide you're looking for?
The repo's homepage has the guide for using ET: https://github.com/pytorch/executorch?tab=License-1-ov-file#
rascani commentedon Oct 8, 2026
For contributing source, the project is licensed under the BSD license. Please ensure all source has a license header (look at nearby sources), and you can include your copyright if you would like (you don't need to include Meta's).
There is also the CLA process. Earlier this year, ExecuTorch moved to the PyTorch Foundation, so we now use the Linux Foundation's easyCLA. I just realized our documentation is still pointing at the Meta CLA, so I'll update that.
Here is a link to sign the easyCLA: easyCLA Authorization
And here's the support link: easyCLA portal
Also, as an fyi, our team is really interested in esp32 support, and I will likely start working on supporting it in-tree here shortly.
CodeKitty-max commentedon Oct 15, 2026
Since I have largely completed and tested the backend, I now want a suggestion on how it will be linked through here since we decided it would be best if it were uploaded on my Github account. I have already done a lot of the work or the vast majority of it for esp32 development, and I wanted it in-tree but it was suggested above that I do it out-of-tree instead.
rascani commentedon Oct 15, 2026
I spent a little time last week getting the Espressif emulator working in in-tree CI, so we have a viable path to supporting an espressif backend. If you would like to submit a pull request(s) with the backend, we can consider it for in-tree development. Do you have a repo or a fork you can share with us?
CodeKitty-max commentedon Oct 15, 2026
That would be wonderful, I can do it as soon as I get to my PC tomorrow, I wanted to get a greenlight through this issue. Caveat, I have only physically tested on the esp32s3 because it was the most powerful board I had. But I can progressively update benchmarks. Expect a PR tomorrow.
CodeKitty-max commentedon Oct 18, 2026
The PR is finally up: #23956 sorry for the delay.