Sensor cadence

Functions
void	ai_engine_set_sensor_rate (uint32_t interval_ms)
	Set the accelerometer feed interval; call it on its own, from one owner.
void	ai_engine_resume_sensor (void)
	Standalone resume of the default cadence; never back-to-back with a rate set.

Detailed Description

Two functions that send asynchronous sensor-rate requests to CM33. Issued back to back, a resume can cancel a rate change. That single fact is the whole contract of this topic.

Variant

mtb-mpy and mtb-only

Function Documentation

ai_engine_set_sensor_rate()

void ai_engine_set_sensor_rate

(

uint32_t

interval_ms

)

Set the accelerometer feed interval; call it on its own, from one owner.

Set the accelerometer feed interval (20 = 50 Hz model rate, 100 = 10 Hz dashboard). Callable from any CM55 task; it also resumes the sensor push. Call it on its own: an ai_engine_resume_sensor() issued right after it can cancel it.

Contract

Sets the accelerometer feed interval — 20 (50 Hz model rate) or 100 (10 Hz dashboard). The request goes to CM33 asynchronously, and it also resumes the sensor push. Callable from any CM55 task. Never call it back-to-back with ai_engine_resume_sensor(): a resume issued while this request is still in flight can cancel it, and CM33 then pauses the sensor push instead of changing its rate. Give rate changes one owner — the shipped firmware decides the rate in one place: it raises it to 50 Hz when the started model (or any member of a started set) is AI_SENSOR_IMU, only after ai_engine_start() returned true, and walks it down on every ai_engine_stop().

Variant

mtb-mpy and mtb-only

ai_engine_resume_sensor()

void ai_engine_resume_sensor

(

void

)

Standalone resume of the default cadence; never back-to-back with a rate set.

Restore the default sensor cadence after a model session. Use it on its own, not in the same breath as ai_engine_set_sensor_rate().

Contract

Restores the default sensor cadence after a model session by sending a resume request. No caller exists anywhere in shipped firmware (absent from consumer_must_provide.txt). The explicit anti-usage rule: do not call it immediately after ai_engine_set_sensor_rate()** — both requests are asynchronous, and the resume can cancel a rate request still in flight; this froze the pure-MicroPython Edge AI feed (result() == None) on real hardware. It is also unnecessary after a rate change: set_sensor_rate() already resumes the sensor push. The correct use is a standalone** send with no rate request in flight (a page-leave path that wants no rate change). CM55 task context.

Variant

mtb-mpy and mtb-only

Example (authored — no shipped call site)

The example below teaches the anti-pattern: the boxed WRONG sequence is what not to write, and the single call that follows is the only legal shape.

__attribute__((used))
static void bento_ex_ai_engine_resume_sensor(void)
{
    /* WRONG — the two requests can cancel each other (see the box):
     *
     *   ai_engine_set_sensor_rate(100u);   // rate request, in flight...
     *   ai_engine_resume_sensor();         // ...can cancel it -> PAUSE
     *
     * RIGHT — set_sensor_rate alone already resumes the sensor push:
     *
     *   ai_engine_set_sensor_rate(100u);   // walk down to dashboard rate
     *
     * RIGHT — resume on its own, with no rate change in flight
     * (page-leave path, no rate change wanted): */
    ai_engine_resume_sensor();
}