3、触发条件类型详解：周期性触发、数据触发、操作触发、模式切换触发

各位好，我是老周。今天咱们来聊聊RTE事件链里最核心的一个话题——触发条件。

触发条件是什么？说白了，就是告诉系统「什么时候该干活了」。我做了十几年嵌入式，见过太多因为触发条件没配好导致系统崩溃的案例。有一次，一个同事把周期性触发设成了1毫秒，结果CPU直接跑满，连看门狗都喂不上。嗯，这种坑咱们今天必须填上。

RTE支持四种触发类型：周期性触发、数据触发、操作触发和模式切换触发。每种都有它的脾气，咱们一个一个来拆解。

3.1 周期性触发

周期性触发是最基础、最常用的触发方式。你给它一个时间间隔，它就老老实实按这个节奏干活。

我个人习惯把周期性触发分成两类：固定周期和可变周期。

固定周期：比如每10ms执行一次。适合传感器采样、状态刷新这类任务。
可变周期：周期值可以动态调整。比如根据负载情况，把采样周期从10ms拉长到50ms。

核心配置参数：

周期值：单位通常是毫秒或微秒
初始偏移：第一次触发前的等待时间，用于错峰
抖动容忍：允许的周期偏差范围

举个例子，你想想看，如果系统里有三个任务都是10ms周期，同时触发会怎样？CPU瞬间飙高，然后闲着。我建议给每个任务加个初始偏移，比如任务A偏移0ms，任务B偏移3ms，任务C偏移7ms。这样CPU负载就平滑了。

// 周期性触发配置示例（伪代码）
Rte_EventConfig_t eventConfig = {
    .triggerType = RTE_TRIGGER_PERIODIC,
    .periodMs = 10,
    .initialOffsetMs = 2,   // 错开2ms启动
    .jitterToleranceUs = 100 // 允许100微秒抖动
};
Rte_InstallEvent(&eventConfig);

我的经验：周期性触发最怕「共振」。如果多个周期任务的时间间隔成整数倍关系，它们会逐渐对齐，导致周期性峰值负载。我曾经在一个项目中，把三个任务的周期分别设为10ms、11ms、13ms，故意让它们互质，负载曲线瞬间平了。

3.2 数据触发

数据触发，就是当某个数据发生变化时，自动触发事件链。这玩意儿比轮询高效多了。

数据触发有三种常见模式：

模式	触发条件	典型场景
变化触发	数据值发生任何变化	按键状态、开关信号
阈值触发	数据超过或低于设定阈值	温度报警、电量低告警
变化率触发	数据变化速率超过设定值	急加速检测、压力突变

我记得有一次做车载项目，需要检测刹车踏板的行程。如果用周期性触发每1ms读一次，CPU扛不住。后来改成数据触发——踏板位置变了才触发，CPU占用率直接降了80%。

注意：数据触发有个坑——「抖动」。传感器数据在临界值附近来回跳，会导致频繁触发。我建议加一个迟滞区间，比如温度超过50度触发，低于48度才恢复。这2度的差值就是迟滞，能有效防抖。

// 数据触发配置示例
Rte_DataTriggerConfig_t dataCfg = {
    .dataId = RTE_DATA_TEMPERATURE,
    .triggerMode = RTE_TRIGGER_THRESHOLD,
    .thresholdHigh = 50.0f,
    .thresholdLow = 48.0f,   // 迟滞区间
    .debounceMs = 10         // 10ms防抖
};

3.3 操作触发

操作触发，说白了就是「被人叫醒」。它不依赖时间，也不依赖数据变化，而是由其他任务或中断主动调用。

操作触发有两种形式：

同步调用：调用方等待被调用方执行完毕。适合短任务。
异步触发：调用方发出信号就返回，被调用方排队执行。适合长任务。

你想想看，什么时候用操作触发？我举几个例子：

用户按下「开始」按钮，触发启动流程
通信模块收到完整报文，触发解析任务
故障检测模块发现异常，触发紧急停机

避坑指南：我曾经在一个项目中，把操作触发用成了「连环炮」。任务A触发任务B，任务B触发任务C，任务C又触发任务A。结果形成了死循环，系统直接卡死。后来我加了一个触发深度限制，最多嵌套3层，超出就报错。

// 操作触发示例
void TaskA_Handler(void) {
    // 做一些处理...
    Rte_TriggerOperation(RTE_TASK_B);  // 异步触发任务B
    // 这里不等待，直接返回
}

void TaskB_Handler(void) {
    // 任务B被触发后执行
    // ...
}

3.4 模式切换触发

模式切换触发，是RTE里比较高级的玩法。当系统从一个运行模式切换到另一个模式时，自动触发一系列事件。

常见的模式切换场景：

系统从「正常模式」切换到「省电模式」
从「手动控制」切换到「自动控制」
从「运行态」切换到「诊断态」

模式切换触发的好处是——批量处理。你不需要一个个去关任务、开任务，只需要定义好模式切换时的行为，RTE自动帮你搞定。

模式切换	触发的事件	说明
正常→省电	关闭显示、降低采样率、暂停通信	批量进入低功耗
手动→自动	启用控制算法、禁用人工输入	切换控制权
运行→诊断	冻结当前状态、开启日志记录	进入调试模式

我的建议：模式切换触发一定要设计好退出条件。比如进入省电模式后，什么条件下才能切回来？是定时唤醒，还是外部中断？我曾经见过一个产品，进入省电模式后因为退出条件没配好，再也醒不过来了。嗯，那叫一个尴尬。

// 模式切换触发配置
Rte_ModeSwitchConfig_t modeCfg = {
    .currentMode = RTE_MODE_NORMAL,
    .targetMode = RTE_MODE_POWER_SAVE,
    .onEnter = {
        .disableTasks = {RTE_TASK_DISPLAY, RTE_TASK_COMM},
        .setSamplingRate = 100  // 采样率降到100ms
    },
    .onExit = {
        .enableTasks = {RTE_TASK_DISPLAY, RTE_TASK_COMM},
        .setSamplingRate = 10   // 恢复10ms采样
    }
};

3.5 四种触发条件的对比与选择

最后，咱们做个总结。四种触发条件各有千秋，选哪个取决于你的场景：

周期性触发：适合固定节奏的任务，比如传感器采样、心跳检测
数据触发：适合事件驱动的场景，比如按键响应、报警处理
操作触发：适合任务间协作，比如流水线处理、级联调用
模式切换触发：适合系统级状态变更，比如电源管理、模式切换

我个人习惯是：能用数据触发就不用周期性触发，能用操作触发就不用轮询。为什么？因为省CPU啊。你想想看，一个按键，用周期性触发每1ms读一次，和用数据触发只在按下时触发，CPU开销差了多少？

好了，这一章的内容就到这里。触发条件这块，说白了就是「什么时候干活」的问题。配好了，系统跑得又稳又省电；配不好，CPU飙高、响应延迟、甚至死机。希望今天的内容能帮你避开我当年踩过的那些坑。

📚 课程目录

3、触发条件类型详解：周期性触发、数据触发、操作触发、模式切换触发

3.1 周期性触发

3.2 数据触发

3.3 操作触发

3.4 模式切换触发

3.5 四种触发条件的对比与选择