kassane
commented
3 months ago Although the readme claims to support v4.4 to 5.x, it is actually being tested on 5.3-dev.
The last commit added a wrapper to handle the IDF version. The main idea was to read the esp_idf_version.h header, but zig couldn't find it even though it had access to the include path.
The idea of managing multiple versions of functions could be done in a similar way to crc_xx, depending on the version of the IDF.
TODO
mini-FAQ
So Zig can read C headers. Why manual wrappers?
Indeed
@cImport/@cIncludedoesn't access C types directly, but it converts to zig binding automatically (like binding-rs). However, there have been some limits to support at the moment, in particular when converting macros (difficult to parse). One example isESP_LOGx, which has been done manually, since the original version provided inesp_log.hhas become untranslatable. see: zig doc -@cImportvstranslate-cSo why not use microzig to make the project fully zig-written?
I am currently using zig v0.12.0-dev (nightly/master) and the microzig project does not support this version yet. see: https://github.com/ZigEmbeddedGroup/microzig/pull/178 The use of regz (svd converter) will also need to be evaluated, since it is under development and not all peripherals are guaranteed during translation. see: https://github.com/ZigEmbeddedGroup/microzig/pull/180
Why did you add C++ example using Zig?
Isn't it clear? Okay, so instead of using crosstool-NG you switch to
zig c++/clang++, but only withlibc++(LLVM C++ ABI) and notlibstdc++(GNU C++ ABI). However, the final binary will still be compiled via cmake with crosstool-NG andlibgcc(compiler ABI), notcompiler-rt(compiler ABI). see: https://github.com/kubo39/esp32-resource/issues/1Note: Zig (the toolchain) doesn't just prefer its own language!