Skip to content
heliaAOT
HELIA HUB

Installation

heliaAOT runs on your development machine and turns a LiteRT .tflite model into C. Start with an isolated CLI installation; firmware libraries and board tools are needed later.

Terminal window
uv tool install helia-aot
helia-aot version

If the command is not on your shell’s path, run uv tool update-shell and open a new shell. Upgrade with uv tool upgrade helia-aot.

An isolated tool installation does not make the Python API importable from another project environment. For API use, install helia-aot into that project’s environment; see the Python API guide.

Terminal window
helia-aot version
helia-aot --help

The version command identifies the installed compiler. Help lists version, list-targets, target-info and convert. A successful version command checks the installation; it does not check your model or firmware toolchain.

The examples on this site use helia-aot. Substitute the launcher from your chosen tab consistently. When keeping a deployment record, save the version alongside the model, configuration and generated module.

Stage Requirements
Read a target and convert Python 3.11 or newer; the model and, for this walkthrough, its golden fixture
Build the walkthrough application A Zephyr workspace supporting Apollo510, west, the Zephyr SDK and ns-cmsis-nn
Run on silicon Apollo510 EVB, J-Link programming connection/software and a serial terminal

The next three pages need only the host installation. Other firmware formats are covered in Firmware integration.

The package requires Python 3.11 or newer and declares support for Python 3.11–3.14. TensorFlow is not required for the supplied-golden conversion path.

Generated modules require ns-cmsis-nn 7.35.0 or newer. The generated aot_common.h enforces the applicable library floor at compile time; individual operators may require a higher version. You need the library to build the emitted C, not to convert the model.

C language and toolchain requirements

Use a toolchain compatible with the complete firmware SDK and kernel library. The generated CMake target requests c_std_99, while generated headers also use features such as stdalign.h. The generated README calls for a target-compatible toolchain and distinguishes the C99 declaration from C11 host checks. A CMake language feature declaration alone is not a portability guarantee. Toolchains and build environments separates compatibility declarations from build and execution coverage.

After upgrading, regenerate the module and repeat its build and output check. Versions and compatibility describes the version contract.