第4章 CAPL函数与事件

第4章 CAPL函数与事件：系统事件、CAN事件、自定义函数、回调函数的使用

好，咱们进入第四章。这一章我打算聊聊CAPL里最核心的两个东西——事件和函数。

说实话，很多新手学CAPL，上来就写代码，结果发现程序跑起来完全不是那么回事。为什么？因为没搞懂事件驱动这个概念。CAPL不是像C语言那样从上往下顺序执行的，它是靠事件来触发的。你想想看，汽车上的ECU什么时候开始工作？得等上电、等收到报文、等按键按下，对吧？CAPL也是这个道理。

4.1 系统事件：脚本的“开机”与“关机”

系统事件，说白了就是CAPL脚本的生命周期管理。我最常用的两个：on preStart 和 on start。

关键区别：

on preStart：测量开始前触发，用于初始化硬件、加载DLL
on start：测量开始时触发，用于初始化变量、打开文件

我个人习惯把硬件相关的初始化放在 on preStart 里，把业务逻辑的初始化放在 on start 里。为什么？因为 on preStart 执行时，CAN总线还没激活，这时候配置硬件最安全。

on preStart
{
    // 加载CANoe的DLL库
    // 配置硬件通道
    write("硬件初始化完成");
}

on start
{
    // 初始化全局变量
    gTestStep = 0;
    gPassCount = 0;
    
    // 打开日志文件
    // 设置定时器
    write("测试脚本启动");
}

on stop
{
    // 关闭文件
    // 释放资源
    write("测试脚本停止");
}

我的经验：记得在 on stop 里做资源清理。我曾经有个项目，脚本跑了一整天，最后发现日志文件没关闭，导致磁盘空间爆满。从那以后，我每次写脚本都会检查 on stop 里的清理代码。

4.2 CAN事件：捕获总线上的“对话”

CAN事件是CAPL里最常用的事件类型。你想想看，总线上的报文来来往往，我们怎么抓住它们？就是用 on message 事件。

on message 0x123
{
    // 只捕获ID为0x123的报文
    write("收到报文 ID=0x%x", this.id);
}

on message *
{
    // 捕获所有报文（慎用，性能开销大）
    if(this.id == 0x456)
    {
        // 处理特定报文
    }
}

这里有个坑，我得提醒你。on message * 会捕获总线上的所有报文，如果你的总线负载很高（比如500kbps满载），这个事件会被频繁触发，导致脚本响应变慢。我建议尽量指定具体的报文ID。

4.3 自定义函数：让代码“活”起来

写CAPL脚本和写C语言很像，函数是组织代码的基本单元。我个人习惯把重复的逻辑封装成函数，这样代码看起来清爽，调试也方便。

// 检查报文是否在超时范围内
byte CheckMessageTimeout(int msgId, dword expectedCycleTime)
{
    dword actualCycleTime;
    
    // 计算实际周期
    actualCycleTime = timeNow() - gLastMsgTime[msgId];
    
    if(actualCycleTime > expectedCycleTime * 1.1)
    {
        write("警告：报文 0x%x 超时", msgId);
        return 0;  // 超时
    }
    return 1;  // 正常
}

// 主测试逻辑
on message 0x123
{
    if(CheckMessageTimeout(0x123, 100) == 0)
    {
        gTestFailCount++;
    }
}

注意：CAPL函数不支持递归调用，也不支持函数指针。这是和标准C语言的一个区别。如果你需要复杂的回调机制，得用其他方式实现。

4.4 回调函数：让系统“通知”你

回调函数这个概念，说白了就是“你告诉系统：有事儿了叫我”。在CAPL里，回调函数通常用于定时器、键盘事件、系统状态变化等场景。

// 定时器回调
msTimer gTestTimer;

on timer gTestTimer
{
    // 定时器到期后执行
    write("定时器触发，当前测试步骤：%d", gTestStep);
    
    // 执行下一步测试
    ExecuteNextTestStep();
}

// 键盘事件回调
on key 'a'
{
    write("用户按下 'a' 键，开始自动化测试");
    StartAutomatedTest();
}

on key 's'
{
    write("用户按下 's' 键，停止测试");
    StopAutomatedTest();
}

我记得有个项目，客户要求测试脚本能手动控制执行流程。我就用键盘回调实现了“按a开始、按s停止、按r重置”的功能。调试的时候特别方便，不用每次都重新启动测量。

4.5 事件优先级与执行顺序

这里有个容易混淆的地方：多个事件同时触发时，谁先执行？

事件类型	优先级	说明
系统事件（preStart、start）	最高	测量开始/结束时执行
定时器事件	高	定时器到期时执行
CAN事件（on message）	中	收到报文时执行
键盘事件	低	用户按键时执行

实际上，CAPL的事件调度是顺序执行的，不会出现两个事件同时执行的情况。但如果你在事件处理函数里写了耗时操作（比如循环等待），就会阻塞其他事件的处理。嗯，这里要注意，千万别在事件处理函数里写死循环或者长时间的延时。

4.6 实战技巧：组合使用

在实际项目中，我经常把系统事件、CAN事件和自定义函数组合起来用。比如下面这个例子：

// 全局变量
int gTestPhase = 0;
msTimer gPhaseTimer;

// 系统启动
on start
{
    write("测试开始");
    gTestPhase = 1;
    setTimer(gPhaseTimer, 1000);  // 1秒后进入下一阶段
}

// 定时器回调
on timer gPhaseTimer
{
    gTestPhase++;
    write("进入测试阶段 %d", gTestPhase);
    
    if(gTestPhase < 5)
    {
        setTimer(gPhaseTimer, 1000);
    }
}

// CAN报文处理
on message 0x100
{
    if(gTestPhase == 2)
    {
        // 在阶段2检查特定报文
        CheckSpecificSignal(this);
    }
}

// 自定义函数
void CheckSpecificSignal(message *msg)
{
    if(msg.byte(0) == 0xAA)
    {
        write("信号检查通过");
    }
    else
    {
        write("信号检查失败");
    }
}

我的建议：写CAPL脚本时，先把事件框架搭好，再填充具体逻辑。就像盖房子，先搭好框架，再砌墙。这样代码结构清晰，后期维护也方便。

好了，这一章的内容就到这里。总结一下：系统事件管生命周期，CAN事件管总线通信，自定义函数管代码复用，回调函数管异步通知。把这四个东西用好，你的CAPL脚本就能写得既专业又高效。

下一章我会讲CAPL的数据类型和变量作用域，到时候咱们再聊。

📚 课程目录