| Supported Targets | ESP32 | ESP32-C2 | ESP32-C3 | ESP32-C6 | ESP32-H2 | ESP32-P4 | ESP32-S2 | ESP32-S3 |
|---|
This project aims to integrate Zig language and toolchain with the Espressif IoT Development Framework for enhanced development capabilities on ESP32 and its variants.
| target | commands |
|---|---|
| esp32 | -Dtarget=xtensa-freestanding-none -Dcpu=esp32 |
| esp32-s2 | -Dtarget=xtensa-freestanding-none -Dcpu=esp32s2 |
| esp32-s3 | -Dtarget=xtensa-freestanding-none -Dcpu=esp32s3 |
| esp32-c2/c3 | -Dtarget=riscv32-freestanding-none -Dcpu=generic_rv32+c+m |
| esp32-h2/c5/c6 | -Dtarget=riscv32-freestanding-none -Dcpu=generic_rv32+a+c+m |
| esp32-p4 | -Dtarget=riscv32-freestanding-eabihf -Dcpu=generic_rv32+a+c+f+m |
[!WARNING] Zig upstream (LLVM-Codegen) does not have xtensa support. Like esp-rs, it is necessary to use the zig-xtensa - toolchain forked.
Zig Language Integration: Use the Zig programming language to write firmware code. It provides modern language features such as comptime, meta-programming, and error handling.
Zig Toolchain Integration: The Zig toolchain can be used to build zig libraries and executables, and can also be integrated with the ESP-IDF build system. Also, system compiler and linker can be replaced to zig cc/zig c++.
llvm-libc++ ABI by default.ESP-IDF Compatibility: Seamlessly integrate Zig with the ESP-IDF framework, allowing developers to leverage the rich set of APIs and functionalities provided by ESP-IDF for IoT development.
Build System Configuration: Using CMake to build Zig libraries allows easy integration with existing ESP-IDF projects while providing efficient dependency management and build configuration.
Cross-Platform Development: Facilitate development across various ESP32 variants including ESP32-C2, ESP32-C3, ESP32-C5, ESP32-C6, ESP32-H2, ESP32-P4, ESP32-S2, and ESP32-S3, ensuring broad compatibility and versatility.
[!NOTE]
Asserts allocations are within
@alignOf(std.c.max_align_t)and directly callsmalloc/free. Does not attempt to utilizemalloc_usable_size.
std.heap.raw_c_allocatorallocator is safe to use as the backing allocator withstd.heap.ArenaAllocatorfor example and is more optimal in such a case thanstd.heap.c_allocator. - ref.: std-doc
std.heap.ArenaAllocatortakes an existing allocator, wraps it, and provides an interface where you can allocate without freeing, and then free it all together. - ref.: std-docCustom Allocators (based on
std.heap.raw_c_allocator)
idf.heap.HeapCapsAllocator- ref.: espressif-docidf.heap.MultiHeapAllocator- ref.: espressif-docidf.heap.vPortAllocator- ref.: FreeRTOS-doc
This project is licensed twice: