SDK for TESAIoT Dev Kit
API reference & tutorials (ModusToolbox)
Loading...
Searching...
No Matches
Two layers of access — who can call what

There are exactly two caller layers, and they do not overlap:

  • C code compiled into proj_cm55 calls ai_engine_* and ai_model_staged_* directly. Every shipped caller of this surface is itself inside the prebuilt libbento_cm55.a (built from page_edge_ai.c, deepcraft_task.c and tesaiot_display.c per dist/cm55_core/PROVENANCE.txt). The template ships zero .c call sites for any of these functions; lib/cm55_core/consumer_must_provide.txt lists the 35 ai_* symbols that have a shipped caller, and the two absent from that list (ai_engine_dq_calls(), ai_engine_resume_sensor()) have no caller anywhere.
  • MicroPython runs on CM33_NS and cannot call ai_engine_* at all. It reaches this module only over the IPC model link — the edge_ai.* module (mp_module_edge_ai, exported from dist/mpy_secure/api.txt) sends MODEL_LINK_* commands that deepcraft_task.c services on CM55, and that task is what calls into this archive. A MicroPython program therefore never sees a C prototype from this page; it sees edge_ai.select(), edge_ai.result(), edge_ai.diag() and the rest, whose semantics are the ones documented here.

Because the callers are archived, every example on these pages is either lifted verbatim from the archived sources (marked with an Origin paragraph naming the file and lines — compiled into libbento_cm55.a, not shipped as source) or authored for the two functions that have no caller (marked Example (authored — no shipped call site)*).