性能分析非常重要的一个方面是响应时间,例如,从一个任务被激活到运行完成的时间。可以通过多种方式来测量响应时间,如反转I/O引脚并使用逻辑分析仪进行测量,或通过添加一些额外的代码来测量两点之间时钟周期数。但这些测量措施只能检测两点之间的处理器时间,无法获知影响时间的因素,例如中断或其他任务抢占导致的干扰。
性能分析的另一个重要内容是执行时间,一段特定代码实际使用的处理器时间。我们通常可以对程序计数器进行采样获取使用的处理器时间,许多IDE支持该功能,大多数基于ARM的MCU为此提供了硬件支持。然而,通过该方式获取的数据是平均测量值,对于频率较低的函数或任务是不准确的。此外,这些信息不能指示异常长的执行可能会导致问题,例如超时。
使用RTOS知识进行跟踪
要获得RTOS行为的准确信息,你需要一个RTOS感知跟踪的解决方案。但许多工具仅支持指定的操作系统。它们通常使用水平甘特图显示任务执行随时间的变化,但其跟踪信息很难并行显示其他事件,例如RTOS API的调用。
图1 Tracealyzer主视图
Tracealyzer 的主视图(图1)使用垂直时间轴,不仅显示RTOS调度过程和中断,还通过文本标签显示RTOS调用的事件或自定义用户事件。这些标签“浮动”显示并均匀分布。调度轨迹中的矩形框对应于一次连续的执行,称为Fragment(分片)。参与者(Actor)表示被跟踪系统中的所有执行上下文,例如任务和中断处理程序。任务调度可以不同的方式呈现或查看。图1中,每个参与者一列,分片在多列中排序。
图2 执行时间和响应时间变化
一个参与者,在捕获视图中有多个实例。实例表示参与者的一次执行,即从任务被触发到完成的过程。在Tracealyzer 主视图中点击参与者的分片,参与者实例通过蓝色矩形框突出显示,如图1。
此外,执行时间和响应时间等性能指标基于每个实例计算,并可视化为图2所示的详细图表。例如如果捕获任务的最大响应时间是为 3255 µs,而最大执行时间仅为1087 µs,这意味着大部分响应时间被其他任务或中断占用。
Tracealyzer中的所有视图都是相互关联的,通过单击绘制的数据点,你会找到主跟踪视图中的相应位置,以及统计数据背后的详细RTOS行为。
任务调度事件如何分组到任务实例中?对于周期RTOS任务来说,一个实例对应一个迭代循环,由RTOS阻塞调用分隔,例如,循环中的队列接收调用QueueRecieve或延时调用DelayUntil。但是一个任务可能会执行多个这样的调用,那么Tracealyzer如何知道从哪里结束当前实例并开始一个新的实例?
Tracealyzer 有一个“实例完成事件”(IFE)概念,通过两种方式定义。用户在大多数情况下不需要为此烦恼,因为有一组标准规则,用于指定RTOS调用的内容作为IFE,例如延迟调用和 QueueRecieve调用。不需要额外的配置。但是,对于规则不合适的情况,可能会需要生成显式事件 (IFE) 标记实例完成,需要调用记录库中的特定函数实现。
图 3显示了一个示例,其中墨绿色控制任务分为多个实例,尽管这些点上没有发生任务切换。你可以手动决定如何将事件分组到实例中,从而控制时序统计的解释。
图3 实例结束事件IFE允许自定义间隔
总结
使用RTOS带来的复杂性,使得应用的运行时行为难以通过阅读代码的方式理解。基于Tracealyzer的可视化分析,可以帮助我们理解和控制软件的运行时行为。关于如何使用Tracezlyzer,捕获系统行为的信息,可以参考《嵌入式实时操作系统-基于STM32Cube、FreeRTOS和Tracealyzer的应用开发》
这个有点类似SystemView,不过SystemView是免费的,这个是收费的,所以没有推广开。
引用: wangerxian 发表于 2022-2-10 16:08 这个有点类似SystemView,不过SystemView是免费的,这个是收费的,所以没有推广开。
SystemView商业也是需要付费的,评估免费哦
引用: freebsder 发表于 2022-2-14 19:55 SystemView 有人深入介绍一下吗?简单用了下,没感觉先进性在哪里啊。
确实相比tracealyzer 简单了些~
引用: MamoYU 发表于 2022-2-15 14:44 SystemView商业也是需要付费的,评估免费哦
这种工具商业的意义是?目前公司都在用,不过只有出产前调试用。
引用: MamoYU 发表于 2022-2-16 14:40 这。。。那用啥啊
估计用破解版的。
引用: MamoYU 发表于 2022-2-16 14:37 商业版有技术服务
这样啊,应该还用不到技术服务。